Learners increasingly ask an AI assistant for practice material instead of opening a search engine. The assistant can explain a topic, but it can't see which MCQ chapters actually exist on a particular site. I run two exam-preparation sites under PlannerEdge Labs, MPSC Planner and UPSC Planner, so I built a connector that lets Claude, ChatGPT and any other MCP client find the right chapter and send the learner to practice.
The problem
An assistant asked for "NCERT Class 10 Federalism MCQs" can only guess or search the open web. What I wanted was a small, safe, structured answer: the matching collection, how many practice questions it has, a few sample questions, and a link to the practice page on the site itself.
I deliberately scoped it as discovery only. One tool, read-only, no sign-in. It never returns correct answers or explanations, and it doesn't touch learner records. Practice stays on the website, where sign-in may be required.
The architecture
The request path is short: the AI client calls the connector over HTTPS, the site forwards /mcp to the FastAPI backend, the backend runs a bounded read-only query against that site's PostgreSQL database, and the response carries canonical page links and practice links back to the assistant.
The server uses the MCP Python SDK with stateless Streamable HTTP and a single tool, find_mcq_collections. It takes a short topic query and a limit, and returns collections with breadcrumbs, an eligible-question count, up to five child collections for hub pages, and up to three answer-free sample questions.
One codebase, two sites
MPSC Planner and UPSC Planner share a codebase but run as separate deployments with separate databases. The connector reads its identity (name, domain, icon) from the site configuration, so enabling it on another site is configuration plus its own deployment, not new code. I made a point of not hardcoding exam names, subjects or languages. MPSC serves Marathi questions and UPSC serves English ones, and the same search code handles both.
Engineering challenges
Search relevance
Live testing found my first search was too strict: a full sentence returned nothing because every word had to match. My first fix was too loose. It returned the closest matches, which meant "Class 11 Federalism" returned Class 6 and 7 chapters, and nonsense input returned real chapters.
I deleted the fallback. The final rules are simple and strict. Numbers must match exactly and next to the label the catalogue itself uses, so "Class 11" never matches "Chapter 11" and "1" never matches "10". Digits in Devanagari and Latin compare as equal. Words the catalogue doesn't contain are ignored and named in the response, and the remaining words must all match. If nothing matches, the tool says so instead of guessing.
Answer-key isolation
The sample query selects only question text, options and language. Correct answers and explanations are never read from the database, and the response schema rejects unknown fields. A sample is also dropped unless its option labels form a clean sequence like A to D, so an odd option that smuggles in an answer can't slip through. When something looks malformed, the tool omits the sample rather than widening what it shows.
Serverless HTTP and resource limits
A GET on an MCP endpoint can open a long-lived stream that holds a request slot, which is a cheap way to exhaust a small service. So the endpoint accepts POST only and answers everything else with 405. Each request runs in a read-only transaction with a query budget, a statement timeout and an overall deadline, with a small worker pool and a short per-client rate limit. Requests are size-capped, origins are checked, and failures return generic errors with no database detail.
Output truncation
Broad queries can produce huge responses. I cap the total output and decide what to drop first. A live test showed that dropping samples first left broad queries with no preview at all, so child links are now trimmed first and the sample questions are kept as long as possible.
Testing
I tested against the live endpoints with Claude and ChatGPT, using about twenty edge cases: wrong class numbers, gibberish, SQL-looking input, oversized limits and Marathi queries. Every bug became a regression test, and the backend suite runs against the real MCP SDK for both sites before each deploy. I also verified from a separate Claude account, to be sure it works for someone who isn't me.
One lesson: the tool's JSON and the assistant's wording are different things. The tool may return three samples while the assistant shows two, or translates Marathi into English. I judge the connector by its payload, not by the assistant's summary.
The outcome
UPSC Planner passed Anthropic's automated review and is published in the Claude directory as a Community connector. Community means automated review, not a deep security audit or an endorsement. MPSC Planner passed my private tests and has been submitted for review. Because it's a plain MCP URL, ChatGPT custom connectors and other MCP clients can use either endpoint too.
You can see the listing at claude.ai/directory/upsc-planner. This is a different problem from the MCP server on this portfolio, which I wrote about in Static Websites Are Dead: that one serves public profile data, while this one fronts a real product catalogue and needed far stricter limits.