Indian government exams and jobs from official notices: dates, results, admit cards, answer keys
Scored across 2 tools
The two tools have clearly distinct roles: search_exams finds exams, and get_exam retrieves full details for a specific exam using its slug. The descriptions explicitly explain the workflow and boundary between them, leaving little chance of misselection.
Both tools follow a consistent snake_case verb_noun pattern: search_exams and get_exam. The verbs are clear and predictable for their actions.
Two tools is slightly thin by typical MCP standards, but for a read-only exam index the search-plus-detail split is well matched to the purpose. Each tool clearly earns its place.
The surface covers the core workflow: discover exams via search and inspect one via slug, including facts, sections, and documents. Minor gaps remain around browsing or pagination, but agents can work around them through search queries.
Get one exam's details: current status and date, its ParikshaIndex section pages (result, admit card, answer key…), curated facts with their official sources (vacancies, age, fee, qualification, pay, dates) and its newest official documents with PDF links. Use it after search_exams, with the slug of the exam result. Read-only, no side effects. Limitations: facts are present only for exams ParikshaIndex has checked (facts is then omitted); dates are as the commission published them and may change, so users should confirm on the official website.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | From search_exams, e.g. ssc-cgl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), yet the description still adds material context the agent cannot see elsewhere: `facts` may be entirely omitted for unchecked exams, dates are as-published and may change, and results include PDF links. The optional-field caveat is the kind of detail that prevents misinterpretation of a missing key.
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?
Front-loaded with the return payload and the usage rule, then limitations. The parenthetical field enumerations are long but each maps to real returned data; the single limitation sentence is dense but earns its place.
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 no output schema, the description must carry the return-value burden, and it does: it names every major section, flags the possibly-absent `facts` field, and warns about date volatility. Nothing an agent needs to call it or interpret the response is missing.
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 100% and the schema already documents `slug` with its source and an example ('From search_exams, e.g. ssc-cgl'). The description only restates that provenance, adding no format or edge-case detail beyond it. Baseline 3 is correct when the schema fully carries the parameter.
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?
States a specific verb and resource ('Get one exam's details') and then enumerates the exact payload: status, date, ParikshaIndex section pages, curated facts with sources, and newest official documents with PDF links. An agent can distinguish this from search_exams without inspecting either schema.
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 routes the agent: 'Use it after search_exams, with the `slug` of the exam result.' That names the alternative, the ordering, and the required input provenance. No exclusions are stated, but for a single-purpose detail lookup none are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ParikshaIndex's index of Indian government exams, recruiting bodies, state and qualification job lists and official notices. Use it when the user asks about a government exam or job (dates, result, admit card, answer key, cut-off, syllabus, vacancies, eligibility) or which jobs are open for a qualification or state. Query in English, e.g. 'ssc gd answer key 2026', 'rrb ntpc', 'bihar govt jobs', '12th pass'; stage words and a year narrow it. Returns up to 10 matches, best first, each with its ParikshaIndex page; exams also carry a slug for get_exam. Read-only, no side effects. Limitations: covers only what commissions have published on their official websites and ParikshaIndex has indexed; an empty result means nothing matched, not that no such exam exists.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Exam or body name, optionally a stage and a year |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint, idempotentHint, destructiveHint=false), yet the description still adds non-obvious behavior: results capped at 10, ordered best-first, each carrying its ParikshaIndex page, and — critically — that an empty result means nothing matched rather than that the exam doesn't exist. It also discloses a real coverage limitation (only what commissions published and ParikshaIndex indexed). None of this is derivable from the 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?
Front-loaded with purpose before usage, then returns semantics, then limitations — a sensible information hierarchy. Every sentence carries distinct information: no restatement of the title, no filler, and the caveat about empty results is placed where an agent will read it before deciding to trust a zero-result.
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 no output schema, the description still specifies result count, ordering, and the per-result `slug`/page shape, so an agent knows what comes back. Combined with the coverage caveat and the empty-result interpretation, nothing needed to call or interpret this single-parameter search tool is missing.
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 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema's terse 'Exam or body name, optionally a stage and a year': it mandates English queries, supplies example strings, and explains that stage words plus a year act as narrowing terms. It stops short of describing any ranking/query syntax rules, hence 4 rather than 5.
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?
Names a specific verb (search) and a specific resource (ParikshaIndex's index of Indian government exams, recruiting bodies, state/qualification job lists, official notices), and even enumerates the fact types covered (dates, result, admit card, cut-off, syllabus, vacancies). It distinguishes itself from the only sibling by noting exams carry a `slug` for get_exam, so an agent can pick between list-search and detail-fetch without opening either schema.
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 states when to use it (user asks about a government exam/job, or which jobs are open for a qualification or state) and implies the handoff to get_exam once a slug is known. It also gives concrete query patterns ('ssc gd answer key 2026', 'rrb ntpc', 'bihar govt jobs', '12th pass') and notes that stage words and a year narrow results, which is actionable routing guidance rather than vague context.
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.
get_examsearch_examsIndian government statistics and public data: economy, elections, health, agriculture and more
Indian jobs via your AI: profile, apply, skill tests. Employers: post jobs free, find talent.
Open vacancies and competitions of the EU institutions, read daily from their official job pages.
UPSC prep: interactive quizzes, previous-year questions, daily current affairs, cited study search
Add one secure layer between your agents and this server.
