Language en

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds one useful transparency note ('Page content is not stored'), but it does not mention that the tool performs a live HTTP fetch, potential side effects, latency, rate limits, or error behavior. This is insufficient for a network-calling tool.

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

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

Two sentences with no filler. The primary action is front-loaded, and the storage note is short but meaningful. 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 incomplete for a tool with four parameters including json and zone, which are not mentioned in the description at all. There is no output schema and no annotations, so the agent is left without an explanation of how those parameters fit or what the return format looks like.

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 schema already documents all four parameters. The description itself adds no parameter-level meaning and does not explain how json and zone relate to the stated 'host, scheme, and HTTP status' purpose. Baseline 3 applies since the schema handles the heavy lifting.

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 action ('Return host, scheme, and HTTP status') on a specific resource (a URL). However, it does not differentiate this tool from siblings like normalize-url, which could plausibly return the same fields, so the purpose is clear but not fully disambiguated.

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 siblings such as normalize-url, validate-json, or format-time. An agent must infer usage from the terse description and parameter names, which is risky given the overlapping sibling names.

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 does disclose that no identifiers are retained, which is a useful privacy note, but it says nothing about side effects, network calls, rate limits, or what happens to the provided url, host, json, or zone inputs.

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 at two short sentences with no fluff. However, the first sentence is too vague to earn a 5, and the retention sentence, while valuable, is disconnected from the core function.

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 incomplete for a tool with no output schema and no annotations. It does not explain the classification result, what the response looks like, which inputs are expected together, or when to prefer this tool over its many 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 each parameter already has an individual description. The tool description adds no extra parameter meaning beyond calling the request 'classified,' but since the schema covers all parameters, the baseline of 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 says 'Show how this request is classified,' which is vague: it does not specify what kind of request, what classification means, or what the possible classifications are. It does not distinguish this tool from siblings like validate-json or normalize-url, which also involve inspecting inputs.

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 about when to use this tool versus any of the sibling tools. The description gives no context, prerequisites, or exclusions, leaving the agent to guess based on the name and loose schema.

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 absent, so the description must fully disclose behavior, but it only covers the core splitting action and the WHOIS exclusion. It does not explain how the other parameters (especially json, which the schema says is 'discarded') are treated, nor anything about return values 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?

The description is a single front-loaded sentence with no wasted words, and the 'without WHOIS or ownership data' qualifier is genuinely informative. The brevity hurts completeness, but the sentence structure itself is 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?

With four optional parameters, no output schema, and no annotations, the description fails to explain the tool's broader behavior. It leaves the purposes of url, json, and zone largely unaddressed and does not describe the expected output format, making it insufficient for reliable 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 the baseline is 3. The description adds meaning only by clarifying the 'host' parameter's purpose (hostname labels), while offering no additional context for url, json, or zone beyond the schema's own descriptions.

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, 'Split a hostname into labels', and adds a useful exclusion ('without WHOIS or ownership data'). However, it conflicts with the input schema, which includes unrelated parameters like url, json, and zone, making the tool's actual purpose unclear beyond the narrow hostname-splitting claim.

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 negative scope ('without WHOIS or ownership data') implies when the tool should or should not be used, but no explicit guidance or alternative tools are mentioned. The agent must infer the usage boundary from that single phrase.

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 of disclosing behavior. It only describes a static collection of names; it does not state what the tool returns, whether it lists or looks up zones, or how the input parameters participate in the operation. This is a substantial transparency gap.

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 text is short and has no filler, but it is only a noun phrase and is under-specified as a tool definition. It is concise without being a well-structured description of the tool's purpose or behavior.

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 four parameters, no annotations, and no output schema, this description is not complete enough for reliable invocation. It fails to explain the tool's operation, the relevance of most parameters, or its relationship to sibling clock tools, leaving the agent to guess.

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

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

Schema descriptions cover all four parameters, so the baseline is 3. The description adds little beyond the schema, aside from weakly connecting 'zone' to IANA timezone names, and it does not clarify why url, host, and json appear in a timezone-related tool.

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

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

The description identifies the content ('common IANA timezone names') and hints at its use ('for clock calls'), but it lacks an explicit action verb and does not clearly distinguish itself from sibling tools like timezone and utc-time. It is more informative than a tautology, but still vague about what the tool actually does.

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?

'For clock calls' implies the intended context and loosely points toward sibling clock-related tools, but there is no explicit statement of when to use this tool versus alternatives or when not to use it. The guidance is implied rather than clearly 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, the description carries the full burden. It usefully discloses that the fetch targets a public resource and returns counts only, but it never explains the unrelated-looking params (json 'discarded after the check', zone 'IANA timezone name') or any failure/latency behavior, leaving the tool's actual footprint 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?

A single front-loaded sentence states the action, scope, and output limitation with zero filler. 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 an unannotated tool with four optional params and no output schema, one short sentence is insufficient. The description leaves unresolved which params trigger robots.txt fetching, what 'group counts' look like in the response, and why json/zone parameters exist, so the agent must guess.

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

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

Although schema coverage is 100% (baseline 3), the description adds no param-level meaning and actually creates ambiguity: 'Fetch a public robots.txt' does not say whether url or host is the target, while the schema describes url as 'normalize or cite' and json/zone as validation/timezone inputs unrelated to robots.txt. An agent cannot reliably map the described behavior to the right parameter.

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

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

The description names a specific verb ('Fetch'), a concrete resource ('public robots.txt'), and a precise output scope ('group counts only'), so an agent knows exactly what the tool does. It does not explicitly contrast itself with the sibling 'citation', so it stops short of a full 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?

No guidance is given on when to use this tool versus the sibling 'citation', and no exclusions are stated. The context 'when you need robots.txt group counts' is only implicit, and the description gives no hint about which of the four optional params is relevant.

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 of behavioral disclosure. It only states a fact about a language tag and says nothing about what happens when invoked, what inputs are processed, what output is returned, or whether any state changes occur. The relationship between the language tag and the heterogeneous parameters is entirely unexplained.

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

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

The text is brief, but this is under-specification rather than effective conciseness. The single phrase is nearly redundant with the tool name and contains no actionable information that could be front-loaded.

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

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

With four parameters, no annotations, and no output schema, the description needed to explain how the language tag relates to the inputs and what the tool returns. It provides none of that context, making it inadequate for reliable 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 the baseline is 3 even though the description adds no parameter-level information. The description does not connect url, host, json, or zone to the 'en' language tag, providing no extra value beyond the schema field descriptions.

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 that only restates the tool's name: 'ISO 639 language tag en.' It contains no verb or action and does not say what the tool does with the url, host, json, or zone inputs. It also provides no basis for distinguishing it from sibling tools.

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

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

There is no guidance on when to use this tool versus any of its siblings like citation, normalize-url, validate-json, or utc-time. No conditions, alternatives, or exclusions are mentioned. An agent cannot determine the intended use case from this 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, the description carries the full burden of disclosing behavior. It states the return value and the dropping of query/fragment, but does not mention whether the operation is read-only, if validation occurs, what happens on invalid input, or how the additional parameters (host, json, zone) affect behavior. This is a significant transparency gap.

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 fluff. The core purpose is front-loaded, and the behavioral note about dropped components is concise and 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?

The tool has four parameters but the description addresses only one. There is no output schema, so the description should at least clarify how the different parameters relate and what happens when multiple are supplied. An agent cannot fully understand the tool's contract 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?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics for the 'url' parameter by explaining normalization behavior, but it completely ignores the other three parameters (host, json, zone), creating confusion about whether they are part of the same operation or separate modes. The schema provides descriptions, but the tool description should coordinate 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 clearly states a specific verb ('Return') and a specific resource ('origin, host, and path for a URL'), and adds the behavior of dropping query and fragment. It is not a tautology and distinguishes the tool's core function, though it does not explicitly contrast it with sibling tools.

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

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

The description gives no guidance on when to use this tool instead of alternatives like validate-json or other sibling tools. It only states what the tool does, leaving the agent to infer the use case without any exclusions, prerequisites, or routing logic.

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 behavioral disclosure, but it only says the catalog is 'short.' It does not state whether the tool is read-only, what it returns, how the input parameters affect behavior, or whether there are any side effects. The word 'catalog' weakly implies a read operation, but this is not made explicit.

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 short sentence with no filler words, so it is concise. However, it is concise to the point of under-specification, providing only a brief noun phrase and no structural detail that helps an agent act on it.

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

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

The description, input schema, and apparent purpose are mismatched: the description promises an HTTP status code catalog while the schema offers unrelated parameters. There is no output schema and no annotations, yet the description does not explain how the four parameters relate to the tool's function, leaving an agent unable to determine a 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 the baseline is 3 even though the description adds no parameter information. The descriptions in the schema are individually clear, but the description does not bridge the gap between the parameters (url, host, json, zone) and the stated purpose of providing HTTP status codes.

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 is a catalog of common HTTP status codes, which gives a general sense of the resource. However, it is a noun phrase with no action verb and closely paraphrases the tool name, and it does nothing to distinguish the tool from siblings like citation, compatibility, normalize, or validate.

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 tools, no mention of prerequisites, and no exclusionary conditions. An agent can only infer that it might be used to reference HTTP status codes, but the description provides no explicit 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?

No annotations are provided, so the description carries the burden. 'Current time' reasonably implies a read-only, non-destructive operation, which is helpful. However, it does not disclose that output varies between calls or that the other schema fields may be 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?

A single, front-loaded sentence with zero filler. 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 simple time lookup, the description is mostly adequate, but the schema's unrelated optional parameters (url, host, json) with no required fields create ambiguity about correct invocation. The description does not clarify which parameter to use or what happens if none are provided.

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 maps to the 'zone' parameter via 'IANA timezone name', but adds no detail beyond the schema. It also leaves ambiguous whether url/host/json are relevant to this tool or belong to sibling behaviors.

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

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

The description states a specific resource and action: 'Current time in a named IANA timezone.' This clearly conveys what the tool does and is distinct enough from siblings like citation, normalize-url, and validate-json, though it does not explicitly name them.

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

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

No guidance is given on when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The only usage signal is implied by the tool name and purpose 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, the description carries the full burden of behavioral disclosure, but it only says what is returned. It does not clarify the timestamp format, whether parameters are accepted or ignored, or whether any side effects occur. For a trivial read-only tool this is less severe, but it is still minimal.

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 short sentence with no filler and is front-loaded. It is concise, though it is so sparse that it sacrifices usefulness for 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?

There is no output schema and no annotations, yet the description does not state the return format or clarify the optional parameters. The unrelated parameters are unexplained, so an agent cannot be fully confident how to invoke it or interpret the result.

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 parameter info in the description. However, the description adds nothing about how url, host, json, and zone relate to a UTC timestamp, leaving an unexplained mismatch.

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 'Current UTC timestamp.' is essentially a restatement of the tool name 'utc-time'. It identifies the result but lacks a verb and does not distinguish this tool from the sibling 'timezone'.

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 this tool versus alternatives like 'timezone' or when not to use it. The description is a bare statement with no selection 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?

With no annotations provided, the description carries the full burden and does contribute one behavioral fact: 'The body is discarded.' However, it doesn't disclose the return value, error behavior, or whether the url/host/zone parameters have side effects, so the transparency is only partial.

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: one states the purpose and the other adds an important behavioral detail. It is efficient and front-loaded, though arguably too terse to fully cover the tool's scope.

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 four schema parameters, no annotations, and no output schema, the description is insufficient. It only hints at the 'json' parameter and says nothing about why url, host, and zone exist or what the validation result looks like, leaving significant gaps for the agent.

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 a small note about discarding the body, which reinforces the 'json' parameter's description, but it does not clarify the role of url, host, or zone, nor does it explain the relationship between 'body' and the 'json' 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 clearly states the verb 'check' and the resource 'whether a body is valid JSON', which directly conveys the tool's core function. However, it does not explicitly map 'body' to the 'json' parameter or distinguish itself from sibling tools like 'schema-url-json', leaving some potential 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?

The description offers no guidance on when to use this tool versus alternatives, no mention of exclusions, and no context about prerequisites. An agent is left to infer when validate-json is the right choice from the name alone.

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