Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SearchCAIE MCP Server find questions on 'data representation' for 9618 paper 1 from 2021"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Standalone MCP server for Search CAIE past-paper search.
Core search tools for single-topic and multi-topic queries
Filters for subject, paper, year, session, chapter, mode, and pagination
LLM-friendly tool responses: concise text preview plus structured JSON
Multi-topic search returns recommended_ids for quick follow-up retrieval
get_questions supports both compact (default) and full detail modes
Backward-compatible inputs: comma-separated strings and native arrays
Upstream retries and structured error handling
Related MCP server: arXiv MCP Server
search_multi accepts either topics (comma-separated string) or topics_list (array)
get_questions accepts either question_ids (comma-separated string) or question_ids_list (array)
get_questions defaults to detail="compact" to reduce token usage and improve LLM answer quality
pip install .Or from git:
pip install "git+https://github.com/Pixel2075/searchcaie-mcp.git"{
"mcpServers": {
"searchcaie-search": {
"command": "searchcaie-mcp",
"env": {
"MCP_API_BASE": "https://api.searchcaie.com/api"
}
}
}
}MCP_DEFAULT_SUBJECT is optional. If omitted, the server does not apply a
subject filter by default.
MCP_API_BASE (default: https://api.searchcaie.com/api)
MCP_DEFAULT_SUBJECT (optional; if unset, no default subject filter is applied)
MCP_REQUEST_TIMEOUT (default: 30)
MCP_TRANSPORT (default: stdio)
MCP_HOST (default: 127.0.0.1)
MCP_PORT (default: 8000)
MCP_PATH (default: /mcp)
searchcaie-mcpMCP_TRANSPORT=streamable-http \
MCP_HOST=0.0.0.0 \
MCP_PORT=8000 \
MCP_PATH=/mcp \
searchcaie-mcpFetch full question details and mark schemes for selected IDs.
Accepts either question_ids (comma-separated) or question_ids_list.
Default detail is compact for LLM-friendly responses.
Returns for each question:
Full question text and context
Key mark scheme points (authoritative answers)
Paper identification
question_url: link to full question page
Image URLs (question_image_url, ms_image_url) for image-based questions
Use include_images=True to get image URLs for ALL questions (not just image-based). Use include_ocr=True to get OCR text extracted from question images.
| Name | Required | Description | Default |
|---|---|---|---|
| question_ids | No | ||
| question_ids_list | No | ||
| detail | No | compact | |
| max_key_points | No | ||
| include_images | No | ||
| include_ocr | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, ensuring safe behavior. The description goes further by detailing exactly what is returned (e.g., mark schemes, image URLs, OCR text) and how include_images and include_ocr affect the output, providing comprehensive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but it is a single paragraph that mixes parameter info with return values. A slightly more structured format could improve readability, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with no required fields and no output schema, the description covers all essential aspects: purpose, ID input formats, detail options, image/OCR flags, and return structure. It is self-contained and sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of 5 out of 6 parameters (question_ids, question_ids_list, detail, include_images, include_ocr), compensating for the 0% schema coverage. Only max_key_points is not explained explicitly, but its effect is partially implied by the mention of key mark scheme points.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full question details and mark schemes for selected IDs, using a specific verb and resource. It distinguishes itself from sibling tools like search_questions, which is for searching by keywords.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two parameter options for IDs and the default detail mode, giving clear usage context. However, it lacks explicit guidance on when not to use this tool versus alternatives like search_questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overall API statistics and service health.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It only states the purpose without disclosing safety, idempotency, or side effects, which is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, perfectly concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and presence of an output schema, the description is mostly complete for a basic stats/health endpoint. However, it could elaborate on what 'API statistics' entails to improve agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description does not add parameter info since none exist, but it also does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('overall API statistics and service health'), distinguishing it from sibling tools which focus on questions, reports, and searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description is minimal with no explicit context or exclusion criteria, leaving the agent to infer usage solely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Cambridge examiner report commentary for insights on how a topic is examined.
Returns examiner observations including:
What examiners expect in answers on this topic
Common mistakes candidates make
Tips for how to structure answers to gain full marks
Use AFTER searching questions to understand examiner expectations on the same topic. Examiner reports are the most authoritative source for HOW to answer, not WHAT to answer.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| subject | No | ||
| paper | No | ||
| year | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds behavioral context about the type of insights returned (examiner observations, common mistakes, tips). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, uses a bullet list for return types, and fits in a few sentences without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the purpose, return type, and usage guidance effectively. Does not explain pagination or exact output format, but for a search tool with no output schema, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the individual parameters (subject, paper, year, limit) beyond their names. The general purpose of the query is clear, but filter parameters lack explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches Cambridge examiner reports for insights on how a topic is examined. Lists specific return types (examiner expectations, common mistakes, tips). Differentiates from siblings by specifying it is about HOW to answer, not WHAT, and advises use after searching questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use AFTER searching questions to understand examiner expectations on the same topic.' Provides clear context for when to use, but does not give explicit alternatives for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search multiple topics and deduplicate by question ID.
Accepts either topics (comma-separated string) or topics_list.
| Name | Required | Description | Default |
|---|---|---|---|
| topics | No | ||
| topics_list | No | ||
| subject | No | ||
| paper | No | ||
| year | No | ||
| session | No | ||
| chapter | No | ||
| mode | No | hybrid | |
| limit_per_topic | No | ||
| max_results | No | ||
| expand | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm read-only and idempotent behavior. The description adds value by noting deduplication by question ID and the flexibility of accepting either 'topics' string or 'topics_list' array.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences: the first states purpose and key behavior, the second explains the alternative parameter formats. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters and no output schema, the description omits critical details about filtering parameters (subject, year, etc.) and the structure of the response, making it insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only explains 'topics' and 'topics_list', leaving 9 out of 11 parameters (e.g., subject, paper, year, mode) completely undocumented, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool searches multiple topics and deduplicates by question ID, distinguishing it from sibling tools like search_questions which likely handle single topics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like search_questions or search_web_context, leaving the agent to infer based on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search past-paper questions with optional filters.
Returns ranked questions with compact metadata. Each result includes:
Paper identification (paper, year, session, variant, paper_label)
Question number, marks, relevance score
Whether it's image-based (if so, question_image_url and ms_image_url are provided)
topic_signal: exam frequency and importance summary
question_url: link to full question page
NEXT STEP: Call get_questions(question_ids_list=[...]) with the recommended_ids to get full question text, mark scheme key points, and images.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| subject | No | ||
| paper | No | ||
| year | No | ||
| session | No | ||
| chapter | No | ||
| mode | No | hybrid | |
| limit | No | ||
| offset | No | ||
| expand | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent. Description adds value by detailing output structure (ranked results, compact metadata, image URLs, topic_signal).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise; front-loads purpose, uses bullet points for output details, and callout for next step. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output is well described, but input parameters are nearly undocumented. Given 10 params with 0% schema coverage, the description is incomplete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only mentions 'optional filters' without explaining any of the 10 parameters (query, subject, paper, etc.). Leaves agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches past-paper questions with filters, but does not explicitly differentiate from siblings like search_multi or search_examiner_reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no context on prerequisites or exclusions. Only a next-step suggestion to call get_questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find educational diagrams and illustrations for a CAIE topic.
Returns external web images (Wikipedia, GFG diagrams) — NOT past paper images. For actual question/mark scheme images, use get_questions with include_images=True.
Use this when:
Student needs a visual explanation of a concept (e.g., "show me a binary tree diagram")
Adding supplementary illustrations beyond what exam papers show
Returns: image URL, title, source domain.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| subject | No | ||
| num_images | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so no repetition needed. Description adds valuable behavioral context: returns external web images only (not past paper images) and specifies return fields (URL, title, source domain). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently organized: one-line purpose, contrast, bullet usage cases, return format. No redundant sentences. All information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 parameters and no output schema. Description covers return fields but lacks parameter descriptions. For simple search tool, usage guidance is strong but missing parameter details leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explicitly explain the parameters. The 'query' parameter is implied through usage examples, but 'subject' and 'num_images' are not described at all. The description does not compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states purpose: 'Find educational diagrams and illustrations for a CAIE topic.' Clearly differentiates from sibling tool get_questions by specifying it returns external web images, not past paper images. Provides a concrete example ('show me a binary tree diagram').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (visual explanation, supplementary illustrations) and when not to use (for question/mark scheme images, use get_questions with include_images=True). Names the alternative tool directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get educational web content to supplement CAIE exam explanations.
Returns summarized content from trusted CS education sites. Use when the student needs conceptual explanations beyond what mark schemes provide.
Web content is supplementary — always prioritize official CAIE mark scheme points first. Returns: source title, URL, domain, and key educational content (max 800 chars per source).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| subject | No | ||
| num_results | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and idempotentHint, so the tool is safe and idempotent. The description adds behavioral details such as returning summarized content from trusted CS education sites, with a max of 800 characters per source, and listing return fields (source title, URL, domain, key educational content). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with each sentence adding value. It front-loads the purpose, provides usage guidance, and specifies return format, all in a few sentences without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema), the description explains the return format but does not elaborate on the subject parameter or how num_results behaves. Additional details about the 'trusted CS education sites' would improve completeness. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain the parameters (query, subject, num_results). The description only implies the query relates to CAIE topics, but fails to add meaning for subject or num_results, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'educational web content', specifically targeting CAIE exam supplementation from trusted CS education sites. It distinguishes itself from sibling tools like search_examiner_reports and search_questions by emphasizing supplementary conceptual explanations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use when the student needs conceptual explanations beyond what mark schemes provide' and prioritizes official CAIE mark scheme points first. This provides clear context, though it could further specify when not to use or name alternative siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_questionsget_statssearch_examiner_reportssearch_multisearch_questionssearch_topic_imagessearch_web_contextScored across 7 tools
Tools have distinct purposes overall, but search_questions and search_multi overlap in searching questions; descriptions differentiate them (single vs multiple topics, deduplication). Minor confusion possible.
All tools use a consistent verb_noun snake_case pattern. 'get_' for retrieval and 'search_' for searching, with clear, predictable names.
Seven tools is well-scoped for a CAIE exam search server. Each tool addresses a specific need: searching, fetching details, examiner reports, statistics, supplementary content.
Core workflows are covered: search questions, get details, examiner reports, supplementary resources. Minor gaps like listing available subjects or papers are missing but not critical for the primary use case.
Search university course materials, your flashcards, quizzes, streak and quota. All tools read-only.
LLM-ready web search + instant answers + URL-to-clean-text fetch for agents and RAG.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Search peer-reviewed papers and research methodology guidance from your AI agent.
