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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint. The description adds 'prefilled,' indicating the URL embeds query parameters, and 'request URL' implies no side effects beyond returning a string. This gives extra behavioral 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?

The description is a single, compact sentence that communicates the core function without wasted words. It is front-loaded with the action and object, making it easy to scan.

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 5 parameters and no parameter documentation or usage guidance, the tool is under-specified. The output schema exists but doesn't help the agent understand how to construct the URL or what each parameter does. This is a significant gap for a tool with multiple optional parameters.

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 schema lists 5 parameters with 0% description coverage, and the description does not explain any of them. The agent is left to infer the meaning of authority_slug, body, tags, title, and default_letter solely from their names, which is insufficient for reliable invocation.

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 uses the specific verb 'Build' and clearly identifies the resource as a 'prefilled WhatDoTheyKnow request URL.' This distinguishes it from siblings like create_request_record, which creates a record, and get_* tools that retrieve 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?

There is no explicit guidance on when to use this tool versus alternatives. The description implies it's for generating a URL link, but it doesn't mention the alternative of create_request_record for record creation or specify scenarios like 'when you need to share a pre-filled form link.' The usage context is only implied.

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 provide openWorldHint and destructiveHint. The description adds the requirement for WDTK_API_KEY and the experimental API status, which is useful additional context. However, it does not disclose further behavioral details such as side effects, idempotency, or error handling, leaving some gaps beyond what annotations already cover.

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 two short sentences that immediately state the operation and a key prerequisite. It is front-loaded, free of redundancy, and each sentence contributes meaningful information without unnecessary elaboration.

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

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

For a tool with four required, undocumented parameters and an experimental write API, this description is too sparse. It omits parameter meanings, the domain concept of 'request', and any guidance on how the destructiveHint annotation applies. Even with an output schema, the input side remains largely unexplained, making it hard for an agent to invoke 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?

The schema has four required parameters with zero description coverage, and the tool description does not mention any of them. The description fails to compensate for the schema's lack of detail, forcing the agent to infer meaning solely from parameter names like 'title', 'body', 'external_user_name', and 'external_url'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Create a request' with a specific verb and resource, and it distinguishes from siblings like update_request_state and get_request_detail by being the only create operation. The mention of 'experimental write API' further clarifies it is a write action.

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

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

The description implies the tool is for creating requests and notes the need for WDTK_API_KEY and the experimental nature, which gives some usage context. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or alternative tool references.

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?

With no annotations, the description carries the behavioral transparency burden. It explains the return format (JSON with a messages array) and clarifies how arguments should be structured (dict mapping names to values). It does not cover error cases or side effects, but for a simple get operation this is adequate.

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 two sentences, front-loaded with the primary action ('Get a prompt by name'), followed by concise return-format and argument-format details. Every sentence adds value with no redundancy or 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?

Given the tool has only two parameters, an output schema, and no annotations, the description covers the essential behavioral aspects: what it retrieves, how to pass arguments, and what the return shape looks like. It is sufficiently complete for an agent to invoke the tool correctly without further 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 input schema already provides descriptions for both parameters (name and arguments), giving 100% coverage. The description adds extra meaning by specifying that arguments must be a dict mapping argument names to values, which is not fully detailed in the schema. This elevates the score above 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?

The description clearly states the tool fetches a prompt by name, with optional arguments. This distinguishes it from sibling tools like list_prompts (which would enumerate prompts) and call_tool (which invokes tools). The verb-resource pair is specific and 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?

The description implies when to use this tool: when you know the prompt's name and want its rendered output. It does not explicitly mention alternatives or provide 'when not to use' guidance, but the context is clear enough for an agent to decide appropriately.

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, openWorldHint. Description adds that output contains link field with URL and advises follow-up, but doesn't mention potential limitations or side effects.

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

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

Three sentences, purpose first, no fluff. Efficient and well-structured.

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

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

Despite having output schema, description provides context on how to use returned data. Covers main purpose, alternative, and follow-up. Sibling tools are different, so no confusion.

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?

With 0% schema coverage, description implicitly explains request_slug via 'specific FOI request' but does not mention the limit parameter, leaving some gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool returns parsed Atom feed entries for a specific FOI request as structured objects, distinguishing it from raw XML resource and sibling tools like search_request_events.

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 tells when to use (over raw resource) and provides follow-up instructions (use slug for full detail), giving clear context and 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?

With no annotations provided, the description must carry the full burden of behavioral disclosure. It states that the tool returns JSON metadata, which is useful, but it does not explicitly state that this is a read-only operation with no side effects, nor does it mention any limitations like pagination. For a simple list operation, this is adequate but not rich.

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 two terse sentences: the first delivers the primary action, the second clarifies the return format. Every word earns its place, with no redundancy or irrelevant detail.

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 tool with an existing output schema, the description covers the essential purpose and return type. It is complete, but could be slightly more helpful by explicitly connecting to get_prompt for retrieving specific prompts, which would aid discoverability.

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 the description does not need to explain parameter meaning. The description adds a small amount of value by mentioning that the output includes 'optional arguments', but per the guideline, 0 params warrants a baseline score 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 clearly states the action ('List') and the resource ('all available prompts'), making the purpose unambiguous. It also distinguishes from siblings like list_resources by specifying prompts, and from get_prompt by listing rather than retrieving a specific prompt.

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

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

The description implies when to use the tool: to enumerate all available prompts. It does not explicitly mention alternatives or exclusions, but the context is clear for a list operation with no parameters. A brief note on using it before get_prompt would elevate this to a 5.

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 and idempotentHint, but the description adds critical context: matching logic (name or short_name, case-insensitive), the limit parameter's effect, and the output shape (includes a slug field). No contradictions with 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 compact, front-loaded with purpose, and includes an example and next-step usage in a clear, structured way. Every sentence adds value.

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

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

With an output schema available, the description doesn't need to detail return values. It covers purpose, parameters, behavior, and next steps, making it fully self-contained for an agent to select and invoke 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 provides zero description coverage, but the description explains query as the search string and limit as the maximum result count. The example demonstrates the query parameter's usage, fully compensating for the lack of schema 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?

The description states a specific verb ('Search') and resource ('WhatDoTheyKnow public authorities') and defines the search scope ('by name'). It clearly distinguishes from sibling tools like search_request_events and get_authority_detail.

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 explains the behavior (matches name or short_name, case-insensitive, limit parameter) and provides explicit next-step guidance: 'Use the slug field with authority_json or build_request_url as the next step.' The example clarifies usage context.

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 indicate readOnlyHint, idempotentHint, and openWorldHint. The description adds that it returns up to `limit` AtomEntry objects and describes the navigation flow (link field). This provides behavioral context beyond the annotations without contradiction.

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

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

The description is concise with three paragraphs: purpose, usage guidance, and examples. Every sentence adds information; no fluff. Information is well 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?

Given the presence of annotations and output schema, the description covers the main purpose, result shape, and follow-up steps. It lacks details on sorting or pagination, but the examples and next-step guidance make it fairly complete.

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

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

Schema coverage is 0%, so description must compensate. It explains `limit` indirectly ('Returns up to limit') and gives query examples for `search_expression`. However, it does not formally define the query syntax beyond examples, leaving some ambiguity.

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 specifies the action 'search' and the resource 'WhatDoTheyKnow's feed-based event index' to find FOI requests. It distinguishes from siblings like search_authorities and get_request_feed_items (for full detail). The verb 'Search' and resource 'event index' are specific.

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

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

It explicitly states when to call ('find FOI requests matching a query expression') and provides next steps (use link field, call get_request_feed_items for full detail). Example expressions aid usage. However, it does not explicitly state when not to use or compare directly with all siblings.

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 destructiveHint and openWorldHint, so the agent knows the tool is potentially destructive and the schema may not be closed. The description adds valuable context by stating that WDTK_API_KEY is required in the server environment and that the API is experimental, which is beyond what annotations convey. This enhances the agent's understanding of operational constraints.

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 two sentences, front-loaded with the purpose, and contains no filler. Every word contributes to clarity, and the structure is easy to parse for an agent.

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 write tool with an output schema and annotations, the description covers the essential operational context: it is experimental, requires an API key, and updates a specific aspect of a request. It does not describe side effects or reversibility, but the annotations already warn of destructiveness, and the output schema handles return values. Overall, it is sufficiently complete for agent use.

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?

With 0% schema description coverage, the description must compensate, and it does partially by clarifying that 'state' refers to 'user-assessed state,' which adds meaning beyond the parameter name. However, it does not enumerate valid state values or explain request_id semantics beyond the obvious name. Given only two parameters, this is sufficient but not exceptional.

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 uses a specific verb 'Update' and identifies the resource as 'user-assessed state of a request,' which clearly states what the tool does. This distinguishes it from sibling read tools and even from create_request_record, as it focuses on updating an existing request's state rather than creating a new record.

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

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

The description implies that this tool is for modifying an existing request's state, but it does not explicitly mention when to use it over alternatives like create_request_record. It also does not provide any exclusions, prerequisites beyond the API key, or comparison to other write tools. The mention of 'experimental write API' gives some context but no direct usage guidance.

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