Ship audit-grade Indian portfolio parsing without reverse-engineering registrars.
Portfolio Intel turns CAMS and KFintech CAS PDFs into structured data for browser tools, fintech products, and AI clients. This docs hub is optimized for separate Pages hosting, while keeping the docs MCP surface independent.
Start here
The landing page stays high-signal: each route has a clear job, and the browser docs do not need to know how the docs MCP server is deployed.
Quickstart in five minutes
Generate a key, parse your first CAS, and understand the response shape before touching a production workflow.
Platform setupClaude, Cursor, VS Code, ChatGPT
OAuth for Claude Desktop, header-based setup for IDEs, and OpenAPI import for ChatGPT actions.
ReferenceREST and MCP endpoints
Parse, enrich, MCP transport, auth semantics, and when to use each integration surface.
ExamplesCode you can paste today
Node.js, Python, cURL, MCP tool flows, and a simple operational mental model for the product.
Platform setup guides
Keep setup guidance grouped by client instead of burying it inside one endless page. This makes the docs markdown-friendly and easier to keep aligned with the MCP worker content.
Claude Desktop / claude.ai
Connector UX with OAuth and the consent screen flow.
Claude Code CLI
Remote MCP over HTTP with a bearer header.
Cursor IDE
Drop-in config using remote MCP headers.
VS Code + Copilot
User configuration snippet for MCP over HTTP.
ChatGPT Actions
OpenAPI import and OAuth discovery for custom GPT flows.
Docs MCP
A dedicated remote MCP surface for querying docs from AI tools.
What the docs site should own
The separate Pages project should focus on browser readability and deployment isolation. AI search and assistant behavior can evolve independently without destabilizing the docs shell.
Readable, linkable, SEO-friendly content
Markdown or MDX pages, stable URLs, and a clean route tree for product, platform, and API docs.
Keep `/api` as a focused Stoplight surface
The interactive API route should remain a dedicated reference view, not the landing page itself.
Reuse the existing docs MCP worker
Keep docs MCP separate from the browser runtime and feed both surfaces from the same docs source later.
FAQ snapshot
The full answers live in the FAQ page, but the landing page should still expose the questions users ask before they commit to an integration path.
What password formats do CAS PDFs usually use?
See the full answer in the FAQ section when you need implementation detail rather than just the headline.
Which statement types and registrars are supported today?
See the full answer in the FAQ section when you need implementation detail rather than just the headline.
Should I use REST API or MCP for my product?
See the full answer in the FAQ section when you need implementation detail rather than just the headline.
How does pricing work for test keys and live keys?
See the full answer in the FAQ section when you need implementation detail rather than just the headline.
The landing page is ready for separate Pages deployment now. Richer docs AI like semantic retrieval or an in-browser assistant should remain a second phase after the docs source of truth is unified.