French tests and schools that count for Canadian PR.
Scored across 9 tools
Most tools target distinct resources and actions: get_listing vs search_listings, get_product vs list_products, and the place/category/source tools are clearly separated. The only mild overlap is list_categories vs list_product_categories, but the descriptions make the distinction clear enough.
All tools follow a consistent snake_case verb_noun pattern: get_*, list_*, and search_*. Singular/plural usage is predictable (get_* for one item, list_*/search_* for collections).
Nine tools is a well-scoped set for a read-only directory API covering providers, products, categories, places, sources, and stats. Each tool has a clear purpose and no obvious filler.
The surface covers the main read-only workflows: browsing providers, searching, retrieving products, categories, places, sources, and stats. Minor gaps exist, such as no direct get_category/get_place/get_source tools, but agents can work around these through the list endpoints.
Get one published French provider by its slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The listing slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered elsewhere. The description's one genuinely additive fact is the 'published' qualifier, implying unpublished records are not returned. Auth requirements, not-found behavior, and localization are unaddressed.
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 short sentence with no filler, and the identifying mechanism ('by its slug') is placed where it is needed. Nothing could be removed without losing information.
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 one-parameter read with a fully described schema and complete annotations, plus no output schema, the description is nearly sufficient. The remaining gap is the naming inconsistency (listing vs. French provider) and the absence of any not-found or error behavior, which an agent calling by slug would want to know.
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 single slug parameter carries its own pattern, length bounds and description, so the schema does the heavy lifting. The description only restates that lookup is keyed on slug, adding no format or normalization guidance beyond 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?
States a specific verb ('Get') and a tightly scoped resource ('one published French provider by its slug'), which separates it from search_listings and the list_* siblings that return collections. It loses a point because the noun shifts from 'listing' in the tool name to 'French provider' in the description, leaving mild ambiguity about the returned entity.
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?
Usage is implied rather than stated: 'by its slug' signals a single-item exact-key lookup, and 'published' hints that unpublished items are out of scope. It never names search_listings as the alternative for retrieval by criteria other than slug, nor does it say what to do when the slug is unknown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one affiliate product by its slug, with its page and outbound link.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The product slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new information by stating the response includes the product's page and outbound link, which matters because there is no output schema. It omits not-found behavior, which keeps it below 5.
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 front-loaded sentence with no filler; the lookup key and the returned content are both stated in one pass.
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 one-parameter read tool with full annotation coverage and complete schema documentation, this is nearly sufficient. The only real gap is what happens when the slug does not resolve, which an agent would want to know.
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 single slug parameter carries its own description plus a pattern, so the schema does the heavy lifting. The description's 'by its slug' restates rather than extends that, matching the baseline 3.
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 affiliate product') and scopes it to a single-item lookup, which implicitly contrasts with the plural sibling list_products. It does not explicitly name the alternative tool, so it stops short of a 5.
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?
'by its slug' implies the precondition that the caller already has a slug, which is useful context for choosing this over list_products or search_listings. However, no explicit when-to-use/when-not statement or named alternative appears.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the number of published French providers, places and categories, and when the data last changed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds behavioral context only in the sense of what the response contains (counts and a last-changed timestamp); it says nothing about freshness caching, cost, or whether counts include unpublished entries beyond the word 'published'.
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 with no padding that front-loads the primary payload (the counts) and appends the secondary payload (last-changed time). Nothing is wasted.
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 carries the burden of describing return values, and it does name the four data points returned. It falls slightly short of 5 because it does not indicate the shape of the response (e.g., field names or whether counts are grouped), which an agent would need to consume it confidently.
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 tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly signals the tool is argument-free by framing it as a global count.
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 ('Get the number of') and enumerates exactly what is counted: published French providers, places and categories, plus last-update time. This clearly separates it from the sibling list_*/search_* tools, though it never names those siblings explicitly.
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?
Usage is only implied: an agent can infer this is the aggregate/count tool to use instead of paging through list_categories, list_places or get_listing. There is no explicit 'use this when you need totals rather than records' statement and no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List categories with their French provider counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so safety behavior is well covered. The description adds that results include French provider counts, which is useful context beyond annotations. It does not describe ordering, pagination, or return shape.
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 front-loaded sentence with no filler. Every element earns its place by naming the resource and the distinguishing output content.
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 zero-parameter read-only list tool with annotations covering safety and an empty schema, the description is nearly sufficient. The only gap is that it does not clarify return ordering or whether all categories are always included, but no output schema exists to cover that.
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 tool has zero parameters, so there is no parameter semantics burden. The schema is empty and fully self-explanatory, making a baseline high score 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 gives a specific verb and resource: 'List categories'. It also adds that results include 'French provider counts', which clarifies intended output. It does not explicitly distinguish this from siblings like list_sources or get_stats, so it stops short of a 5.
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?
There is no guidance on when to use this tool instead of alternatives such as get_stats, list_sources, or list_places. The listing purpose is implied by the name and description, but no usage conditions or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List countries, regions and cities that have French providers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the important scoping constraint that results are limited to places with French providers, which is genuine behavioral context. However, it says nothing about return shape (flat list vs. hierarchy) or ordering, so it adds only moderate value 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?
A single front-loaded sentence with no filler. The key scoping qualifier ('French providers') is present and nothing is repeated from the annotations.
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 no-parameter, read-only list tool with full annotation coverage and no output schema, the description is nearly sufficient. The only remaining gap is whether the output is a flat list or a nested country/region/city structure, which an agent might want to know before parsing.
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 tool takes zero parameters, so the baseline is 4. The description correctly implies no inputs are needed to scope the result and doesn't clutter with unnecessary parameter talk.
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 verb ('List') and resource ('countries, regions and cities') with a meaningful qualifier ('that have French providers'), so it's clear what the tool returns. It doesn't explicitly differentiate itself from siblings like list_categories or list_sources, though the resource domain makes it distinguishable in practice.
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?
Usage is implied: use it when you need the set of supported geographies. There's no explicit when-to-use/when-not-to-use guidance and no mention of alternatives such as search_listings or list_sources, so the agent must infer the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the product categories with their product counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive and closed-world, so the safety profile is covered. The description's contribution beyond that is that results include product counts — useful, but no ordering, pagination, or empty-result behavior is disclosed.
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 short sentence with zero filler, and the key payload detail (counts) is front-loaded where the agent will read it.
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 zero-parameter, read-only listing tool with full annotation coverage, the description plus schema is enough to invoke it correctly. Minor gap: with no output schema, the exact return shape (field names, ordering) is only alluded to.
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 tool takes no parameters, so there is no parameter semantics to explain; the baseline for a zero-param tool 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?
States a specific verb and resource ('List the product categories') plus a distinguishing payload detail (product counts). However, it does not differentiate itself from the sibling 'list_categories', leaving an agent to guess which category lister to call.
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?
There is no explicit when-to-use, when-not-to-use, or alternative-tool guidance. The only implied cue is that this variant returns counts, which the agent must infer rather than being told.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the affiliate products, with the price each had on the day it was checked. Filter by product category.
| Name | Required | Description | Default |
|---|---|---|---|
| category | No | A product category slug. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds one genuinely non-obvious data semantic — the price is a point-in-time snapshot from the day the product was checked, not a current price — but says nothing about result volume, ordering, or pagination.
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, zero filler, with the core action and the most decision-relevant detail (price snapshot semantics) front-loaded ahead of the filter note.
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 one-optional-param, read-only list tool with full schema coverage and annotations, the description is largely sufficient and even hints at the returned fields (product + price). The one gap is the absence of any output schema combined with no note on pagination or result limits.
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 single optional parameter carries its own type, slug pattern, and length bounds. The description only restates that the parameter filters by category, adding no syntax or behavior beyond the schema, 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?
States a specific verb and resource ("List the affiliate products") plus the returned payload (price as of the check date) and the filter dimension. It implicitly separates from get_product (single record) and list_categories, but never names a sibling, so the differentiation is left to inference.
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?
"Filter by product category" plus the optional parameter implies narrowing usage, but there is no explicit when-to-use guidance and no mention of when to prefer get_product, list_product_categories, or list_categories instead. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List where the French provider data comes from, with the license and refresh of each source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds information annotations cannot: the shape of the returned records (source, license, refresh cadence), which is the main behavioral question for a zero-argument list tool.
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?
One sentence, front-loaded with the verb and subject, with the returned fields appended where they add value. No filler and nothing repeated from the schema or annotations.
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 zero-parameter, read-only listing with rich annotations and no output schema, the description says enough about content to justify a call. It only stops short of clarifying what 'French provider data' scopes -- e.g. whether the list is exhaustive or filtered by locale.
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 tool takes no parameters, so the baseline is 4; there is nothing for the description to disambiguate beyond the empty schema. It correctly avoids inventing filter semantics that the schema does not support.
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 pairs a specific verb ('List') with a specific resource ('where the French provider data comes from') and adds what each item carries (license, refresh). That distinguishes it from list_categories and list_places, though the sibling differentiation is by implication rather than an explicit contrast.
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?
Usage is only implied: an agent can infer this is a reference/metadata listing to call when provenance or licensing matters, but the description never states when to call it or points to any alternative. With zero parameters there is little to get wrong, which keeps this at minimum-viable rather than failing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search published French providers by text, place and category.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Search text, with at least one letter or digit. Matches name, categories, attributes, description and place. Typos fall back to close matches. | |
| city | No | City slug, from /places. | |
| sort | No | `relevance` needs `q` and is the default with it. `name` is the default without `q`. `recent` is newest first. | |
| limit | No | Items per page. | |
| cursor | No | `page.nextCursor` from the previous response. Opaque. Send the same filters and `limit`. | |
| region | No | Region slug, from /places. | |
| country | No | ISO 3166-1 alpha-2 country code, any case. A country the directory does not cover, as listed in /places, gives 400. | |
| category | No | Category slug, from /categories. A parent slug also matches its children. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds only the meaningful scoping fact that results are limited to published French providers; the richer behavioral detail (typo fallback, cursor opacity, 400 on uncovered country) lives in the schema, not here.
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 front-loaded sentence with no filler or repetition. It is efficient, though the extreme terseness leaves no room for the routing or pagination cues an eight-parameter search tool would benefit from.
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 eight optional parameters, no required fields and no output schema, the description should at least orient the agent on results and pagination (cursor-based paging is only visible in the schema). The rich schema compensates substantially, but the description itself leaves gaps for a moderately complex search endpoint.
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%, so every one of the eight parameters is already documented with patterns, enums and defaults. The description's 'by text, place and category' loosely maps to q, city/region/country and category but adds no syntax or constraint beyond the schema, 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?
States a specific verb (Search) and resource (published French providers) plus the three facets used for filtering. It is distinguishable from get_listing (single item) and the list_* siblings (reference data), though it never explicitly frames that contrast and 'providers' is a slightly loose term for listings.
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?
Usage is only implied: 'Search ... by text, place and category' tells the agent what inputs exist but never says when to reach for this instead of list_places, list_categories or get_listing, nor any preconditions. An agent can infer it is the search entry point, but nothing is stated.
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_productlist_product_categorieslist_productsget_listingget_statslist_categorieslist_placeslist_sourcessearch_listingsCanadian citizenship test practice: verified questions, mock tests, IRCC stats, eligibility tools.
Guides, housing, jobs, events and communities for foreigners living in France, in 6 languages.
Citizenship by descent (Ireland, Canada) plus sourced visa rules for Americans moving abroad.
French address intelligence: 18.6M sold prices, energy, risk, crime and schools — each sourced.
Add one secure layer between your agents and this server.