OathReady: Canadian Citizenship Test
Server Details
Canadian citizenship test practice: verified questions, mock tests, IRCC stats, eligibility tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 10 of 10 tools scored.
Each tool has a distinct purpose with no functional overlap: presence calculation, question lookup, separate stats for citizenship and journey, mock test vs. single practice question, multiple guides for different aspects (oath, test day, study, general info). An agent can unambiguously select the correct tool for each task.
Most tools follow a 'get_<noun>' pattern (8 out of 10), but 'calculate_presence' and 'check_answer' use different verbs, breaking the pattern slightly. Additionally, some names use multiple nouns (e.g., 'get_test_day_guide'), but overall the naming is predictable and readable.
With 10 tools, the server covers all core aspects of Canadian citizenship test preparation without being bloated or sparse. Each tool serves a clear need, from eligibility calculation to test-day guidance, making the set well-scoped and manageable.
The tool set comprehensively covers the application domain: eligibility (calculate_presence), study materials (get_study_guide, get_practice_question, get_mock_test), test information (get_test_info, get_test_day_guide, get_oath_guide), statistics (get_citizenship_stats, get_journey_stats), and answer verification (check_answer). No obvious gaps exist for the stated purpose.
Available Tools
10 toolscalculate_presenceCalculate physical presenceARead-onlyIdempotentInspect
Calculate physical presence for Canadian citizenship eligibility (the 1,095-days-in-5-years rule, including the pre-PR half-day credit capped at 365). Dates are YYYY-MM-DD. Returns eligibility as of the application date plus any shortfall. This is an estimate, not legal advice; the full interactive calculator is at https://oathready.ca/presence-calculator.
| Name | Required | Description | Default |
|---|---|---|---|
| pr_date | Yes | Date the person became a permanent resident | |
| absences | No | Trips outside Canada (departure and return days count as present) | |
| application_date | No | Planned application date (defaults to today) | |
| temporary_resident_from | No | In Canada since this date as a temporary resident/protected person, if any |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | Yes | |
| pr_days | Yes | |
| eligible | Yes | |
| pre_pr_credit | Yes | |
| required_days | Yes | |
| shortfall_days | Yes | |
| full_calculator | Yes | |
| pre_pr_credit_cap | Yes | |
| total_credited_days | Yes | |
| pre_pr_physical_days | Yes | |
| absence_days_deducted | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds context beyond annotations: explains the specific rule, date format, and that it returns eligibility and shortfall. Annotations already indicate read-only and idempotent, so description reinforces safety and provides rule-specific behavioral details.
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, front-loaded with purpose and rule, then format, then return info and disclaimer. No wasted 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 rule, date format, return value, and disclaimer. With output schema present, return values are covered. Could mention error handling or out-of-range dates, but adequate for a calculator tool with good schema annotations.
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 baseline is 3. Description mentions date format and the rule, but does not add additional meaning per parameter beyond what is already in the schema.
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 'Calculate physical presence for Canadian citizenship eligibility' with specific rule details (1,095-days-in-5-years, half-day credit). Distinct from sibling tools that are all get_* 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?
No explicit guidance on when to use this tool vs alternatives. The description only states what it does and a disclaimer. Slight implicit differentiation by being a calculation tool, but no when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_answerCheck or look up an answerARead-onlyIdempotentInspect
Look up a bank question and optionally grade an answer to it. Accepts a question id (exact) OR remembered question text (fuzzy matched against all questions and their alternate phrasings). Typical uses: grading long after a question was fetched, or a user half-remembering a question from their real test and wanting the verified answer.
| Name | Required | Description | Default |
|---|---|---|---|
| answer | No | The user's answer to grade, if they have one | |
| question_id | No | The question id, e.g. q-042 (exact match) | |
| question_text | No | The question as the user remembers it (fuzzy matched); used when no id is given |
Output Schema
| Name | Required | Description |
|---|---|---|
| question | Yes | |
| web_page | Yes | |
| explanation | Yes | |
| question_id | Yes | |
| correct_answer | Yes | |
| match_confidence | Yes | |
| your_answer_correct | Yes | null when no answer was provided to grade |
| other_possible_matches | Yes | Runner-up matches when the text match was not certain |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds behavioral context: fuzzy matching of question text and the optional grading feature. No contradictions, and it provides useful additional detail.
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 just two sentences, with the first sentence clearly stating the purpose and the second providing usage details. It is concise and well-structured, with no wasted 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?
Given the presence of an output schema, the description covers the essential aspects: what the tool does, how to use parameters, and typical use cases. It is complete for an agent to determine when to invoke this tool.
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%, but the description adds meaning by explaining the OR relationship between question_id and question_text, and the fuzzy matching behavior. This goes beyond the 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?
The description clearly states the tool's purpose: 'Look up a bank question and optionally grade an answer to it.' It specifies the verb (look up/grade) and resource (bank question), and the distinction from siblings is evident as this tool focuses on answer checking rather than fetching tests or guides.
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 that it accepts either a question ID (exact) or remembered text (fuzzy matched), and provides typical use cases like grading after fetching or verifying half-remembered questions. It does not explicitly state when not to use it, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_citizenship_statsGet new-citizen statisticsARead-onlyIdempotentInspect
Official IRCC statistics on new Canadian citizens: monthly counts, yearly totals, and top countries of birth. Source: IRCC open data (Open Government Licence - Canada), rounded to the nearest 5. Cite https://oathready.ca/citizenship-statistics when using these numbers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| cite | Yes | |
| source | Yes | |
| monthly | Yes | |
| retrieved | Yes | |
| year_totals | Yes | |
| latest_full_year | Yes | |
| top_countries_of_birth | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds beyond this: data source (IRCC open data), rounding to nearest 5, and citation requirement. 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?
Two sentences with no wasted words. First sentence states purpose and contents, second adds source, rounding, and citation. Efficient and well-structured.
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 no parameters and existing annotations/output schema, the description is nearly complete. It covers data source, rounding, and citation. Missing explicit mention of output format, but schema covers it.
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?
There are no parameters, so schema coverage is 100%. The description adds meaning by listing included data (monthly counts, yearly totals, top countries of birth), which helps understand what the tool returns.
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 provides official IRCC statistics on new Canadian citizens, specifying monthly counts, yearly totals, and top countries of birth. This distinguishes it from sibling tools like get_journey_stats, which likely focuses on different statistics.
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 use for obtaining citizen statistics but does not explicitly state when to use or avoid this tool, nor does it mention alternatives among siblings. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_journey_statsGet citizenship journey timelinesARead-onlyIdempotentInspect
How long the citizenship journey takes: the official IRCC processing time plus anonymous community medians (days from application to each milestone: AOR, test invitation, test, oath) contributed by OathReady users who share their journeys. Community cohorts under 5 journeys are never published.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| stages | Yes | |
| web_page | Yes | |
| community | Yes | null until enough journeys are shared |
| official_processing_time | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint; description adds useful context: community-contributed data, privacy condition (cohorts under 5 not published), and list of milestones.
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 with no fluff. Front-loaded with key info (timeline, official vs community). 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?
Tool has no parameters and an output schema exists; description sufficiently explains what the tool returns. Could be considered complete.
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?
No parameters; empty input schema with 100% coverage. Description correctly omits parameter details, maintaining clarity.
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?
Clear verb 'get' and specific resource 'journey_stats' (citizenship journey timelines). Differentiates from siblings like 'get_citizenship_stats' which likely focuses on different statistics.
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?
Description explains what data is returned (IRCC times, community medians, privacy threshold) but does not explicitly state when to use or not use alternatives. However, the context of sibling tools makes the purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_mock_testGet a full mock testARead-onlyInspect
Get a full mock Canadian citizenship test: a set of questions in the real exam format (the real test is 20 questions, pass mark 15). Returns questions with answer keys and explanations. Act as quizmaster: present one question at a time, never reveal an answer before the user commits, keep score, and give a pass/fail verdict with 15/20 as the bar.
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many questions (real test is 20) | |
| topic | No | Limit to one study topic | |
| province | No | Include region-specific questions for this province or territory |
Output Schema
| Name | Required | Description |
|---|---|---|
| pass_mark | Yes | |
| questions | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=true) already indicate safe read. The description complements by detailing return content (questions, answer keys, explanations) and specifying agent behavior as quizmaster. No contradictions, and adds valuable behavioral context beyond 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?
Three sentences: purpose, return format, usage instructions. Front-loaded and concise with no fluff. 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?
Covers purpose, return structure, and detailed agent behavior. An output schema exists (not shown but noted), so the description focuses on interaction. Complete for a mock test tool.
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?
All three parameters have 100% schema coverage with descriptions. The description does not add new semantic information beyond what the schema provides. 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 explicitly states 'Get a full mock Canadian citizenship test' with details on format, number of questions, and pass mark. It clearly distinguishes from sibling tools like get_practice_question by describing the full mock test experience.
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?
Provides clear usage instructions for the agent: present one question at a time, don't reveal answers early, keep score, give pass/fail verdict. However, it does not explicitly contrast with sibling tools (e.g., when to use get_practice_question instead), leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_oath_guideGet the oath ceremony guideARead-onlyIdempotentInspect
What happens at the Canadian citizenship oath ceremony: the oath text, what to bring, how the day unfolds (video and in-person), and first steps as a new citizen. Verified against official IRCC guidance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| bring | Yes | |
| formats | Yes | |
| web_page | Yes | |
| oath_text | Yes | |
| dress_code | Yes | |
| oath_notes | Yes | |
| what_happens | Yes | |
| after_the_ceremony | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, so the bar is lower. The description adds value by stating the content is 'verified against official IRCC guidance,' which conveys trustworthiness and accuracy beyond what annotations offer. 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 with two sentences: the first lists the content topics, the second adds verification context. Every sentence adds value, and the structure is front-loaded with the key purpose.
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 zero parameters and the presence of an output schema, the description is complete. It covers the tool's purpose, content, and verification. No further details are needed for an AI agent to understand and use it.
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?
There are zero parameters, so no parameter info is needed. Schema coverage is 100%, and the description does not need to add parameter meaning. The description adequately covers the purpose, compensating for the lack of 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 provides information about the Canadian citizenship oath ceremony, listing specific content areas (oath text, what to bring, day unfolding, first steps). It distinguishes from sibling guides like get_study_guide or get_test_day_guide by focusing on the oath ceremony specifically.
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 usage for learning about the oath ceremony but does not explicitly specify when to use this tool over alternatives. With multiple sibling guides (e.g., get_study_guide, get_test_info), explicit guidance on when to use this one would help but is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_practice_questionGet a practice questionARead-onlyInspect
Get one random Canadian citizenship test practice question from OathReady's verified bank (based on the official Discover Canada guide). Returns the question, shuffled options, the correct answer, and an explanation. Act as quizmaster: show the user ONLY the question and options, wait for their pick, then grade it and share the explanation.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Limit to one study topic | |
| province | No | Include region-specific questions for this province or territory |
Output Schema
| Name | Required | Description |
|---|---|---|
| id | Yes | Stable question id, e.g. q-042 |
| topic | Yes | |
| source | Yes | |
| options | Yes | Answer choices in display order |
| question | Yes | |
| web_page | Yes | This question's page on oathready.ca |
| explanation | Yes | |
| correct_answer | Yes | Do not reveal until the user has answered |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, consistent with the read-only nature. The description adds behavioral context beyond annotations: the question is random, from a verified bank, options are shuffled, and the agent should act as quizmaster. This gives the agent a clear understanding of the tool's behavior.
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, consisting of three sentences. It front-loads the core purpose, lists return values, and provides a clear usage instruction. Every sentence adds value with no 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 presence of an output schema (not shown) and two optional parameters with enums, the description covers the tool's purpose, usage, and return values adequately. It does not need to detail return format because the output schema handles that. The guidance on acting as quizmaster adds practical completeness.
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% with enums and descriptions. The description adds semantic context: 'Limit to one study topic' for topic and 'Include region-specific questions for this province or territory' for province, which helps the agent understand how to use these parameters effectively.
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 explicitly states it retrieves one random Canadian citizenship test practice question from a verified bank, and instructs the agent to act as quizmaster. This clearly differentiates it from sibling tools like get_mock_test (which likely provides multiple questions) and check_answer (which grades answers). The verb 'get' and resource 'practice question' are specific.
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 provides clear guidance on when to use the tool (when a user wants a practice question) and how to interact: show question and options, wait for pick, grade, and share explanation. However, it does not explicitly mention when not to use it or name alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_study_guideGet a topic study guideARead-onlyIdempotentInspect
Get OathReady's study-guide content for one citizenship test topic: an overview and the bite-size facts most commonly tested, verified against the official Discover Canada guide.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | The study topic |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| topic | Yes | |
| overview | Yes | |
| web_page | Yes | |
| key_facts | Yes | |
| practice_questions_in_topic | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds useful context about the content's source and curation (verified against official guide), which is beyond annotations. 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?
A single sentence that is concise, front-loaded, and contains no unnecessary words. Every part serves the purpose.
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 one parameter and an output schema, the description is complete. It explains what the tool does and the quality of the content. No missing information.
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% with one parameter that has a clear enum and description. The description's mention of 'one citizenship test topic' adds minimal value beyond the schema. Baseline 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 the tool gets study-guide content for one citizenship test topic, specifies the content type (overview and bite-size facts), and notes verification against official guide. This distinguishes it from sibling tools like get_mock_test 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 description does not explicitly state when to use this tool versus alternatives or when not to use it. The context of 'study guide' implies usage for topic review, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_test_day_guideGet the test day guideARead-onlyInspect
Practical guidance for Canadian citizenship test day, plus what recent test-takers actually reported: hot topics that came up a lot lately and short anonymous tips from real reports on OathReady.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| before | Yes | |
| during | Yes | |
| web_page | Yes | |
| recent_reports | Yes | |
| online_test_facts | Yes | |
| recently_hot_topics | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds context about the content (practical guidance, hot topics, tips) but does not disclose additional behavioral traits beyond what annotations provide.
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 a single sentence that efficiently conveys the tool's purpose with no wasted words. It is front-loaded with the key function.
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 the presence of an output schema, the description sufficiently explains what the tool returns. No additional context is needed for the agent to understand its role.
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?
There are no parameters, so schema coverage is 100%. The description adds no parameter details because none exist. Baseline for 0 parameters is 4, and the description is adequate.
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 provides practical guidance for the Canadian citizenship test day and includes recent test-taker reports, hot topics, and anonymous tips. This distinguishes it from siblings like get_test_info (general info) and get_citizenship_stats (statistics).
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 usage for test day preparation and recent insights but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_test_infoGet test and oath factsARead-onlyIdempotentInspect
Key facts about the Canadian citizenship test and oath: format, pass mark, who must take it, how scheduling works, and what happens at the ceremony. Verified against official IRCC sources.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| oath | Yes | |
| test | Yes | |
| practice | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's claim of being 'verified against official IRCC sources' adds credibility but does not disclose behavioral traits beyond what annotations provide. The description does not contradict 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?
The description is a single sentence that efficiently conveys all key details: what info is provided, the specific topics, and the source verification. No extraneous words, and the purpose 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?
For a tool with no parameters and an existing output schema, the description sufficiently covers the tool's role: providing key facts about the test and oath. It lists the topics covered, making the tool's knowledge boundaries clear. The openWorldHint=false annotation is consistent with the bounded scope.
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 and 100% schema description coverage. The baseline for 0 parameters is 4, and the description does not need to add parameter details. It appropriately focuses on tool purpose.
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 provides 'key facts about the Canadian citizenship test and oath' and lists specific topics like format, pass mark, scheduling, and ceremony. This differentiates it from sibling tools such as get_oath_guide or get_mock_test.
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 usage for factual information about the test and oath but does not explicitly state when to use this tool versus alternatives like get_oath_guide (ceremony details) or get_study_guide (study materials). No guidance on when not to use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!