Canadian public-sector data and legal information for AI agents, paid per call in USDC over x402
Scored across 15 tools
Most tools target clearly distinct sources and actions (MGRS conversion, per-agency alert feeds, per-database searches). The only plausible confusion is between get_federal_law_section and lookup_canadian_rights, both Canadian legal, but their descriptions (statute text by act/section vs. plain-language Q&A by province) make the boundary readable. The three recall search tools are separated by jurisdiction/domain in both name and description.
Nearly all names follow a verb_noun snake_case pattern (get_*, lookup_*, search_*, convert_*), which is predictable and scannable. Minor deviations exist in element ordering, e.g. search_canadabuys_tenders versus search_vehicle_recalls_canada and search_us_fda_recalls, where jurisdiction/source placement varies.
Fifteen tools sit at the top of the well-scoped range and each maps to a distinct dataset or conversion task. The free/paid split is explicit per tool, and no tool appears redundant or filler.
Each named sub-domain (geospatial conversion, survey monuments, Canadian law, federal corporations, tenders, three recall databases, six alert feeds) has a working entry point, so there are no dead ends. Gaps remain: no capability/dataset discovery tool, no pagination or paging parameters on the 'up to 10 results' searches, and asymmetric coverage (e.g. US vehicle recalls, non-Canadian weather) that an agent must work around.
FREE, no payment: convert a latitude and longitude to a military grid reference (MGRS, 1 m precision, WGS84), or an MGRS reference back to latitude and longitude. Send lat and lon, or mgrs. Computed by an algorithm, no data. Works from 80 S to 84 N. Check a result against a map before you rely on it to find or reach a place.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude in decimal degrees. Give lat and lon together, or mgrs. | |
| lon | No | Longitude in decimal degrees. | |
| mgrs | No | An MGRS reference, for example 15T WG 00000 49776. Spaces and case do not matter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the description earns credit for what they cannot say: results come from an algorithm rather than a database, 1 m precision, WGS84, and a coverage limit of 80 S to 84 N. The closing caution to verify against a map is genuine accuracy/risk context. Only the error behavior for bad input is missing.
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 conversion and the input modes, and every subsequent sentence carries real constraints (precision, datum, latitude band, verification). 'FREE, no payment' is mild promotional padding that the annotations' title already conveys.
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 3-parameter stateless converter with no output schema, the description covers inputs, precision, coordinate system, and geographic bounds — enough to call correctly. It stops short of stating the return shape or the behavior on conflicting/invalid inputs.
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 each parameter already carries its own description and range constraints. The description reinforces the lat/lon-or-mgrs mutual exclusivity, but adds no format or edge-case detail beyond what the schema states — baseline 3 is correct.
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 (convert) and concrete resource pair (lat/lon ↔ MGRS) in both directions, plus precision and datum. No sibling tool is remotely close, so the agent can identify it instantly.
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 'Send lat and lon, or mgrs', which tells the agent how to drive the two modes. It does not cover the failure cases (what happens if both or neither are supplied, or what happens for out-of-range coordinates), which one sentence would have fixed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NASA/JPL Sentry impact-risk table entries as published. These are computed estimates: the stated probability can easily be inaccurate by a factor of a few, and almost every object listed will not hit Earth. Not an official alerting channel. Free. Unaltered copy of the issuer's own notice with the issuer's name and times; ArrowMem adds no assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| designation | No | An object designation as Sentry lists it, for example 101955. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, and the description goes further with genuinely decision-relevant traits: values are computed estimates that can be off by a factor of a few, almost every listed object will not hit Earth, the content is an unaltered copy with no added assessment. That materially changes how an agent should present results.
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 reliability caveat is front-loaded and the sentences are short and purposeful. There is mild redundancy between 'Unaltered copy of the issuer's own notice' and 'ArrowMem adds no assessment', which restate the same non-endorsement point.
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-parameter, no-output-schema read tool with rich annotations, the description covers what matters about the data's trustworthiness. The one real gap is behavior when designation is not supplied (full table vs. error), which an agent must guess.
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 parameter is documented in the schema with an example, so the baseline applies. The description adds nothing about designation being optional or what the tool returns when it is omitted, so it neither compensates nor regresses.
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 resource (NASA/JPL Sentry impact-risk table entries) and pins the provenance, so an agent can tell what it returns. It omits the retrieval verb and never mentions that the tool can be scoped to a single object by designation, but the resource is unambiguous and no sibling overlaps.
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: it positions itself as a non-alerting reference ('Not an official alerting channel') which steers the agent away from treating results as warnings. There is no explicit when-to-use, no mention of when to omit the designation to get the whole table, and no alternatives named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Environment and Climate Change Canada weather alerts as issued, in English and French, with no change to content or intent. Data Source: Environment and Climate Change Canada. Not an official alerting channel; ArrowMem has no official status. Free. Unaltered copy of the issuer's own notice with the issuer's name and times; ArrowMem adds no assessment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world. The description adds real value beyond that: it is not an official alerting channel, the copy is unaltered, and there is no added assessment — useful trust/provenance context. However, it never says whether returned alerts are currently in effect, how often they refresh, or what an alert record contains.
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 provenance disclaimer is stated three times in different words ('no change to content or intent', 'unaltered copy of the issuer's own notice', 'ArrowMem adds no assessment'), which pads a short description. The data source and status caveat are front-loaded well, but redundancy costs 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?
With no input schema, no output schema, and no coverage of return contents, an agent cannot tell what an alert record looks like (event type, severity, affected region, effective/expiry times) or whether the feed is live. The description spends its budget on legal disclaimers instead of the operational facts needed to use the 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?
The tool takes zero parameters and the description introduces no parameters, so there is nothing to mis-specify. Baseline 4 applies for a parameterless tool.
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 identifies the resource: Environment and Climate Change Canada weather alerts, bilingual, unaltered. The retrieval verb is only implicit (a noun phrase), and the only differentiation from siblings like get_us_weather_alerts or get_space_weather_alerts is the jurisdictional qualifier, not an explicit statement.
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 call this versus get_us_weather_alerts, get_space_weather_alerts, or get_tsunami_messages, and no mention of whether results are current active alerts or an archive. The agent must infer scope from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: get the text of one named section of a federal Act or regulation held in ArrowMem's index. Send the act and the section. Returns the whole section text in English and French, its marginal note and historical note, the Justice Laws Website address, the consolidation date from the published XML, and the notice that this is a reproduction and not the official version. Schedules are not included. You are not charged when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| act | Yes | The federal Act or regulation, by name or citation, for example its short title. | |
| section | Yes | The section number, for example 40(3). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond readOnly/idempotent annotations, the description discloses the paid per-call cost model, the valuable 'not charged when nothing matches' fallback, and precisely what is returned (bilingual full text, marginal and historical notes, Justice Laws URL, consolidation date, reproduction notice). These are behavioral facts an agent cannot infer from structured fields.
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?
Cost ('PAID, per call') is front-loaded in the very first words, and each subsequent sentence contributes either return-content detail or a billing/exclusion caveat. No sentence is filler despite the length.
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 takes on the burden of describing return values and does so thoroughly, plus it covers cost, a refund condition on no-match, and a coverage boundary (schedules). An agent has everything needed to call it correctly and know what it will cost.
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 both parameters are already documented with examples (short title/citation, '40(3)'). The description's 'Send the act and the section' restates rather than extends that, so the baseline of 3 is right.
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 the text of one named section of a federal Act or regulation. Scope is tightly bounded ('one named section', 'Schedules are not included'), and no sibling tool in the list retrieves statutory text, so an agent can select it unambiguously.
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 tells the agent what to supply ('Send the act and the section') and notes the schedule exclusion, which implies when the tool applies, but it never names an alternative or states when not to use it (e.g. versus lookup_canadian_rights or a search tool when the section number is unknown).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent earthquakes from the U.S. Geological Survey ComCat summary feed, from all contributing networks, each credited to its network. Carries the USGS tsunami flag as published; it is not a tsunami forecast. Not an official alerting channel. Free. Unaltered copy of the issuer's own notice with the issuer's name and times; ArrowMem adds no assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| feed | No | Which USGS summary feed. Default 4.5_day. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond the annotations by defining critical behavioral traits: the data source (USGS ComCat), its fidelity ('Unaltered copy,' 'ArrowMem adds no assessment'), and the specific handling of flags ('carries the USGS tsunami flag as published; it is not a tsunami forecast').
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?
While highly detailed, the description is verbose. However, given the necessary legal and operational disclaimers (source, limitations, flag handling), the length is justifiable, but it could be slightly tighter.
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?
Since no output schema is provided, the description is maximally complete. It defines the quality, origin, limitations, and scope of the data package, allowing an agent to understand exactly what the tool returns despite the lack of a specific output schema definition.
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%, setting a baseline of 3. The description does not add specific semantic value to the enum parameters ('significant_day', etc.), as those definitions are contained entirely within the input 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?
The description clearly identifies the tool's purpose as retrieving recent earthquake data specifically from the USGS ComCat summary feed. It distinguishes itself by detailing the scope (all contributing networks) and the nature of the data (unaltered copy).
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 extremely clear usage boundaries by stating exactly when the tool *cannot* be used: it is 'not an official alerting channel,' 'not a tsunami forecast,' and 'adds no assessment.' This prevents misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
NOAA Space Weather Prediction Center scales (G, S, R) and alert bulletins, as issued. Not an official alerting channel, and no alert does not mean calm. Free. Unaltered copy of the issuer's own notice with the issuer's name and times; ArrowMem adds no assessment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds meaningful behavioral context beyond those annotations: it is 'Free,' an 'Unaltered copy of the issuer's own notice,' includes 'the issuer's name and times,' and explicitly states 'ArrowMem adds no assessment.' This is valuable provenance and trust information without contradicting any annotation.
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 compact and front-loads the resource, then layers caveats and provenance. Every sentence contributes useful information, though the phrasing is slightly dense in places.
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, no output schema, and rich annotations, the description is largely complete: it identifies the data source, notes the unaltered copy and lack of assessment, and warns about absence of alerts. It could optionally clarify the return format, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so parameter semantics are not applicable. Per the baseline for zero params, a 4 is appropriate; the description does not need to compensate for missing schema details.
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 resource: NOAA Space Weather Prediction Center scales (G, S, R) and alert bulletins. It is clear this is a retrieval tool, and the name disambiguates it from terrestrial weather siblings, though the text itself does not explicitly differentiate from get_us_weather_alerts or get_canada_weather_alerts.
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 offers a caveat that it is 'Not an official alerting channel, and no alert does not mean calm,' which guides interpretation but not tool selection. It does not state when to use this tool versus alternatives, nor does it list exclusions; usage is only implied by the name and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current tsunami messages from the NOAA tsunami warning centers, as issued. Not an official alerting channel. In Canada, official alerts come from the national alerting system (Alert Ready) and your provincial or territorial emergency authority. Free. Unaltered copy of the issuer's own notice with the issuer's name and times; ArrowMem adds no assessment.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds meaningful provenance and caveats: it is not an official alerting channel, data is an unaltered copy of the issuer's notice, and ArrowMem adds no assessment.
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 front-loaded with purpose and stays reasonably tight. The disclaimer and provenance details are relevant, though slightly verbose for a simple no-parameter retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, no-parameter tool with no output schema, the description supplies enough context about source, scope, provenance, and safety limitations. Nothing essential for correct invocation appears to be 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?
The tool has zero parameters, so there are no parameter semantics to explain. A baseline of 4 is appropriate for a no-parameter tool with complete schema coverage.
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 resource and scope: current tsunami messages from NOAA tsunami warning centers, as issued. This clearly distinguishes the tool from sibling alert tools such as weather, space weather, and earthquake feeds.
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 by 'Current tsunami messages,' but there is no explicit guidance on when to use this versus alternatives. The note about official Canadian alerts adds safety context rather than a usage rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active National Weather Service alerts for one US state or territory code, as issued. A US source: not an official alerting channel, and not for Canadian locations (use the Canada weather alerts tool). Free. Unaltered copy of the issuer's own notice with the issuer's name and times; ArrowMem adds no assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Two letter US state or territory code, for example TX. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the description's value-add is elsewhere: it discloses cost ('Free') and, importantly, the content contract — an 'unaltered copy of the issuer's own notice' with no added assessment by ArrowMem. That provenance and no-endorsement caveat is real behavioral context an agent cannot get from 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?
Scope is front-loaded in the first clause, and the remaining sentences (source caveat, Canadian exclusion, cost, provenance) each add distinct information. It is dense but not padded; a mild run-on in the provenance sentence is the only cost.
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?
No output schema exists, and the description compensates by describing what comes back (issuer's own notice, issuer name and times, unaltered). The one gap is that `area` is not required, yet the description never says what happens when it is omitted (all US? error?). Otherwise complete for a single-parameter read 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 description coverage is 100% and the pattern is documented with an example ('TX'), so the schema carries the parameter burden. The description only restates 'one US state or territory code' without adding format or validation detail. 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+resource+scope: 'Active National Weather Service alerts for one US state or territory code, as issued.' It also explicitly carves itself away from the sibling get_canada_weather_alerts, so an agent can distinguish it 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 excludes Canadian locations and routes to the Canada weather alerts tool, and warns it is 'not an official alerting channel'. It lacks any positive when-to-use framing (e.g., vs. other alert sources like tsunami or space weather), but the exclusion and alternative naming are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: look up Canadian legal information by province. Send a question in plain words and a province code (AB, BC, ON, QC have provincial lines; any other code returns federal lines only). Returns the matching lines of ArrowMem's sourced legal corpus (tenancy, employment, small claims, collisions, being sued, arrest and custody, student loans, VAC and CPP review, caregivers), each with its VERIFIED or RESEARCHED label, its source and URL, the jurisdiction, and English and French text. Legal information, not legal advice. Appeals and family law are not covered. You are not charged when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| province | Yes | Two-letter province or territory code. | |
| question | Yes | Your question in plain words, English or French. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world), and the description layers on material economics and behavior beyond them: 'PAID, per call' and 'You are not charged when nothing matches'. It also discloses the return shape (source, URL, jurisdiction, VERIFIED/RESEARCHED label, EN/FR text) and a liability caveat ('Legal information, not legal advice').
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 pricing warning is front-loaded in the first two words, and the paragraph moves purpose → inputs → outputs → caveats in a sensible order. It is dense and clause-heavy in the middle (the corpus topic list and return-field enumeration), but essentially every clause carries information an agent needs.
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 only two required parameters, no output schema, and rich annotations, the description fills exactly the gaps that remain: cost model, partial-match billing, the provincial-vs-federal resolution rule, result fields, and topical coverage limits. Nothing an agent needs in order to call this correctly and 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%, so the baseline is 3; the description earns above that by explaining behavior the enum cannot: AB, BC, ON, and QC get provincial lines while any other code silently degrades to federal-only results. That is real semantic value an agent could not infer from the 13-value enum, though it adds nothing on the question parameter 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?
The description names a specific verb and resource ('look up Canadian legal information by province') and enumerates the corpus topics covered (tenancy, employment, small claims, etc.), which makes it clearly distinct from the weather, recall, and earthquake siblings. It never names the one genuinely overlapping sibling, get_federal_law_section, so the boundary against statutory-section lookup is left implicit.
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?
It gives clear operating context: send a plain-words question plus a province code, and it states explicit exclusions ('Appeals and family law are not covered'), which prevents wasted paid calls. It stops short of routing the agent to an alternative tool for those excluded topics, so there is no when-to-use-instead guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: look up survey control monuments in Nova Scotia (NS), British Columbia (BC) and Newfoundland and Labrador (NL), by monument id, by a bounding box, or the nearest monuments to a latitude and longitude (up to 25, nearest first, with the distance). Every monument carries its 10 figure military grid reference (MGRS, 1 m precision). Returns id, coordinates, type, condition and assessment date where the province publishes them, with the province's licence and attribution line on every answer. No images are returned. You are not charged when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Nearest search: latitude in decimal degrees. Give lat and lon together, instead of monument_id or bbox. | |
| lon | No | Nearest search: longitude in decimal degrees. | |
| bbox | No | Bounding box in decimal degrees, at most 2 degrees on a side. Give this or monument_id, not both. | |
| limit | No | Nearest search only: how many monuments, nearest first. Default 10, at most 25. | |
| province | Yes | NS, BC or NL. | |
| radius_km | No | Nearest search only: search radius in km. Default and maximum 50. | |
| monument_id | No | The station or monument id, as the province publishes it. Give this or bbox, not both. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial context beyond the annotations: per-call cost, no charge when nothing matches, return fields per province, licence/attribution line on every answer, and the explicit 'no images' constraint. These are exactly the operational facts an agent needs before paying for a call.
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?
Dense but front-loaded: cost and scope first, then modes, then return contents and caveats. Every sentence carries information, though the single long paragraph could be split for easier scanning.
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?
There is no output schema, so the description must explain returns, and it does: id, coordinates, type, condition, assessment date where published, plus licence/attribution and the no-image caveat. For a 7-parameter nested-schema read tool, nothing an agent needs in order to call it correctly 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 baseline is 3, but the description adds real semantic value: nearest-search ordering, the 25-item cap with distance included, and the fact that every result carries an MGRS 10-figure reference. It does not restate the mode-exclusivity constraints, which the schema already handles.
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 ('look up survey control monuments'), names the three covered provinces (NS, BC, NL), and enumerates the three lookup modes. An agent can distinguish this from unrelated siblings immediately, and the MGRS detail ties it loosely to convert_mgrs without ambiguity.
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?
Clearly enumerates the three selection paths (monument id, bounding box, nearest to lat/lon) and the 25-result nearest-first behaviour, which tells an agent which mode to pick for which question. It does not name sibling alternatives or exclusions (e.g., when to use convert_mgrs instead), which is why it stops short of 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: search the Government of Canada's published CanadaBuys tender notices by keyword, procurement category, region and closing date range (give at least one). Returns up to 10 matches, each with reference and solicitation number, English and French title, publication and closing dates, status, category, notice type, procurement method, regions, the buying organization, goods and services descriptions and the notice address, plus the total matched, the data date and the attribution. Contact names, emails and phone numbers in the notices are not returned. This is not the official notice, and a notice can change or close after the data date. You are not charged when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | A region name as CanadaBuys publishes it, for example Ontario or National Capital Region. Matches regions of opportunity and of delivery. | |
| keyword | No | Words to find in the notice title, buyer and goods or services description. Every word must appear. | |
| category | No | The procurement category as the notice publishes it. | |
| closing_to | No | Closing date on or before this date, YYYY-MM-DD. | |
| closing_from | No | Closing date on or after this date, YYYY-MM-DD. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive, but the description adds substantial context beyond them: it discloses cost per call, the maximum of 10 matches, the exact return fields, that contact names/emails/phones are excluded, that it is not the official notice, and that notices can change or close after the data date. This is exactly the kind of behavioral detail an agent needs to call the tool responsibly.
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 front-loaded with the cost and action, followed by return details and caveats. Every sentence carries useful information, though the first sentence is long and dense. It could be slightly more structured, but there is no filler or repetition.
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 fully explains the return shape: up to 10 matches, the fields included, total matched, data date, and attribution. It also covers cost, exclusions, and data freshness caveats. Combined with the annotations, an agent has everything needed to call and interpret the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema itself documents all five parameters thoroughly. The description adds one important semantic not present in the schema: 'give at least one' filter is required even though all parameters are technically optional. It also enumerates the filter types, reinforcing their purpose. The baseline is 3 when schema coverage is high, but the added constraint lifts this to 4.
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 opens with a specific verb and resource: 'search the Government of Canada's published CanadaBuys tender notices'. It names the exact filters (keyword, procurement category, region, closing date range), so an agent can immediately understand what the tool does. Sibling tools are unrelated, but the purpose is still sharply distinct.
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 a clear usage constraint: 'give at least one' of the filter parameters. It also notes the tool is 'PAID, per call' and that 'You are not charged when nothing matches', which helps an agent decide when to invoke it. There are no explicit exclusions or named alternatives, but the sibling set contains no overlapping tools, so 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.
PAID, per call: look up a federally incorporated corporation by name or by corporation number, in Corporations Canada's published Federal Corporations data. Returns up to 10 matches (exact name first, then names that start with it, then names that contain it; active first), each with corporation number, business number, name, governing Act, status, the anniversary and last filing dates, the registered office address and the minimum and maximum number of directors, plus the total matched and the attribution. The address is shortened to city, province and the first three characters of the postal code for every corporation. Director names are not included. This is not the official record. You are not charged when nothing matches.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | A corporate name, or part of one. Give this or corporation_number, not both. | |
| corporation_number | No | The federal corporation number, digits only or with a hyphen before the check digit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond annotations: discloses per-call cost, the free-on-no-match policy, the 10-result cap with explicit ranking order (exact, prefix, contains; active first), address truncation to city/province/three postal characters, exclusion of director names, and that results are not the official record. These are exactly the behavioral facts an agent cannot get from readOnly/idempotent hints.
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 cost warning is correctly front-loaded as the first two words, and every clause conveys new information (coverage, ordering, fields, truncation, caveats). It runs as one long paragraph rather than grouped lines, which slightly hurts scannability.
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?
There is no output schema, so the description carries the full return-value burden and does so thoroughly: every returned field is enumerated in order, along with totals, attribution, and the known limitations (no directors, truncated address). An agent can call this and interpret the response correctly without further 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%, including the 'give this or corporation_number, not both' constraint, so the description only restates the two lookup modes without adding format or matching semantics beyond the schema. Baseline 3 is appropriate when the schema already carries the parameter detail.
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 ('look up a federally incorporated corporation') plus the exact dataset ('Corporations Canada's published Federal Corporations data') and the two lookup keys. No sibling tool covers corporation data, so no disambiguation is needed, and the scope is unambiguous.
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?
Makes clear this is a paid, per-call lookup and that unsuccessful lookups are free, which is the key decision input a caller needs. It also implicitly routes the agent to either a name or number query, though it does not name any alternative tool or state exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: search Health Canada's published Recalls and Safety Alerts open data by keyword, category, recall id and date range (give at least one). Returns up to 10 notices, each with the dates of the data. You are not charged when nothing matches or when the data is out of date.
| Name | Required | Description | Default |
|---|---|---|---|
| date_to | No | Notice date on or before this date, YYYY-MM-DD. | |
| keyword | No | Words to find in the title, product, category and issue. Every word must appear. | |
| category | No | A category as the notice publishes it, for example Food or Medical device. | |
| date_from | No | Notice date on or after this date, YYYY-MM-DD. | |
| recall_id | No | The notice id exactly as published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses critical behavior: paid per-call billing, a cap of up to 10 notices, and no charge on no-match or stale-data outcomes. These are non-obvious operational facts an agent cannot derive from annotations or schema.
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 tight sentences with pricing and the at-least-one requirement front-loaded, followed by the return shape and billing exception. No wasted text.
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 shoulders return-value explanation and does state up to 10 notices with dates, plus billing outcomes. It could still be richer about the fields each notice contains, but for a search tool it is largely sufficient.
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 per-field semantics baseline is a 3. The description earns above baseline because the schema marks all five parameters optional, and the description adds the crucial 'give at least one' constraint that the schema does not encode.
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) against a precisely named resource (Health Canada's published Recalls and Safety Alerts open data) and enumerates the filterable dimensions. This clearly distinguishes it from siblings like search_us_fda_recalls and search_vehicle_recalls_canada.
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 constraint 'give at least one' filter is a genuine usage rule that prevents empty scans. However, it does not explicitly name when to prefer this over alternatives such as search_us_fda_recalls, leaving that to the resource scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: search the U.S. Food and Drug Administration's published enforcement reports (food, drug and device recalls) by domain, classification, recalling firm, recall number, keyword and report date (give a firm, a recall number, a keyword or a since date). Returns up to 10 recall rows with the dates of the data and the FDA address for the full report. Remedy text is not included. You are not charged when nothing matches or when the data is out of date.
| Name | Required | Description | Default |
|---|---|---|---|
| firm | No | Words of the recalling firm's name. | |
| since | No | Report date on or after this date, YYYY-MM-DD. | |
| domain | No | Which enforcement report: food, drug or device. | |
| keyword | No | Words to find in the firm, product and reason. Every word must appear. | |
| recall_number | No | The FDA recall number exactly as published, for example F-0123-2026. | |
| classification | No | The FDA recall class. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description goes well beyond them: it discloses per-call cost, the no-charge conditions (no match or stale data), a hard cap of 10 rows, the absence of remedy text, and that results carry data dates plus an FDA address. These are exactly the traits an agent cannot infer from structured fields.
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?
Cost and scope are correctly front-loaded in the first clause, and the sentences carry real information about output limits and omissions. The enumeration of faceted filters partially repeats what the schema already lists, which is the only waste.
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 describe returns and it does (up to 10 recall rows, dates, FDA address, no remedy text). It leaves open whether 10 is a hard ceiling with no pagination path and never states the consequence of calling with zero filters, which is a real gap for a 6-optional-parameter 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 description coverage is 100% and each parameter already carries format, enum and matching rules, so the schema does the heavy lifting. The description's filter list mirrors the schema property names without adding matching semantics beyond it, so the baseline of 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?
Specific verb plus specific resource ('search the U.S. Food and Drug Administration's published enforcement reports') with a parenthetical scope of food, drug and device recalls. The retrievable facets are enumerated, and the resource is unambiguously distinguished from the sibling 'search_health_canada_recalls'.
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 parenthetical '(give a firm, a recall number, a keyword or a since date)' sets an implicit precondition that at least one narrow filter should be supplied, and the billing rules tell the agent when a call costs money. It stops short of naming a sibling alternative or an explicit 'do not use when' case, so it is clear but not fully routing-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID, per call: search Transport Canada's Vehicle Recalls Database, full monthly file, by make, model, model year, recall number and keyword (give a make, a recall number or a keyword). Returns up to 10 recall rows, each with the dates of the data. The database leaves out inconsequential recalls. Remedy text and VINs are not included. You are not charged when nothing matches or when the data is out of date.
| Name | Required | Description | Default |
|---|---|---|---|
| make | No | The vehicle make as Transport Canada publishes it, for example FORD. | |
| year | No | The model year. | |
| model | No | The model name or a word of it, for example F-150. | |
| keyword | No | Words to find in the make, model, system and defect text. Every word must appear. | |
| recall_number | No | A Transport Canada or manufacturer recall number exactly as published. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial operational context beyond the annotations: paid per call, up to 10 rows returned, monthly file freshness, omitted inconsequential recalls, omitted remedy text and VINs, and no charge when there are no matches or stale data. These are meaningful behavioral traits not covered by the read-only/idempotent 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 dense and front-loaded, beginning with 'PAID, per call' and then covering scope, input guidance, return limits, exclusions, and billing exceptions. Every sentence contributes operational information without repetition.
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 paid search tool with no output schema, the description covers cost, result limits, data freshness, exclusions, and billing exceptions well. It only partially describes the returned row structure beyond saying each row includes dates, so there is a small gap for output expectations.
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 the per-parameter definitions already carry most semantics. The description still adds a useful cross-parameter constraint: the caller should provide a make, recall number, or keyword, which is not obvious from the schema alone since zero parameters are marked required.
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: search Transport Canada's Vehicle Recalls Database by make, model, model year, recall number, and keyword. It clearly distinguishes this tool from sibling recall searches such as search_health_canada_recalls and search_us_fda_recalls by naming the Canadian vehicle domain.
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 instruction 'give a make, a recall number or a keyword' establishes a minimum identifying input, and 'PAID, per call' plus the no-charge conditions give useful context for when to invoke it. However, it does not explicitly compare this tool with sibling recall or lookup tools, so the alternatives guidance is incomplete.
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_recent_earthquakes1 field changedInput schema / properties / feed / descriptionPrevious value: -"Which USGS summary feed. Default significant_day."New value: +"Which USGS summary feed. Default 4.5_day."check_exposed_servicescheck_ollama_hardeningcheck_ollama_loopbackconvert_mgrsdisable_alert_relayenrol_alert_relayget_arrowbridge_infoget_asteroid_impact_riskget_canada_weather_alertsget_data_dignity_standardget_federal_law_sectionget_hardening_guideget_org_infoget_privacy_modelget_recent_earthquakesget_space_weather_alertsget_tsunami_messagesget_us_weather_alertsget_verified_business_factsinventory_ai_agentslist_packslookup_canadian_rightslookup_survey_monumentsrotate_alert_relaysearch_canadabuys_tenderssearch_federal_corporationssearch_health_canada_recallssearch_us_fda_recallssearch_vehicle_recalls_canadacheck_exposed_servicescheck_ollama_hardeningcheck_ollama_loopbackdisable_alert_relayenrol_alert_relayget_arrowbridge_infoget_data_dignity_standardget_hardening_guideget_org_infoget_privacy_modelget_verified_business_factsinventory_ai_agentslist_packsrotate_alert_relayPay-per-call US public data for agents: recalls, weather, climate, SEC filings. x402 USDC on Base.
Pay-per-call tools for AI agents: product photos, documents, web pages, data. USDC via x402.
Pay-per-call APIs for AI agents: queries, storage, ads. Billed in USDC via x402.
Paid data tools for AI agents, pay per call in USDC via x402: AI visibility, company enrich, SERP
Add one secure layer between your agents and this server.