ISO country LB

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

No annotations exist, so the description must carry behavioral disclosure. It mentions 'Task text discarded' and several parameters are described as 'discarded', but it does not state side effects, network/disk access, authentication, or operational constraints beyond those discarded-input hints.

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

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

The description is short and avoids unnecessary fluff, using two sentences to state the tool's action and outputs. However, the content is vague, which limits the value of the concise structure.

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 9 optional parameters, no required parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how the parameters are used, what the returned 'CLI setup' or 'skill file' contain, or how to form a valid request.

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%, but the parameter descriptions are confusing and largely negative: e.g., 'Git ref name; discarded after the shape check', 'City name for a public weather hint; discarded after the call'. They do not explain how these inputs relate to the tool's stated purpose of finding a gateway.

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 says 'Find a public pay-per-call tool gateway (Monid)' and lists outputs, but does not explain what Monid is or what input selects the result. With 9 unrelated optional parameters and no required parameters, the actual purpose remains ambiguous.

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

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

There is no guidance on when to use this tool compared to the many sibling tools. No conditions, examples, or alternative recommendations are provided.

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 behavioral information. It does disclose the key side-effect boundary: no browser is launched. But it does not explain whether a network request is made, whether the check is purely syntactic, what the return value indicates, or how the many 'discarded' parameters behave beyond what the schema already says.

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 with no wasted words. The primary action is front-loaded, and the important side-effect qualifier 'No browser is launched' is placed immediately after. Every word 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?

For a tool with 9 parameters, no output schema, and no annotations, this description is too thin. It does not clarify the relationship between the URL-focused description and the non-URL parameters, nor does it explain expected return values or failure semantics. An agent would need to infer too much before calling this tool confidently.

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

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

Schema description coverage is 100%, so the input schema already documents each parameter thoroughly. The description adds no information about parameters, which is acceptable given the high coverage. However, the singular focus on 'URL' does not help the agent understand how non-URL parameters like json, city, or ref relate to the tool's purpose.

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 action ('Check whether a URL can be opened') and clearly identifies the resource. The added 'No browser is launched' also distinguishes it from sibling tools like playwright-url-ok that likely launch a browser. It loses a point because 'can be opened' is somewhat ambiguous and the input schema contains many non-URL parameters such as json, city, and ref.

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

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

The description provides clear context for when to use this tool: when you only need to know whether a URL can be opened without actually launching a browser. This separates it from alternatives like playwright-url-ok or web-fetch. However, it does not explicitly name alternatives or state when not to use this tool, so it is one step below fully explicit 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?

With no annotations, the description carries the full behavioral burden, but it discloses only that the expression is discarded. It does not state what the tool returns, whether it performs real computation, what a valid a+b input looks like, or what happens when validation fails.

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 short and front-loaded, but it is under-specified to the point of ambiguity. The two sentences do not form a coherent specification of what the tool accepts or returns, so brevity here comes at the cost of usefulness.

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?

A 9-parameter tool with no annotations and no output schema needs a much richer description. This one fails to explain return values, how the many discardable parameters relate to arithmetic evaluation, or any error semantics, making correct invocation effectively impossible.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description contributes no parameter-level detail. The description references an 'expression' that does not exist among the nine schema properties, so it adds no clarifying meaning to the actual parameters.

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 concrete operation, evaluating a+b style arithmetic, which is more than a tautology. However, it never ties this operation to any field in the input schema, and there is no expression parameter an agent could populate. The phrase 'Expression discarded' also leaves ambiguity about whether the tool returns a result or merely validates and forgets the input.

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 when-to-use guidance, no criteria for choosing this tool over alternatives, and no mention of sibling tools. The discard note is a behavioral observation, not actionable guidance about when calc-eval should be invoked.

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 only behavioral disclosure beyond the schema is 'Page content is not stored,' which is useful privacy context. With no annotations, the description nonetheless omits whether the URL is fetched live, whether parameters are simply discarded, and any rate-limit or error behavior—so it does not carry the full transparency burden.

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 with the core behavior front-loaded and the privacy note earning its place. There is no redundant or filler material.

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?

The tool has nine optional parameters, no annotations, and no output schema, yet the description covers only the URL case. It does not clarify what the other parameters are for, what counts as a 'citation,' or what the return object looks like, leaving an agent with no way to assess complete behavior.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description provides no parameter details. The description does add that url is central, but it does not explain the purpose of the eight other optional parameters or how they relate to the documented URL behavior.

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 result ('host, scheme, and HTTP status') for a specific resource ('URL'), so the core operation is clear. However, it does not distinguish this from sibling tools like fetch-status or normalize-url, and the input schema's nine unrelated optional parameters suggest a broader purpose than the description implies.

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

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

There is no guidance about when to use this tool instead of fetch-status, normalize-url, browser-url-ok, or web-fetch. The description provides no when-to-use, when-not-to-use, or alternative-selection cues.

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?

No annotations are present, so the description carries the full burden of disclosing side effects and safety. It does add a useful 'No identifiers are retained' guarantee, but it does not state whether the tool is read-only, whether it performs network requests, or what observable behavior occurs beyond returning a classification. This leaves significant ambiguity.

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 with no filler, and the primary action is front-loaded ahead of the privacy note. It is concise to the point of under-specification, but that deficiency is better penalized under contextual completeness and purpose clarity.

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 nine heterogeneous optional parameters, no annotations, and no output schema, this definition is far from complete. It does not explain what the classification result looks like, how multiple populated parameters are combined, or what response the agent should expect. An agent cannot confidently predict the tool's behavior from this description alone.

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 provides 100% parameter description coverage for all nine optional fields, so the description does not need to restate parameter meanings. However, the description adds nothing about how the parameters interact or which fields determine the overall classification. Baseline 3 is appropriate because the schema already carries the parameter-level semantic load.

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 verb and object ('Show how this request is classified'), so it is not a tautology, but it never defines what 'classified' means, what classification categories exist, or what output to expect. It also does not differentiate this tool from the many sibling shape-check and fetch 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?

There is no guidance on when to use this tool instead of alternatives like domain-shape, fetch-status, or validate-json. No prerequisites, exclusions, or contextual triggers are mentioned. The privacy note is informative but not usage 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?

With no annotations, the description must carry the transparency burden. It discloses that the operation is label splitting and excludes WHOIS/ownership data, but it doesn't say whether any network access occurs, how invalid hostnames are handled, or what the return value looks like. This is meaningful but incomplete.

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 one tight sentence with the action front-loaded and no filler. It loses a point because it is so terse that it omits essential invocation context for a nine-parameter tool, though that omission is penalized more directly in contextual completeness.

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?

This is a high-complexity tool: nine optional parameters, no required parameters, no output schema, no annotations, and a large sibling set. The one-sentence description does not tell the agent which input to pass, what the output format is, or what happens on invalid input, so it is far from complete enough for confident 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?

The input schema already documents all nine parameters with descriptions, so the baseline is 3. The tool description adds no extra parameter-level detail and does not state that 'host' is the relevant field among the nine optional properties.

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 concrete operation and resource—'Split a hostname into labels'—and adds a useful negative scope, 'without WHOIS or ownership data,' which separates it from ownership-oriented sibling tools. It doesn't name the 'host' parameter or mention any validation behavior, so it's clear but not maximally precise.

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 when-to-use or when-not-to-use guidance and no mention of sibling tools such as normalize-url, github-repo-shape, or browser-url-ok. The 'without WHOIS or ownership data' clause hints at a syntactic scope, but an agent is left to infer when this tool beats its 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 carries the full burden of explaining behavior. It does disclose the HTTP method (HEAD), the public nature of the URL, and that only status is returned, but it does not explain what happens when other parameters are passed, how errors or redirects are handled, what the returned status looks like, or whether the request is safe/read-only.

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

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

The description is a single, front-loaded sentence with no filler; every word contributes to the basic action and result. It is concise, though the brevity comes at the cost of contextual completeness.

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 nine optional parameters, no annotations, no output schema, and many similar sibling tools, this description is far too sparse. It fails to explain how the non-URL parameters relate to the tool, which parameter is required for a successful call, or what the response will contain. An agent cannot reliably invoke this tool correctly based on the provided definition.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level detail. The description implies 'url' is the main input, but the schema describes url as 'HTTPS URL to normalize or cite', which adds ambiguity. Still, each parameter has its own schema description, so the description does not need to repeat them.

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 concrete action ('HEAD a public URL') and result ('return status only'), which is clear on the surface. However, the input schema exposes nine unrelated optional parameters such as city, zone, json, and query, and the url parameter is described as 'normalize or cite' rather than HEAD. It also does not distinguish this tool from siblings like web-fetch, browser-url-ok, or playwright-url-ok.

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, and no mention of which parameter should be supplied. The only implicit hint is 'public URL' and 'status only', but the schema allows many non-URL inputs, so the agent is left without reliable selection criteria.

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 only disclosed behavior is that the path is discarded. No annotations exist, so the description carries the full burden, but it fails to state whether this is a read-only check, whether network access occurs, or what happens with invalid URLs. The return value is also 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?

The description is extremely brief, with no filler, and the main action is front-loaded. 'Path discarded' is a deliberate second sentence adding behavioral clarity. However, the brevity veers into under-specification, and the phrase 'Path' is ambiguous.

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 a rich 9-parameter schema and no output schema or annotations, the description gives no indication which parameter is the Figma URL or what the tool returns. 'Path discarded' may refer to the path parameter or the URL path components, but this is not clarified. The description is insufficient for an agent to confidently invoke the tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not reference any parameter, and the schema's parameter descriptions (e.g., 'HTTPS URL to normalize or cite' for url) are generic and not tailored to Figma, leaving potential confusion about which field to populate. However, since the schema technically documents all parameters, the description adds no further value, matching 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?

States a specific verb ('Parse') and resource ('Figma file URL'), which clearly distinguishes it from sibling validators like github-repo-shape. However, it does not explain what 'parse' produces (e.g., validation result vs extracted parts), and 'Path discarded' is ambiguous. Still, the core purpose is unmistakable.

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?

No guidance on when to use this tool versus sibling validators such as domain-shape or wiki-title-ok. There are no exclusions, alternative suggestions, or contextual triggers. An agent must infer usage solely from the tool name.

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 carries the full behavioral burden. 'No disk access' is a useful transparency signal and implies a non-mutating, side-effect-free check, but the description does not disclose what 'looks safe' means, what happens with invalid paths, or what the tool returns.

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, front-loaded sentences with no filler. Every word earns its place, and the core purpose is stated before the key behavioral caveat.

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?

This is a 9-parameter tool with no annotations and no output schema, yet the description only addresses path checking. It omits the role of the other accepted parameters, the return behavior, and the definition of 'safe,' leaving an agent with meaningful uncertainty about how to 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?

The input schema already provides descriptions for all 9 parameters, so the description does not add much parameter-level meaning. It references 'path' only, while the schema itself documents the rest; this meets the baseline but adds no extra semantic value beyond the schema.

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

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

The description states a specific verb and resource: 'Check whether a path looks safe.' It clearly distinguishes this from sibling URL- and domain-oriented tools by targeting file paths, and 'No disk access' further clarifies it is a syntactic or shape check rather than a filesystem operation.

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 no guidance on when to prefer this tool over alternatives such as browser-url-ok, normalize-url, or wiki-title-ok. There is no mention of exclusions, prerequisites, or context in which this tool should be selected.

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 full burden, but it only names the external service (Open-Meteo). It does not disclose that many inputs are discarded, that the call is stateless/read-only, or any limitations, so behavior remains opaque.

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 concise sentence with no filler or repetition. It is front-loaded with the core output, though it may be too terse to fully support tool selection.

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 nine optional parameters, no output schema, and no annotations, the description is incomplete: it fails to map a place to a parameter or describe the return format. An agent cannot reliably invoke it correctly from the description alone.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning and does not clarify that 'city' or 'query' is likely the place input, but the schema already documents each field.

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 the tool returns latitude and longitude for a place via Open-Meteo, which is a clear outcome and distinguishes it from weather or timezone siblings. However, it lacks an explicit action verb and does not say which input parameter identifies the place.

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?

No guidance is given on when to use geo-hint versus alternatives like weather-hint or timezone, or which of the nine optional parameters is relevant. The description leaves usage entirely 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?

With no annotations, the description carries the full burden, yet it only states the parse action. It does not disclose how malformed or non-GitHub URLs are handled, whether any other parameters are ignored, or what the response looks like.

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

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

One sentence, front-loaded with the verb and resource, with no filler or repeated schema information. Every word 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?

The description is enough for a simple call: provide a GitHub URL and expect owner and repo. However, with nine optional parameters, no required fields, no output schema, and no annotations, it leaves return shape, invalid-input behavior, and routing details 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 description coverage is 100%, so the baseline is 3. The description adds a little semantics by clarifying that the URL is a GitHub URL and that owner/repo are extracted, but it does not resolve which of the eight other optional parameters are relevant.

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 concrete verb ('parse'), a specific resource ('GitHub URL'), and an explicit outcome ('owner and repo'). This distinguishes it from sibling tools like figma-url-shape or jira-key-shape without requiring the schema to be opened.

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 phrase 'from a GitHub URL' implies when to use the tool, but the description gives no explicit routing, no exclusions, and no mention of alternatives such as normalize-url or domain-shape for non-GitHub URLs. Usage is inferable, not stated.

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 carries the full burden of explaining side effects, network access, rate limits, or data handling. It only states the action and a cryptic note about titles, offering no transparency about the tool's behavior beyond the surface action.

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 extremely concise, consisting of two short sentences. It is well-structured and free of unnecessary content, but the brevity sacrifices essential information about parameters and usage, making it concise yet incomplete.

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 9 optional parameters with seemingly irrelevant descriptions, the tool description fails to provide sufficient context for correct invocation. It does not explain whether parameters are intended to be ignored, what each parameter does in the context of counting stories, or what output to expect, leaving the agent with a large gap in understanding.

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?

Although the schema has 100% description coverage for its 9 parameters, those descriptions are generic and unrelated to counting Hacker News stories (e.g., 'url' for normalization, 'city' for weather). The tool description does not map any parameters to its purpose, so an agent cannot determine which, if any, parameters should be provided.

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 verb 'Count' and the specific resource 'Hacker News front-page stories', making the primary purpose understandable. However, it does not explicitly mention that the tool returns a number, and the odd phrase 'Titles discarded' adds minor ambiguity about output format.

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 no indication of when to use this tool versus any of the 27 sibling tools. There is no mention of suitable use cases, prerequisites, or scenarios where this tool is preferred, leaving the agent without guidance on 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?

There are no annotations, so the description must carry behavioral disclosure. It only says the tool relates to 'Common IANA timezone names' and 'clock calls'; it does not state what the tool returns, whether it is read-only, whether it calls external services, or how inputs are handled. Some schema hints mention 'discarded,' but the description itself provides no behavior.

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 short and front-loaded, with no filler words. But it is under-specified rather than meaningfully concise: one short phrase does not provide enough operational detail for an agent to invoke the tool correctly.

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 9 optional parameters, no output schema, and no annotations, the description is far from complete. It gives only a domain hint and does not explain the return value, which parameters are relevant, or what behavior the caller should expect.

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

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

Schema description coverage is 100%, so the baseline is 3. However, the description adds no parameter-related meaning, and the listed parameters such as ref, url, json, and path seem unrelated to IANA timezone names, leaving the mapping between arguments and tool purpose unclear.

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 is a noun phrase: 'Common IANA timezone names for clock calls.' It restates the tool name without a specific verb or action, so an agent cannot tell whether this tool lists, validates, retrieves, or filters timezone names. It also does not clearly distinguish itself from sibling tools like timezone or utc-time.

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 phrase 'for clock calls' gives a weak context hint, but there is no explicit when-to-use guidance, no exclusions, and no mention of alternatives. An agent has no basis for choosing this tool over the sibling timezone-related tools.

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 alone must disclose behavior. It claims a network fetch of robots.txt, but the schema parameters do not support this (e.g., 'url' is described as 'HTTPS URL to normalize or cite', not for robots). Side effects, error handling, and return format are unspecified. The behavior is opaque and inconsistent with the schema.

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

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

The description is extremely brief, but brevity here sacrifices necessary detail. It lacks structure and does not clarify the intended parameter usage. While it is concise in word count, it is not appropriately sized for the complexity of 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?

The tool has 9 optional parameters, no annotations, and no output schema. The description does not explain how parameters map to the robots.txt fetch, what 'group counts' means, or how the tool behaves. An agent cannot successfully invoke this tool based on the available information.

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

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

Although every parameter has a description, they are generic and misaligned with the tool's stated purpose. For instance, 'host' and 'url' are vaguely defined, and none are clearly tied to fetching robots.txt. The descriptions do not help an agent understand which parameter to use or how. Semantics are effectively absent.

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 (fetch) and resource (robots.txt) and output (group counts), but the parameter list is entirely generic and unrelated (ref, city, feed, etc.), creating confusion about what the tool actually does. The purpose is stated, but the mismatch undermines clarity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It neither mentions conditions for use nor distinguishes it from sibling tools like web-fetch or browser-url-ok. There is no usage context at all.

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?

No annotations are provided, so the description carries the full burden, but it only offers the terse 'Key discarded' note. It does not disclose return values, error behavior, whether network access is required, or any side effects beyond discarding input.

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 very short and front-loads the purpose, with no filler. However, it is under-specified: one additional sentence clarifying which parameter carries the Jira key would make the definition appropriately sized.

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 annotations, no output schema, and a seven-parameter schema that never names a key field, an agent cannot determine how to invoke the tool or interpret its result. The definition is critically incomplete for a callable validation 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?

Every parameter in the input schema has a description, giving high schema coverage, but none of the parameters is identified as the Jira key the tool is meant to check. The description adds no mapping from 'key' to any actual field, making invocation semantically ambiguous.

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 action ('Check') and resource ('a Jira issue key shape'), and adds that the key is discarded. However, it nearly restates the tool name and does not differentiate it from sibling shape validators like github-repo-shape or domain-shape.

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

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

There is no guidance on when to use this tool versus the sibling shape-checking tools, nor any conditions under which it should be avoided. The description provides no prerequisites, expected input format, or 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only reveals that the body is discarded, but says nothing about whether a network request is made, how the nine optional inputs are treated, what a successful or failed status looks like, or whether any data persists.

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 very short and front-loaded, with no filler or repetition. 'Body discarded' adds meaningful behavioral detail. However, the brevity borders on under-specification given the tool's complexity.

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 9 optional parameters, no output schema, no annotations, and 26 sibling tools, two short sentences are insufficient. The description does not explain which parameter produces the HTTP status, what the return format is, or how this tool relates to its many sibling tools.

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

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

Schema description coverage is 100%, so the baseline is 3 even without additional description. The description adds a small hint that a URL yields an HTTP status, but it does not clarify the roles of the other eight parameters or how they relate to the stated purpose.

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 action ('HTTP status for a public library docs URL') and discards the body, so it is not a tautology. However, the 9-parameter schema covers city, feed, host, JSON, path, zone, query, and more, which the description never accounts for, making the tool's actual scope ambiguous and poorly differentiated from siblings like fetch-status or browser-url-ok.

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

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

There is no guidance on when to use this tool instead of the many URL/status/shape-check siblings. No exclusions, no alternatives, and no selection criteria are mentioned, so an agent cannot decide between lib-docs-hint and fetch-status, browser-url-ok, or normalize-url.

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 are entirely absent, so the description carries the full disclosure burden. It reveals one behavior — "Values discarded" — but is silent on error handling for invalid JSON, whether keys are counted at top level or nested depths, the return shape, and the retention implications hinted by the tool's "memory" name.

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?

Eight words across two sentences, with the core action front-loaded and the key qualifier immediately following. Every word earns its place with no fluff — exemplary minimalism, even though other dimensions pay the price for the brevity.

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 nine heterogeneous parameters, zero annotations, and no output schema, the description leaves the parameter-to-operation mapping unresolved — an agent cannot tell which parameter carries the JSON or what happens when multiple are provided. The return value (a key count) is only implied, and failure behavior for malformed JSON is undocumented.

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%, which sets the baseline at 3, and the description adds no parameter-level meaning. It never identifies which of the nine heterogeneous parameters (ref, url, city, feed, host, json, path) supplies the JSON object to count, and the schema's "JSON text to validate" wording sits awkwardly against the description's counting intent.

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 and resource — "Count keys in a JSON object" — which is instantly distinguishable in action from the sibling list, and "Values discarded" sharpens the scope. However, it never explicitly contrasts itself with adjacent tools like validate-json, so differentiation is implicit rather than stated.

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?

No when-to-use or when-not-to-use guidance is offered; the two sentences are purely definitional. With 27 siblings including validate-json and other JSON-adjacent tools, an agent has no basis for routing between this and an alternative.

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 must carry behavioral disclosure. It does reveal that query strings and URL fragments are dropped, which is useful. However, it does not disclose that most of the nine input properties are ignored or discarded, nor what happens with invalid or non-HTTPS URLs.

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 with no filler. The core action is front-loaded, and the dropped-query/fragment behavior is stated efficiently. Every sentence 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?

Given nine optional parameters, no annotations, and no output schema, the description is too sparse. It does not specify which parameter should receive the URL, what the return type is, or what happens when no URL is provided. An agent could plausibly pass the wrong property among url, feed, or host.

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

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

Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter-specific meaning beyond saying 'a URL', leaving the schema to identify which parameter is the URL. It does not compensate for or clarify the presence of many unrelated optional parameters.

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 ('Return') and names the resource ('a URL') and the output components ('origin, host, and path'). It also explains a key behavior (dropping query and fragment), which makes the tool's purpose reasonably distinct from URL-checking siblings. It does not explicitly differentiate itself from sibling tools, so it stops short of a 5.

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

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

The description provides no guidance on when to choose this tool over the many sibling URL-related tools, such as browser-url-ok, figma-url-shape, or playwright-url-ok. It also gives no 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 full burden. It discloses one useful trait ('No browser is launched') but does not explain whether a network request occurs, what 'ok' means, whether input is discarded, or what side effects exist. The schema hints that many params are discarded, but the description itself is silent.

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 only two short sentences and front-loads the core purpose. It earns its place, though the absence of any structural cues (like 'Returns...') means it is terse rather than fully informative.

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 no annotations, so the description must explain return value and behavior; it does not. With 9 optional input parameters and many sibling tools, a two-sentence description leaves too much for the agent to infer.

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

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

Schema description coverage is 100%, so the baseline is 3. The main description adds no parameter guidance, and with 9 optional params it does not clarify which one should be treated as the URL; however, the schema descriptions already provide per-param 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 description names a specific check ('Check whether a URL can be opened') and adds a key differentiator ('No browser is launched'), which helps distinguish it from browser-based siblings like browser-url-ok. It doesn't explicitly name that sibling, so it stops short of a fully unambiguous purpose.

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?

No guidance is given about when to prefer this tool over browser-url-ok, fetch-status, web-fetch, or normalize-url. The 'No browser is launched' sentence implies a lightweight check, but the description never states the condition for choosing this tool or an alternative.

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 and no output schema, the description carries full responsibility for behavioral disclosure. It does meaningfully disclose that the query is discarded, which is a useful privacy trait. However, it does not state what the tool returns, what happens when 'query' is omitted, or whether other provided fields are ignored.

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

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

The description is compact and front-loaded: the core action appears in the first sentence. It is economical, though slightly too sparse given the tool's nine-parameter schema and lack of supporting annotations.

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

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

Given nine optional parameters, no annotations, and no output schema, the description is substantially under-specified. It never clarifies which parameter the tool actually operates on, how to handle the other eight fields, or what the output looks like. This leaves an agent uncertain about correct 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 100%, so every parameter already has a documented meaning. The description adds essentially no new parameter-level information beyond mentioning the query discard behavior, which is also stated in the schema. Baseline 3 is appropriate.

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

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

The description states a specific action ('Count characters') and a specific resource ('search query'), which makes the tool's purpose understandable and distinguishes it from shape-checking and URL-tool siblings. However, it does not reconcile why the input schema exposes eight other unrelated optional fields, which creates ambiguity.

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

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

There is no guidance about when to use this tool versus alternatives or which parameter to provide. The description implies it is for measuring a search query's length, but it never says that only the 'query' field matters or that the other fields should be ignored or left empty.

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?

No annotations are provided, so the description must carry the behavioral burden. It only says 'short catalog of common HTTP status codes' without disclosing whether this is a static read-only lookup, whether inputs are required, whether network access occurs, or what side effects might happen.

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

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

The description is a single, front-loaded sentence with no filler, which is concise. However, it is so underspecified that the brevity sacrifices essential clarity; it is more minimal than genuinely 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?

With seven input parameters, no output schema, and no annotations, a six-word description is not enough for an agent to know how to invoke the tool correctly or interpret its result. The relationship between the varied parameters and the catalog content is entirely 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?

The input schema documents all seven parameters with individual descriptions, giving high schema coverage. The tool description itself adds no parameter-level meaning, but the schema already does the heavy lifting, so a baseline 3 is appropriate.

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

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

The description clearly identifies the resource (common HTTP status codes) and indicates a short catalog, so the general intent is understandable. However, it uses a noun phrase rather than an explicit verb like 'returns' or 'lists', and it does nothing to distinguish this tool from siblings like fetch-status.

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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or intended calling context. An agent would have to infer from the name/siblings what role it plays.

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 bears the full burden, and it only says the prompt is discarded. It does not disclose whether any of the seven input properties affect the returned template, whether the operation is read-only, or what happens with the other params; it merely returns a vague template.

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 main behavior and followed by the discard note, with no filler. Slightly too terse to earn a 5 because the discard statement is ambiguous without a 'prompt' param, but it remains efficient.

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 seven schema parameters and no output schema or annotations, the description provides only a minimal return statement and ignores usage context, output shape, and the role of the unrelated-looking parameters. Significant gaps remain for an agent to decide it can call with no meaningful input.

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?

All seven parameters already have individual descriptions in the schema, giving high schema coverage, so the baseline is 3. The description's 'Prompt discarded' adds a small amount of input-handling context, but it does not go beyond the schema's own 'discarded after' notes.

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 concrete action and deliverable ('Return a three-step thinking template') with a specific verb and resource. It does not heavily rely on the tool name, but the template is left underspecified and no sibling differentiation is offered, so it falls short of a 5.

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

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

There is no guidance on when to invoke this tool instead of another, and no exclusions or alternatives are named. The 'Prompt discarded' note hints at behavior but not at selection conditions, so an agent has no basis for choosing this over 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?

With no annotations, the description carries the behavioral disclosure burden, but it only restates the high-level purpose. It does not mention that many input fields are discarded, how the timezone is supplied, or any 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?

The description is a single tight, front-loaded sentence with no filler. It efficiently conveys the main purpose without wasting tokens.

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 9 parameters, no annotations, and no output schema, this description is too thin. It omits which parameter selects the timezone, how discarded parameters behave, and how the tool relates to nearby siblings.

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

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

Schema description coverage is 100%, so the baseline is 3 and the parameter descriptions largely stand on their own. However, the tool description does not map the 'named IANA timezone' concept to a specific parameter, leaving ambiguity across the many unrelated fields.

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 the core function: returning the current time for a named IANA timezone. It is clear enough to distinguish from sibling tools like iana-zones and utc-time, though it lacks an explicit verb.

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?

No guidance is provided on when to use this tool instead of utc-time or iana-zones. The agent must infer usage purely from the tool name and description.

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 present, the description carries the full burden of behavioral disclosure, but it only says 'Current UTC timestamp.' It does not explain return format, that all input parameters are discarded/ignored, or any other behavioral characteristics. The schema hints that inputs are discarded, but the description itself is silent.

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 extremely concise with no filler words, making it easy to parse. It is not structured or elaborated, but for a one-line tool description it is appropriately compact, though it sacrifices helpful 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?

The tool has a surprisingly large and unrelated input schema, no output schema, and sibling tools that overlap semantically. The description does not mention that all parameters are ignored, nor does it clarify what exact form the timestamp takes, leaving an agent under-informed for a tool whose schema is confusing.

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 has seven parameters, all with individual descriptions, so schema_description_coverage is high and the baseline is 3. However, the tool description adds no parameter meaning and fails to clarify why a UTC timestamp tool accepts parameters like url, ref, city, feed, host, json, and path, even though the schema notes they are discarded.

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 returns a current UTC timestamp, which is a specific result. It does not use a verb like 'get' or 'return', and it does not differentiate itself from sibling tools such as timezone or iana-zones, so it stops short of a 5.

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

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

The description provides no guidance about when to use this tool versus alternatives like timezone or iana-zones. There is no mention of intended use cases, exclusions, or conditions that would help an agent decide between tools.

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's 'body is discarded' disclosure is useful but incomplete. It does not state what the tool returns (e.g., a boolean or error), and it leaves the purpose of the other six parameters unexplained; the schema partially fills this in by marking them as discarded.

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 with no filler; the key action and side effect are front-loaded. The brevity comes at the cost of not mapping 'body' to the schema, but the structure itself is clean.

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 seven parameters and no output schema, the description is too sparse. It does not specify how to invoke the validation (which parameter is the JSON), what the response looks like, or why the tool accepts unrelated-looking fields such as ref, city, and feed. An agent would need to inspect the schema carefully and might still be confused.

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

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

Schema description coverage is 100%, so the baseline is 3 even without extra explanation. The tool description adds no parameter-level meaning, and its vague 'body' wording does not clarify that 'json' is the parameter to populate, but the schema's per-field descriptions compensate.

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 operation (validating whether a body is JSON) and notes the body is discarded. The tool's name reinforces the purpose. However, the term 'body' is not explicitly mapped to the 'json' input parameter, leaving slight ambiguity about what to pass.

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 use case is implied by the name and description: when you need to validate JSON. There are no explicit conditions, prerequisites, or alternatives mentioned, though the siblings list contains no other JSON-specific validator, so no routing conflict is obvious.

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 full behavioral burden, but it only says 'via Open-Meteo.' It does not disclose that this is a stateless read, that other parameters are ignored, whether an API key or network access is needed, or what happens for unknown cities. The schema's 'discarded' notes hint at side-effect-free behavior, but the tool description itself does not.

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

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

One compact sentence with no filler and the core action front-loaded. There is no wasted text.

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

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

A nine-parameter tool with no annotations and no output schema needs more context than this. The description does not say which parameter to use, what unit the temperature is returned in, what errors look like, or that the other parameters are irrelevant. The agent can guess, but the tool definition does not fully equip 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?

Schema coverage is 100%, so the description need not explain each parameter. It does not add meaning beyond the schema; the city parameter is already described in the schema. The description's phrase 'for a city' overlaps with schema info but does not clarify the role of the other eight optional fields.

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 clear outcome: current temperature for a city, and names the data source (Open-Meteo). It is easy to tell apart from sibling geo-hint/timezone tools. It loses a point for using a noun phrase rather than an explicit verb like 'gets' and for not acknowledging that only the city parameter matters.

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?

No when-to-use or when-not-to-use guidance is provided. There are no explicit alternatives or exclusions, and the description does not warn that only 'city' is relevant among the nine optional schema parameters. Usage context is left entirely 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?

With no annotations, the description carries the burden of behavioral disclosure. It usefully discloses that the body is discarded and that the URL must be public. However, it omits other behavioral details an agent may need, such as request method, redirect handling, timeouts, or the exact output/return contract.

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 compact sentences with no filler, and the primary behavior is front-loaded. It is efficient and readable, though brevity comes at the cost of omitting important schema and sibling-tool guidance.

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?

The tool has 9 optional parameters, no annotations, and no output schema, yet the description addresses only the URL case. It does not explain how the other accepted inputs behave, what happens if multiple fields are provided, or what the response will look like, leaving the description incomplete for real invocation decisions.

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 already documents all 9 parameters with 100% coverage, so the baseline is 3. The description adds little beyond the 'public URL' qualifier and does not clarify the relationship between the URL-only description and the many non-URL schema fields like city, iana, query, and json.

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 returns HTTP status and content type for a public URL and explicitly notes the body is discarded. This gives a specific verb-like capability and a clear resource. However, it does not distinguish this tool from similar siblings such as fetch-status or browser-url-ok, so it stops short of a 5.

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

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

The description implies a lightweight status/content-type use case and warns the body is not returned, which is a useful exclusion. But it never names alternative tools, states when to prefer them, or explains which of the nine schema inputs should be used in which situation.

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 to rely on, the description carries the behavioral burden, but it only adds 'Title discarded after the call.' It does not disclose network behavior, return format, failure semantics, rate limits, or what 'exists' means.

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 with the core action front-loaded and no filler. It loses points only because the brevity hides essential parameter mapping information.

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

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

Given eight unrelated input parameters, no annotations, and no output schema, the definition is far from complete. The missing mapping from 'title' to an actual input parameter makes the tool effectively uncallable from the description alone.

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 centers on a 'title,' yet the input schema contains no title property; the eight properties (ref, url, city, feed, host, json, path) are not mapped to the title input. An agent cannot determine which parameter to populate, despite the schema giving each property its own description.

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 sentence uses a specific verb and resource: 'Check whether a Wikipedia title exists.' It is not a tautology and is distinct from sibling shape/hint tools. However, the missing title parameter slightly blurs how the purpose maps to an invocation.

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 use case is implied: an agent should call this when it needs to know whether a Wikipedia title exists. There is no explicit guidance about when not to use it, prerequisites, or alternatives among the sibling tools.

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