Practice questions for the four Claude certifications. The assistant never sees the key.
Scored across 5 tools
Each tool has a distinct purpose: listing exams, fetching practice questions, grading answers, tracking progress, and opening the study page. No two tools overlap in function; even check_answer and open_study are clearly separated as quiz vs. study modes.
Four tools follow the verb_noun snake_case pattern (check_answer, get_practice_question, list_exams, open_study). my_progress deviates slightly as a noun phrase, but the overall naming is clear and predictable, so the inconsistency is minor.
With five tools, the server is well-scoped for its purpose of delivering certification practice and study functionality. Each tool serves a necessary role in the workflow, and the count is comfortably within the ideal range.
The tool surface covers the full lifecycle: discovering exams (list_exams), practicing (get_practice_question), getting feedback (check_answer), tracking progress (my_progress), and transitioning to a richer study interface (open_study). No obvious gaps exist for the stated domain.
Grades the user's choice and returns an explanation for EVERY option, including the ones they did not pick. On this exam two options are frequently defensible and only one is credited, so the reasons the wrong options lose are the part worth teaching.
| Name | Required | Description | Default |
|---|---|---|---|
| exam | Yes | Exam slug. | |
| selected | Yes | Option letters the user chose, e.g. ["B"] or ["B","D"]. | |
| question_id | Yes | The id from get_practice_question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it returns explanations for every option, and it warns that multiple options are often defensible but only one is credited, which shapes the user's expectations. The annotations do not claim read-only behavior, so nothing here contradicts them.
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 sentences, no filler. The main function and distinctive behavior are front-loaded, and the second sentence adds valuable exam-specific context that helps the agent understand why the tool behaves as it does. Every sentence 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 reasonably explains what the tool returns (an explanation for every option) and signals the correctness-grading nature. It could specify the output format or whether the answer is recorded, but for its simplicity the description is sufficiently complete 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 description coverage is 100%, and the input schema already documents each parameter clearly, including the expected format for 'selected'. The description does not add parameter-specific semantics, but the schema carries the burden adequately, so the baseline 3 applies.
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 names a specific verb ('Grades') and resource ('the user's choice'), and explicitly states the distinctive behavior: returning an explanation for every option. This clearly differentiates it from sibling tools like get_practice_question, which fetches questions rather than evaluating answers.
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 implies the tool is used after the user has selected an answer on an exam question, and the exam-context sentence explains why the wrong-option explanations matter. However, it does not explicitly state when to use it versus alternatives, nor does it mention prerequisites such as first obtaining a question_id from get_practice_question.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one original practice question with its options and no answer key. Present it to the user and let them choose before calling check_answer. Pass every id already served in exclude_ids — this server is stateless and remembers nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| exam | Yes | Exam slug from list_exams. | |
| focus | No | Optional ordering by how everyone else answers these questions: "hardest" serves the highest crowd miss rates first, "traps" serves the questions most people get wrong the SAME way — a shared misconception rather than merely a hard question. Nothing is filtered out; questions with no crowd data simply come last. | |
| domain | No | Optional domain id (e.g. "d3") to drill one area. Domain ids come from list_exams. | |
| exclude_ids | No | Question ids already served in this session, so they are not repeated. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it returns no answer keyable, and 'this server is stateless and remembers nothing,' which explains why exclude_ids is essential. This is valuable information an agent needs before calling the tool successfully.
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 entire description is two sentences with no filler. It front-loads the core result, then immediately gives the next step and the statelessness caveat. Every word 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?
For a simple read-only tool with four well-documented parametersched, the description covers what the tool returns, what it intentionally omits, and how to feed it state. It could mention the shape of the returned question id explicitly, but the stateless exclude_ids instruction is sufficient context for an agent to use it 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?
Schema coverage is 100%, so the schema already documents all four parameters. The description adds important semantic context for exclude_ids by stressing 'every id already served' and explaining the statelessness that makes it necessary. It does not add much for exam, focus, or domain, but the schema already covers those thoroughly.
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 states a specific action and resource: 'Returns one original practice question with its options and no answer key.' It also distinguishes itself from sibling tools by explicitly positioning it before 'check_answer' and clarifying it does not reveal answers, which separates it from answer-checking and progress tools.
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 gives clear workflow guidance: 'Present it to the user and let them choose before calling check_answer.' It also instructs the caller to pass all served ids via exclude_ids due to statelessness. It does not explicitly name alternatives or when not to use this tool, but the sequencing guidance is strong enough for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Claude certifications covered here, with exam codes, item counts, fees and the full domain list with published weights. Call this first to get valid exam slugs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already declaring safety, the description adds value by enumerating the returned content: codes, item counts, fees, domain list, and weights. This is consistent with annotations and gives the agent useful expectations about result richness without contradicting anything.
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 two concise sentences, front-loading the specific content delivered and then providing a clear call-to-action. Every word earns its place; no redundancy or filler.
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?
For a simple parameterless list tool with annotations covering the read-only nature and a closed world, the description fully explains the return payload and the intended invocation order. Nothing needed for correct selection or successful invocation 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?
With zero parameters, there is no parameter semantics to add. The baseline of 4 applies because the description has no need or opportunity to clarify parameters.
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 lists Claude certifications with exam codes, item counts, fees, and domain lists/weights. It also explicitly frames the role as the entry point for obtaining valid exam slugs, which distinguishes it from siblings like check_answer or get_practice_question.
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 phrase 'Call this first to get valid exam slugs' gives explicit timing guidance and explains why this tool should precede others. It does not explicitly list alternative tools or when not to use it, but the sibling context and the clear sequencing instruction are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Their recorded history for one exam, broken down by blueprint domain with the weakest first, plus how their misses compare with everyone else's on the same free-form questions. Call this at the start of a study session to decide what to drill, and after a run of questions to show what moved. It names the domain to pass to get_practice_question, and when their misses follow the crowd's favorite wrong answers it says to drill those with focus: "traps". Only a signed-in account has history; anonymous callers are told so rather than shown zeros.
| Name | Required | Description | Default |
|---|---|---|---|
| exam | Yes | Exam slug from list_exams. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, covering safety. The description adds valuable behavioral context: it explains the output structure (domains with weakest first, comparison of misses), the 'traps' focus when misses follow common wrong answers, and the anonymous-caller behavior (told so rather than shown zeros). This goes beyond the annotations and helps the agent anticipate side effects and edge cases.
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 dense but efficient, with the core purpose front-loaded in the first sentence, followed by usage guidance, output details, and an important edge case. It avoids fluff and each sentence contributes to agent understanding. It is slightly long but warranted given the behavioral nuances.
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?
For a tool with one parameter and no output schema, the description covers the essential aspects: what it does, when to use it, what output to expect (domain breakdown, comparison, 'traps'), and the anonymous-caller caveat. It does not specify the exact return format (e.g., JSON structure), but that may not be necessary for the agent to call it correctly. The description is sufficient for most use cases.
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 covers the single parameter (exam) with a full enum and description ('Exam slug from list_exams'). The description adds minimal extra meaning about the parameter beyond what the schema provides; it only refers to 'one exam' in the opening sentence. Since schema coverage is 100%, the baseline of 3 is appropriate.
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 what the tool does: it shows recorded history for an exam, broken down by blueprint domain with the weakest first, plus a comparison of misses against others on free-form questions. This is a specific verb+resource (shows history) and clearly distinguishes it from siblings like get_practice_question, which generates questions, or check_answer, which evaluates a single response.
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 tells the agent when to call this tool: at the start of a study session to decide what to drill, and after a run of questions to show what moved. It also mentions that it names the domain to pass to get_practice_question, effectively routing to a sibling. However, it does not state when not to use it (e.g., if no history exists) beyond the anonymous note, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open or resume the study page for an exam, optionally focused on a domain or a sub-objective. Use this when someone asks to study rather than to be quizzed in chat: the page gives them a visible question they answer themselves, and once it is open a richer set of tools appears for reading and steering that screen. Returns the URL; a browser agent should navigate there.
| Name | Required | Description | Default |
|---|---|---|---|
| exam | Yes | Exam slug from list_exams. | |
| domain | No | Optional blueprint domain, e.g. "d3". | |
| sub_objective | No | Optional concept, e.g. "d1.5". Ids are per-exam. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it opens/resumes a page, shows a visible question the user answers themselves, returns a URL, and instructs a browser agent to navigate there. No contradictions with annotations were found.
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?
Three sentences, each earning its place: core action, usage context, and return/navigation behavior. The key purpose is front-loaded and there is no redundant filler.
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 appropriately states the return value (URL) and the expected agent action. It could elaborate on what 'resume' means when a session already exists, but overall the essential calling context is covered.
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 schema already documents exam, domain, and sub_objective. The description rephrases domain/sub_objective as optional focus but adds no format, validation, or cross-parameter semantics beyond what the schema provides.
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?
Description names a specific verb ('open or resume'), a resource ('the study page for an exam'), and optional focus fields (domain/sub-objective). It also distinguishes itself from quiz-in-chat tools, so an agent can tell it apart from get_practice_question and check_answer.
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 this when someone asks to study rather than to be quizzed in chat,' providing both a positive and negative usage condition. It also signals that subsequent reading/steering tools appear once the page is open, guiding the agent's next actions.
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_practice_question1 field changedInput schema / properties / focusAdded value: +{
+ "description": "Optional ordering by how everyone else answers these questions: \"hardest\" serves the highest crowd miss rates first, \"traps\" serves the questions most people get wrong the SAME way — a shared misconception rather than merely a hard question. Nothing is filtered out; questions with no crowd data simply come last.",
+ "enum": [
+ "hardest",
+ "traps"
+ ],
+ "type": "string"
+}check_answerget_practice_questionlist_examsmy_progressopen_studyFree, unofficial practice questions for four Claude certifications, plus an AI blog (EN/PL).
Fetch real California Notary Public exam practice questions and grade answers in-chat.
Practice questions, exam facts & study guides for professional certification exams.
Run UX research from Claude — create card sort studies, list studies, pull headline stats.
Add one secure layer between your agents and this server.
