OpenNodes

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the read-only and idempotent annotations, it discloses that no invocation or charge occurs and that results are cost bounds rather than a single guaranteed price. It also explains the practical significance of the returned pinned card_revision: making an estimate enforceable at invocation.

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 tool’s purpose, then efficiently covers inputs, outputs, use cases, and side-effect safety. Every sentence contributes operational information without unnecessary background 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?

Despite the detailed nested schema, the description supplies the mental model needed to invoke the tool and interpret its results: ordered chain steps, per-step USD bounds, enforceable revisions, and totals. The absence of an output schema is mitigated by this explicit return-value summary, while the schema documents the detailed filters and constraints.

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 description usefully summarizes the step shape—either a concrete offering or a select query, plus token estimates—but this largely repeats the fully documented schema. It adds no further guidance on estimating token counts, selection tie-breaking, or other parameter behavior, so the high schema coverage leaves this at the baseline.

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?

“Pre-price an invocation chain” states a specific action and resource, while “compare routes or budget a multi-model pipeline” clarifies its planning role. This clearly distinguishes cost estimation from the discovery- and recommendation-oriented sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit timing (“BEFORE spending money”) and concrete use cases: comparing routes and budgeting a pipeline. “Nothing is invoked or charged” also supplies a clear when-not boundary by ruling out use for execution or payment.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the read-only, open-world, idempotent profile, and the description adds substantive context beyond them: data provenance (node cards, imported catalogs, curated location seeds), the evidence ladder, inclusion of sites whose provider publishes no model list (with a note), and placeholder geo points marked `derived`. It also flags that country-only sites are dropped by distance filters, which is exactly the kind of caveat an agent cannot infer 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?

It is front-loaded with the resource and its fields, then pivots to usage, which is the right order. The single dense paragraph with stacked parentheticals is heavy to parse, and the phrase 'Built from node cards, imported catalogs and curated location seeds' is the least load-bearing sentence, but nothing is truly redundant.

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 usefully enumerates the returned fields (evidence basis, source, geo with precision, models served) and warns about derived/placeholder points, which is what an agent needs to interpret results. For a 9-parameter, zero-required filter tool it is nearly complete; only the relationship to find_residency is left unstated.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter descriptions are already detailed (evidence ordering, residency strengths, availability tiers), so the schema carries most of the semantic load. The description contributes mainly by demonstrating parameter combinations in its example queries ('gpt-oss within 500 km of Montréal' implies near + within_km + model), which is a modest addition rather than new parameter meaning.

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 opening clause names a specific resource and scope ('every known serving site ... provider, region, city or facility, live or planned') and enumerates the attributes returned (evidence basis, source page, geo point, models served). This is clearly a location/site lookup, distinct from search_offerings (offerings) and find_residency (commitments), so an agent can route without opening the 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?

It gives concrete trigger questions ('which providers serve which models in Canada', 'what serves gpt-oss within 500 km of Montréal') and an explicit follow-up route: use search_offerings with `region` to pick an offering. The gap is that it also claims to support 'check a residency requirement' without acknowledging the sibling find_residency, leaving ambiguity about which of the two to call for residency questions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. Beyond that, the description discloses the semantic model of commitment levels (processing vs storage vs none vs unstated) and notes that routers and providers with no known sites are included — valuable context a caller could not infer 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?

Content is well front-loaded with purpose first and usage second, but the opening sentence is a long comma-chained enumeration that is dense to parse. No sentence is wasted, though the field list could be tightened.

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 content and does so thoroughly: commitment level, region coverage, availability tier, programme name, statement, and source page with check date. That is sufficient for an agent to call it correctly without further documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining the commitment taxonomy, which clarifies what filtering by `commitment` actually selects. It also frames the tool's output fields (region codes, availability classes), useful orientation even though it does not detail each parameter's syntax.

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 statement — what each AI provider officially promises about where prompts, outputs and stored data stay — and enumerates the returned fields (commitment level, region codes, availability, programme, source page). It is clearly distinguishable from sibling tools like find_locations and search_offerings.

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 a concrete triggering question ('which providers keep data in the EU by default') and explicitly routes follow-up work to find_locations or search_offerings with `region`. Alternatives and sequencing are named rather than inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description goes beyond them by disclosing the returned payload in detail — trust-tier history with reasons, probe results with an availability summary, offerings with window and price — which is the useful behavioral context here since there is no output schema. It does not mention auth requirements or result-size limits, so it stops short of a 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?

Front-loaded with the payload inventory, then usage and the sibling pointer, in two sentences with no filler. The first sentence is a dense compound list, but every clause names a returned field and 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?

No output schema exists, so the description carries the full burden of describing returns — and it does so comprehensively while also routing to sibling tools. An agent has everything needed to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (node_id format, offering_limit cap) are fully documented in the schema. The description adds only the provenance of node_id, which the schema does not state — marginal but real value, so the baseline 3 holds.

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 (get one node) and then enumerates exactly what the record exposes: operator, regions, endpoints, hardware, trust tier and its history, probe results, offerings. It also names the sibling it is not (get_offering) so an agent can distinguish it without opening a 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?

Explicit when-to-use ("vet a provider before relying on it"), an explicit input source ("take node_id from search_offerings, recommend or get_offering results"), and an explicit alternative for the adjacent case ("For one offering's full card, use get_offering"). Nothing is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint and idempotentHint, so safety is covered without the description. The description goes further by enumerating the richness of the payload, including live 'registry's observed probe results', which tells the agent this is a heavy, authoritative retrieval rather than a cached summary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler, with the payload summary front-loaded and the input-sourcing instruction second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so by listing the exact facets an agent would want (endpoints, pricing, context window, languages, hardware, data policy, trust tier, probe results). Nothing needed to invoke or interpret the tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and both parameters carry examples, so the baseline is 3. The description adds provenance the schema cannot express — that node_id/offering_id must come from search_offerings or recommend output — which meaningfully reduces wiring mistakes.

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+resource ('Full detail for one offering') followed by an explicit inventory of what that detail contains (endpoints, pricing, serving capabilities, data policy, trust tier, probe results). The singular 'one offering' naturally contrasts with the plural sibling search_offerings.

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 instructs where to source the inputs ('Take node_id and offering_id from search_offerings or recommend results'), which routes the agent correctly relative to those siblings. It does not, however, state any when-not condition or what to do if the ids are unknown/invalid.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint/openWorldHint/idempotentHint; the description adds real context beyond them, notably that `task` text is sent to the registry but discarded after feature extraction, while `features` keeps the prompt private, and that the cost estimate is pinned to the node's card revision. It does not cover latency, rate limits, or failure modes (e.g. what happens when no candidate satisfies the policy), which keeps it off a 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?

Front-loaded with the purpose, then usage, then input/return behavior, then alternatives — a sound order with no filler sentences. The prose is dense with inline code references and a long first sentence, which costs a little readability but not much.

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 return-value burden and does: ranked candidates with score components, a pinned cost estimate, an optional cheaper two-step scenario, and predicted MCP tool categories. Privacy handling and default behavior for local memory are also disclosed, which is what an agent needs for a 4-param recommendation 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%, so baseline is 3; the description goes further by explaining the privacy semantics of choosing `task` versus `features` and naming the extractFeatures source, which is meaning the schema does not convey. It says nothing extra about `policy`, `est_output_tokens`, or how the two inputs interact when both are supplied, so it is not exhaustive.

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?

"Recommend the best AI node + model for a task" states a specific verb and resource, and the closing sentence explicitly separates this tool from search_offerings (browsing) and estimate (pricing a chain). An agent can route between the three siblings without opening any 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?

"Use this first when you know the task but not the model" gives an explicit entry condition, and the alternatives are named with the conditions that select them: search_offerings to browse, estimate to price a specific chain. Both the task-vs-features input paths are also framed as choices (privacy tradeoff).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered; the description adds genuinely new context: the multi-source registry scope, AND semantics for filters, and the exact return envelope { offerings, total, counts }. It stops short of stating pagination or rate-limit behavior, which is why it is not a 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?

Front-loaded with purpose and source scope, then the return shape, then sibling routing — a sensible priority order. It is dense but nearly every clause earns its place; the parenthetical source list and the return-field enumeration are the only slightly heavy stretches.

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 17-parameter, zero-required-parameter tool with no output schema, the description does the important compensating work: it enumerates the return fields (pricing, trust tier, capabilities, probe results, rank explanation) and states totals/counts. Per-parameter meanings are left entirely to a very thorough schema, which is acceptable here but keeps it short of a 5.

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 carries parameter detail and 3 is the baseline. The description still adds meaning beyond it by declaring that optional filters combine with AND and by explaining that `limit` truncates results while `total` still reflects every match — a cross-parameter behavior the schema cannot express.

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?

Opens with a specific verb and resource ("Search AI inference offerings") and immediately scopes it to two source classes: registered nodes AND imported catalogs (OpenRouter, Hugging Face, models.dev, local nodes). It also names the two sibling tools that serve different intents, so an agent can tell search from get_offering and recommend without opening a 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?

Gives explicit routing ("Use get_offering for one offering's full card, recommend to let the advisor choose") and states the filter combinatorics ("All filters are optional and combine with AND"). It lacks an explicit when-not statement such as how it relates to find_locations/find_residency for pure geography questions, but the core selection guidance is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.