The Dutch Directory

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

Annotations already declare this a read-only, idempotent, non-destructive lookup on a closed world, so the safety profile is covered. The description adds useful return behavior: it gives the nearest option when nothing is local, returns the embassy/consulate for the civic exam, and returns the alternative country when the exam isn't held there. It does not describe pagination or result shape, which keeps it below 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 what it covers, then parameters, then usage trigger — a sensible order. The middle sentences are dense and run long (nested parentheticals about CNaVT/inburgering), but every sentence carries information and nothing is 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 and no annotation detail about return values, the description takes on the return-value burden and largely succeeds, explaining what the tool yields in the local, nearest, embassy and no-arg cases. Minor gaps remain around exact output fields, but an agent has enough 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 coverage is 0%, so the description must carry both parameters. It does: 'capital' is exemplified with Tokyo, 'country' with the ISO code JP, and the no-argument case is described as listing the capitals with a local option. Format and accepted value types are fully conveyed.

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: it finds Dutch courses, university departments, CNaVT exam centres and Dutch schools for children within 40 km of a capital, plus the civic-integration exam location abroad. An agent can tell exactly what this tool returns (a lookup, not a search across the general corpus) and distinguish it from unrelated siblings like tdd_tutors or tdd_move_plan.

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 states when to use it ('someone lives outside the Netherlands and Belgium', or asks about Dutch classes/CNaVT/inburgering/Dutch schools abroad) and how to invoke it (capital like Tokyo, ISO code like JP, or no arguments to list eligible capitals). This is explicit when-to-use and argument-selection guidance.

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, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that the index is Dutch/Flemish-scoped and that gaps are reported per provider type, but it says nothing about result shape or how missing entries are determined.

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, front-loaded with what is returned and followed by the reason to use it. Slightly convoluted phrasing ('Which provider types a Dutch or Flemish city lacks') but no wasted 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 one-parameter, read-only lookup with no output schema, the description conveys both the query target and the meaning of the result. Only the concrete return shape (list vs. count) 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 0%, so the description must carry the load for the single 'city' parameter — and it does constrain the domain to Dutch or Flemish cities, which is real semantic guidance beyond the bare string type and length bounds.

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 resource and scope: provider types that a Dutch or Flemish city lacks in the index. An agent can tell this apart from the sibling search/stats tools, though no sibling is named 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?

The second sentence hints at why the result matters ('to explain when to look online or in a nearby city'), which implies the usage context but does not state when to call this tool versus tdd_search or tdd_abroad. Usage is inferred, not directed.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavior context by revealing the output is a plain-language verdict rather than raw data, but it says nothing about invalid-slug handling or whether the two inputs must be the same entity type.

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: the first defines the operation and output, the second gives the usage timing. Nothing is redundant and the essential information is front-loaded.

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

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

With no output schema, the description appropriately characterizes the return value as a verdict; with two fully undocumented required parameters, it supplies their semantic form (slugs). The remaining gap is error/mismatch behavior, which is minor for a read-only two-slug comparison.

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 0%: 'a' and 'b' are bare strings with only length constraints, so the description must carry the meaning. It does partially compensate by stating inputs are slugs referencing schools, apps or tutors, but it never maps a/b to first/second option, nor does it require the two to be the same entity type.

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 (side-by-side comparison) and resource (two schools/apps/tutors) plus the input form (by slug) and output form (plain-language verdict). It is clearly distinguishable from siblings like tdd_search or tdd_shortlist, which surface candidates rather than judging two of them.

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 when to use it: 'after a search or shortlist when someone is choosing between two,' which ties it to the search/shortlist workflow. It stops short of naming when NOT to use it (e.g., comparing more than two, or comparing a mix of entity types), so it is clear context without exclusions.

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=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that the content is a policy statement (implying static, non-personalized output) but discloses nothing extra about determinism, versioning, or scope of the policy beyond what the annotations imply.

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 no filler: the what comes first, the when comes second. The opening clause is slightly dense (a single sentence carrying two distinct policy claims) but nothing is wasted or 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 parameters, no output schema and simple read-only annotation coverage, the definition supplies what an agent needs: what the tool returns and the question that should route to it. Only marginal gaps remain, such as whether the response is the policy text itself or a pointer to it.

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

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

The tool takes zero parameters, so per the baseline this scores 4; there is nothing for the description to disambiguate. The schema correctly declares additionalProperties=false with an empty properties object, and the description makes no misleading claims about inputs.

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 resource — the public disclosure policy governing when Dutch Fluency products appear in results and how independent alternatives are guaranteed. That is far clearer than the cryptic tool name tdd_conflict_ledger, though the description never explicitly contrasts itself with the tdd_meta or tdd_evidence_pack siblings.

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 it when someone asks whether the directory is independent" gives an explicit, concrete trigger condition. It offers no exclusions or named alternatives, but for a single-purpose static-content tool the positive guidance is sufficient.

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 read-only, idempotent, non-destructive, closed-world behavior. The description adds meaningful scope by enumerating the signals returned and contrasting them with provider claims, which is useful context beyond the annotations.

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

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

Three tight sentences: the first defines the output, the second differentiates scope, and the third states usage. Nothing is redundant and the core definition is front-loaded.

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

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

For a zero-parameter, read-only diagnostic tool with rich annotations, the description covers what the tool reports and when to use it. It could specify the output shape more explicitly, but no output schema exists and the signal list gives sufficient context.

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 are no parameter semantics to document. Per the rubric, a zero-parameter tool has a baseline of 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 specifies the tool surfaces data-quality signals in the index, naming concrete examples (stub names, missing prices or lesson counts) and explicitly scoping it as scrape health rather than provider claims. It stops short of naming any sibling tool, so sibling differentiation relies on 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?

It gives a direct usage condition: 'Use it only for maintenance or data questions,' and excludes provider claims. However, it does not identify which sibling tool to use for other data queries, so an agent still has to infer alternatives.

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?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context that the output is a planning range rather than a quote, but it does not describe calculation assumptions, currency, or return format.

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 efficient sentences, with the important 'not a quote' qualifier front-loaded. Every sentence contributes to understanding what the tool does and when to use it, though further structure or detail could still fit without becoming bloated.

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 budget-estimation tool with no output schema and zero schema-level parameter descriptions, the description is thin. It omits output format, currency, calculation basis, and parameter semantics, leaving the agent with significant unanswered questions before invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It merely enumerates the four inputs (headcount, months, track, cities) without explaining units, allowed values, or how cities and track affect the estimate, adding almost nothing beyond the schema's property names.

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: planning ranges for Dutch training for a team, built from headcount, months, track and cities. The 'not a quote' qualifier helps distinguish this from a quoting tool, though no sibling tool is named to differentiate it 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?

It gives a clear use case: 'Use it for HR or employer questions about cost.' It also provides an implicit when-not by saying 'not a quote', steering agents away from treating the result as binding pricing. No alternative tool is named for related cases.

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety behavior is covered structurally. The description adds useful context about the artifact's shareability and a legal disclaimer, but says nothing about output format, generation semantics, or how the pack is delivered.

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, front-loaded with the artifact description and a brief boundary statement. No wasted words, though the parenthetical input list is somewhat redundant with the schema.

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 and zero parameter documentation, the description should explain what the pack contains and how it is produced, but it does not. It is under-specified for a tool whose name implies a generated deliverable.

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 0% across 4 parameters, so the description must compensate and largely does not — it merely names the fields (name, city, goal, weeks) without any format, constraint, default, or validation meaning. The schema's maxLength and weeks 1-104 bounds are left entirely undocumented in prose.

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 identifies the artifact produced (an independent study plan evidence pack) and enumerates the inputs in parentheses, but uses a noun phrase rather than a verb+resource, so it's unclear whether the tool generates, retrieves, or composes the pack. Sibling tools like tdd_move_plan and tdd_path are not distinguished from it.

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 guidance, no exclusions vs. the 14 sibling tools, and no prerequisites. The only boundary stated is the 'Not legal advice' disclaimer, which is about liability, not tool selection.

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, destructiveHint=false and a closed world, so the safety profile is covered. The description usefully adds that a snapshot is returned and that slim=true degrades the payload to counts and types, but says nothing about size, freshness or permissions.

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 zero filler; the core payload description comes first, the slim mode second, and the usage constraint last. 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 does some of the work by naming the entity types and hinting at edges via 'how they connect', but it never sketches the return shape (nodes/edges, key names) or bounds on response size. Adequate for a read-only snapshot, but an agent cannot predict the payload structure.

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 single parameter has 0% schema description coverage, so the description carries the full burden — and it does, explaining exactly what slim=true changes (counts and types only versus full graph). This is meaning an agent could not get from the bare boolean.

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 resource (the Dutch Learning Graph) and enumerates its contents — providers, exams, goals and their connections — so an agent knows what comes back. It rules out a use case (recommendations), but does not distinguish itself from siblings like tdd_stats or tdd_meta that may also return aggregate data.

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 to use it for data or research tasks and not for recommendations, which gives both a when and a when-not. It stops short of naming the alternative tool an agent should reach for instead when it wants recommendations.

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 destructiveHint=false, so safety is covered. The description adds the useful fact that the response is a content/payload overview (counts, doctrine, endpoint URLs), which annotations do not convey. It stops short of describing response shape or stability guarantees.

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, zero filler, and the payload overview is front-loaded ahead of the call-when guidance. 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 parameters, no output schema, and full annotation coverage, the description is the sole source of return-value information and it does name the returned content (counts by type, Verified Pro count, doctrine, endpoint URLs). It could say more about shape or freshness, but it is sufficient for a zero-arg 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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly adds no fictitious parameter guidance.

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+resource: it returns what the directory covers, namely listing counts by type, the Verified Pro count, doctrine, and endpoint URLs. That is a concrete payload description that separates it from search/stat siblings. It lacks only explicit sibling differentiation in wording.

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 clear trigger: 'Call it when you need to know the scope of the directory before searching.' This establishes the when and implies the relationship to tdd_search. It does not name when not to use it or list alternatives beyond the search reference.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety and side-effect profile is well covered. The description adds useful domain context by naming the planned outputs (courses, exam booking, tutor hours), but it does not disclose return format, permissions, or other behavioral traits beyond what the annotations provide.

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

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

Two tightly written sentences with the core action front-loaded and the usage condition following immediately. No extraneous text; each sentence serves a purpose.

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

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

For a simple read-only planning tool with no output schema, the description gives a reasonable sense of what the tool computes and when to use it. However, it leaves the city and goal parameters unexplained, which is a meaningful gap given the 0% schema coverage on those 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 description coverage is 0% for three parameters. The description clarifies the date concept (arrival, inburgering or exam date), but it does not explain the city or goal parameters at all. With no schema descriptions, it only partially compensates for the missing parameter documentation.

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 planning action: working backward from an arrival, inburgering or exam date to what to start when, including courses, exam booking and tutor hours. It clearly defines the resource and output focus. It does not, however, distinguish this tool from any of the similarly named 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?

It gives a clear use condition: 'Use it when someone has a fixed date.' This tells the agent when the tool is appropriate. It stops short of naming exclusions or alternative sibling tools for cases where no fixed date exists.

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/non-destructive, so the safety profile is covered. The description adds real behavior beyond them: output is a per-week plan, it is not a stateful tracker, and 'practice links to Dutch Fluency always come with alternatives' discloses a deliberate content guarantee about the returned links.

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

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

Three sentences, zero padding, and the core deliverable is front-loaded before the usage trigger and the exclusion. The closing clause about Dutch Fluency is narrow but earns its place as a behavioral guarantee.

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 does sketch the return shape (a week-by-week path of real courses, tutors, apps and trials) and scopes out progress tracking. It remains thin on input value formats and does not say whether any parameter is effectively needed despite zero required fields, but nothing critical for a safe, informed call 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 0% across five parameters, so the description must carry the load. It does map semantic meaning onto each input ('city, goal, current level, weekly hours and deadline'), and 'deadline' usefully clarifies that move_or_exam_date accepts either a relocation or exam date. However it gives no value formats or ranges (level vocabulary, date format, hours bounds), leaving the agent to guess.

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 deliverable: a 'week-by-week study path' that 'points to real courses, tutors, apps and trials' for enumerated inputs. It partially differentiates from siblings by ruling out one adjacent function ('Not a progress tracker'), though it never names tdd_move_plan or tdd_shortlist, which is where an agent would look first.

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 it when someone asks how to get from one level to another or how to prepare for an exam' gives concrete trigger scenarios, and 'Not a progress tracker' supplies one explicit exclusion. It stops short of naming an alternative tool for the excluded case, so the routing is clear but not complete.

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 safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lowered. The description still adds value beyond them by disclosing the return shape — 'Each result has directory_url and primary_url to cite' — which is useful because no output schema exists. It says nothing about pagination, limits or ranking, so 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?

Three sentences, front-loaded with purpose and usage before the filter inventory. The filter sentence is dense but each listed name maps to a real parameter, so it earns its length; only the slightly breathless filter dump keeps it from a 5.

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 10-parameter, zero-required, no-output-schema search tool, the description supplies purpose, trigger, filter inventory and result fields — enough to call it correctly. Gaps remain on the free-text q parameter and the limit cap, which are left entirely to the schema.

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 0%, so the schema only exposes names and types, and the description has to carry the load. It documents 8 of 10 filters and adds real semantics — 'city (Dutch or Flemish, e.g. Utrecht, Den Haag, Antwerpen)' and 'goal (e.g. inburgering, NT2, business, conversation)'. It leaves q and limit unexplained, so it falls short of full compensation.

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 enumerates the resource classes it covers (schools, universities, apps, podcasts, exams, online tutors), so the agent knows exactly what it returns. It does not name any sibling, though the breadth claim 'every way to learn Dutch' implicitly separates it from the narrower tdd_tutors, keeping it 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?

Gives an explicit trigger: 'Use it when someone asks where or how to learn Dutch.' That is a clear when-to-use condition, but there is no when-not guidance and no routing to alternatives such as tdd_tutors, tdd_shortlist or tdd_compare.

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 a safe read-only, idempotent, closed-world operation, so the safety profile is covered. The description adds genuinely non-structured behavior: ranking is by editorial fit and explicitly not paid, and a 'Dutch Fluency item' always ships with independent alternatives. The latter is a useful disclosure although its terminology goes unexplained.

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

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

Three tight sentences, front-loaded with the deliverable and the ranking rule, then the routing cue. The final sentence about Dutch Fluency is cryptic and slightly opaque, but it is short and carries a real behavioral fact.

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 and all 6 parameters are undocumented, and with 0 required params an agent could invoke it blind. The description covers the concept and ranking basis but leaves the meaning of kind/type/limit/verified_pro and the 'Dutch Fluency' clause unexplained.

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 0% across 6 parameters, so the description must compensate and largely does not. Only 'city' and 'goal' are reflected in the text; kind (with its all/provider/tutor enum), type, limit, and verified_pro are left completely undefined.

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 deliverable: a short list of best-fit options for a city and goal, ranked by editorial fit score. It implies a contrast with a broader search tool ('a few recommendations rather than every option') but never names tdd_search, so sibling differentiation is inferred rather than explicit.

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 it when someone wants a few recommendations rather than every option' gives a clear selection condition. No alternative tool is named and no exclusion beyond the search-style case is stated, so it stops short of full routing guidance.

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, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a behavioral trait not in the annotations — that the numbers are 'Live' — which tells the agent the data is current rather than cached. Where the returned data comes from or how fresh is still unspecified.

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

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

Two sentences with zero waste: the payload of metrics is front-loaded, then the usage condition. Nothing is padded or 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?

For a no-argument, read-only statistics tool with no output schema, the description adequately enumerates what comes back and when to reach for it. It could add a note on the data source or snapshot period, but nothing essential to invoking it 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?

The tool takes zero parameters, so there are no parameter semantics to document; the baseline for a no-arg tool is 4. The description correctly implies no input is required by framing this as a whole-market snapshot.

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 resource (market statistics) and enumerates the actual metrics returned — listing counts, Verified Pro rates, median tutor prices. This is concrete rather than tautological, though it only implies sibling differentiation via 'as a whole' rather than naming the narrower tools like tdd_city_gaps or tdd_tutors.

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 to use it 'for questions about the Dutch-learning market as a whole,' which gives a clear scope condition that separates it from per-city or per-tutor siblings. It stops short of naming those alternatives or stating when not to use it.

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 establish readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the result ordering puts Verified Pros (3,000+ lessons, 4.9+ rating) first and results are aggregated across seven distinct platforms. Pagination behavior for limit/offset is not 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?

Two sentences, both doing work. The front-loaded platform list is long but it is the tool's core scoping information; the second sentence delivers use cases and filter options without filler.

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

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

For a low-complexity read-only search with no required parameters and no output schema, the description supplies enough: source coverage, result ordering, and available filters. The missing piece is any indication of result shape or pagination semantics for limit/offset.

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 0% across five parameters, so the description must carry the meaning. It does map 'filter by platform' to the platform enum and 'free text' to q, and the Verified Pros emphasis hints at the verified_pro boolean, but limit, offset, and their bounds are never explained.

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 the exact resource (online Dutch tutors) and enumerates the seven source platforms, so an agent immediately knows what corpus is searched. The action verb lives only in the title ('Find'), and no sibling tool covers the same domain, so disambiguation is automatic rather than argued in the text.

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 use cases are given: private lessons, conversation practice, or a tutor on a schedule, plus a note that results can be narrowed by platform or free text. It stops short of any when-not guidance or alternative-tool routing, which is the only gap.

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