UUID shape check

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 does add a meaningful statelessness guarantee: 'Page content is not stored.' However, it does not clarify whether redirects are followed, how HTTP status is obtained, whether rate limits apply, or what happens with invalid URLs. The single disclosure is useful but not comprehensive.

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 behavior is front-loaded, and the second sentence adds a meaningful caveat. 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 tool has 4 optional parameters with no output schema, and the description only covers the URL use case. An agent seeing 'host', 'json', and 'zone' would not know whether to pass them, whether they are inputs or outputs, or what the return shape looks like. The description is insufficiently complete 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?

Schema description coverage is 100% and each parameter has a reasonable description, so the baseline is 3. The tool description adds minimal value beyond the schema, only implying that 'url' is the central parameter. Notably, it does not explain how the 'host', 'json', and 'zone' parameters relate to the stated URL-focused behavior, leaving an ambiguity that the description should have resolved.

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 and resource: 'Return host, scheme, and HTTP status for a URL.' This clearly explains the tool's primary function. It does not explicitly distinguish itself from siblings like normalize-url or inspect-robots, but the stated output scope is specific enough to infer a unique 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?

The description provides no guidance on when to use this tool versus alternatives such as validate-json or normalize-url, which appear in the sibling list. It also does not mention prerequisites, required inputs, or situations where this tool is appropriate or not. The context is purely implicit in the action described.

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 provide one useful privacy fact ('No identifiers are retained'), but it does not explain side effects, whether inputs are discarded, what kind of response to expect, or what 'classified' actually means. This is too thin for a tool with four heterogeneous parameters.

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 free of filler, and the second sentence adds a privacy-relevant behavioral fact. However, it is under-specified rather than appropriately concise: the first sentence is too vague to carry the meaning it should. It is not bloated, but it is not sufficient either.

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 tool has no annotations, no output schema, four optional parameters, and a set of specialized siblings. The description does not explain expected output, how the parameters select behavior, or why compatibility is the right choice instead of a sibling tool. Too much necessary context is missing.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level detail. The description does not explain how url, host, json, and zone relate to classification, but the schema already documents each parameter individually. No additional semantics are provided 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 gives a verb ('Show') and a subject ('how this request is classified'), so it is not a pure tautology. However, it is vague: it never says what classification means, what inputs are used, or what output is produced. It also does not distinguish this tool from siblings like validate-json or normalize-url.

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 the specialized sibling tools. The description implies some kind of request classification, but it does not state conditions, exclusions, or alternatives. An agent cannot tell whether to call compatibility or validate-json for a JSON input.

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. It offers a helpful hint that the operation is purely lexical, but it fails to disclose what happens with the json input (validated and discarded), what the output format is, or any error/edge-case behavior. The schema hints at 'discarded after the check', but the description itself is nearly silent on 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?

A single sentence with no filler, front-loading the core action and immediately adding a distinguishing constraint. It is efficient, though the brevity may be the cause of some missing 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 four optional parameters and no output schema, the description is too sparse. An agent cannot determine whether to pass url, host, or both, cannot learn what the returned value looks like, and gets no explanation for the unrelated-looking json and zone parameters. The mismatch between the stated purpose and the parameter set is a significant gap.

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 no additional meaning about the parameters, and notably does not explain whether 'url' and 'host' are alternatives or why 'json' and 'zone' are accepted. It neither harms nor improves on what the schema already provides.

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: 'Split a hostname into labels.' It also differentiates the tool from ones that include WHOIS/ownership data. However, it doesn't reconcile this focused purpose with the heterogeneous input parameters (url, host, json, zone), leaving some ambiguity about what the tool actually operates on.

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 'without WHOIS or ownership data' implies this tool is for pure hostname parsing and that other tools are needed when ownership info is required, but it never explicitly names alternatives or states when not to use it. Usage guidance is implied rather than explicit.

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 that common IANA timezone names exist for clock calls; it does not say whether the tool returns a list, validates input, makes a network request, or has any side effects. This is too thin to inform an agent about 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 very short and free of filler, which is positive. But it is under-specified rather than efficiently complete: it omits the action and ignores the surprising parameter set, so brevity comes at the cost of 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?

There is no output schema and no annotations, and the tool has four optional parameters that do not obviously relate to IANA timezone names. The description does not state the return format, clarify which parameters are relevant, or explain how this tool relates to the timezone and utc-time siblings, leaving an agent with significant uncertainty.

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 has its own description, which gives a baseline of 3. However, the description itself adds no parameter semantics and fails to explain why a timezone-names tool accepts url, host, and json fields, leaving the connection between purpose and parameters 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 names a clear resource—'Common IANA timezone names'—and gives a context ('for clock calls'), so an agent can roughly infer the tool provides timezone names. However, it lacks an explicit verb such as 'list' or 'get', and the input schema containing url, host, and json fields creates confusion 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 a usage context, hinting that it belongs with timezone and utc-time tools. But there is no explicit guidance about when to choose this tool over the sibling timezone/utc-time tools, nor any mention of which parameters, if any, should be 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, the description carries the full burden. It does disclose a meaningful behavioral trait — output is summarized to group counts only, not full file contents. However, it omits other relevant behaviors such as network failure handling, redirects, non-robots content, and what 'groups' means, leaving the agent without a complete safety/behavior picture.

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, and the core operation is stated before any constraints.

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 4 parameters, no required parameters, no output schema, and no annotations, the one-sentence description is insufficient. It never says which parameter supplies the robots.txt URL, what 'group counts' look like in the response, or how to handle the seemingly unrelated json/zone parameters. An agent cannot reliably invoke this tool 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 description coverage is 100%, so the baseline is 3; every parameter has its own description and the tool description adds no additional parameter meaning. In fact, the 'url' parameter description ('HTTPS URL to normalize or cite') conflicts with the described robots.txt fetching purpose, which the description does nothing to resolve.

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'), resource ('a public robots.txt'), and output constraint ('return group counts only'), so an agent can tell what the tool is for. It loses a point because the input schema's parameters describe URL normalization, JSON validation, and timezone handling, which do not obviously align with fetching robots.txt, muddying the stated 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?

There is no guidance on when to use this tool versus alternatives, no stated preconditions (e.g., robots.txt must exist, site must be public), and no exclusions. The single sentence implies the use case but never explains under what circumstances an agent should pick this tool.

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 and it does disclose a key behavioral trait: query and fragment are dropped. It also clarifies the output is origin/host/path. It doesn't cover error handling or edge cases, but the main normalization behavior is transparent.

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 wasted words. The main behavior is front-loaded and the dropping of query/fragment is a valuable detail. This is an example of appropriately sized description.

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 optional parameters, no output schema, and no annotations, so the description needs to explain how these parameters fit together. It does not. An agent cannot tell whether to pass `url`, `host`, `json`, or `zone`, or what happens if multiple parameters are provided. The description is incomplete for the full tool contract.

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 has some textual description. However, the description only addresses the `url` use case and leaves `host`, `json`, and `zone` unexplained in relation to the tool's purpose. The input parameter `host` is especially confusing because the description also names `host` as an output, without clarifying its role.

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 operation: return origin, host, and path for a URL, and explicitly notes that query and fragment are dropped. This is clear and matches the tool name, though it does not differentiate 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?

The intended use is implied: use this tool when you need normalized URL components. However, there is no explicit statement of when to use it over alternatives, nor any exclusions or preconditions.

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 full behavioral burden, but it discloses nothing—no indication of what the tool does with its inputs, what it returns, or whether it is read-only or has side effects. The schema hint 'discarded after the check' on json implies some validation behavior, 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 six words with no wasted text, but this is under-specification rather than effective conciseness. For a tool with four heterogeneous optional parameters, the lack of any structural guidance (e.g., how inputs map to behavior) makes the brevity a liability.

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 severely incomplete. Given four unrelated-looking optional parameters, no output schema, and no annotations, the description should explain what the parameters are for and what the agent should expect in return; it explains neither, so an agent cannot reliably select or 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%, with each parameter (url, host, json, zone) already having its own descriptive text, so the schema carries the parameter meaning—baseline is 3. The tool description adds zero parameter-level insight and is actually disjoint from the parameters, but per the rubric the high schema coverage keeps this at baseline.

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

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

The description identifies the subject matter ('common HTTP status codes') and is distinct from the sibling tool names, so an agent can tell this tool is about status codes. However, it lacks a clear action verb—it does not say whether the tool lists, fetches, or looks up the catalog—and it does not explain how the four input parameters (url, host, json, zone) relate to a status-code catalog.

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 usage guidance at all. The description neither states when to use this tool nor mentions any alternative or exclusion condition, leaving the agent to guess from the tool name and sibling list.

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. It discloses the core behavior—returning current time for an IANA zone—which suggests a read-only operation. But it does not describe the output format, behavior on invalid zone names, or whether any of the other schema parameters are ignored or meaningful.

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 phrase with no filler. Every word contributes meaning and directly communicates the tool's purpose.

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

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

The description is minimally viable but leaves gaps: there is no output schema, so return format is unspecified; the schema exposes unrelated parameters (url, host, json) and the description does not clarify that only zone is relevant; and the relationship to sibling tools like utc-time is left implicit.

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 adds no new parameter semantics beyond echoing 'IANA timezone,' which maps to the existing zone parameter 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 description clearly states the tool returns the current time for a named IANA timezone. It is specific about the resource and distinguishes implicitly from siblings like utc-time and iana-zones, though it does not name them or explicitly contrast 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?

Usage context is implied: an agent should use this when it needs the current time in a specific IANA timezone. However, there is no explicit guidance about when to prefer timezone over utc-time or iana-zones, and no mention of what to do with the unrelated schema parameters.

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 the output value and says nothing about whether the tool makes a network call, ignores all parameters, or has any side effects — leaving the agent to guess at runtime 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?

Three words with zero waste, and the core content is front-loaded. It earns high marks for concision, though it is borderline under-specified: one clause clarifying the timestamp format would make it complete without adding meaningful length.

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, four seemingly unrelated parameters, and an overlapping sibling (timezone), the description is not complete enough. An agent cannot determine the return format or whether the declared parameters are accepted, ignored, or required.

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 even though the description adds nothing about parameters. However, the parameters (url, host, json, zone) appear copied from sibling tools like normalize-url and validate-json, and the description does nothing to clarify which, if any, apply to a UTC-time tool — creating real confusion for an agent.

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?

"Current UTC timestamp" clearly names the resource the tool returns, and the word "UTC" helps distinguish it from the timezone sibling. However, it is a noun phrase rather than a verb+resource, and it doesn't explicitly state whether it returns epoch seconds, ISO-8601, or a human-readable string.

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 timezone sibling or any of the other tools. No exclusions, prerequisites, or alternatives are mentioned, so the agent must infer applicability 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.

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

With no annotations, the description carries the full burden, but 'UUID shape check' only restates the name and reveals no side effects, return behavior, failure modes, or prerequisites. It does not even identify which input is checked.

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, but this is under-specification rather than effective conciseness. It has no front-loaded operational detail and leaves every substantive question unanswered.

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 optional parameters, no output schema, and no annotations, the description is far too thin to support correct invocation. It does not say what the tool returns, which parameters to supply, or what 'shape check' means in this context.

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

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

Although the schema covers all four parameters with basic descriptions, the tool description adds no parameter meaning and even introduces 'UUID' without any corresponding parameter. An agent cannot tell from the description how url, host, json, and zone relate to the advertised UUID shape check.

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 'UUID shape check' restates the tool name and does not explain what operation is performed on any of the four parameters. It is also misleading because none of the parameters (url, host, json, zone) is a UUID, and it fails to distinguish this tool from siblings like domain-shape or validate-json.

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 information is provided about when to use this tool versus its siblings. There are no conditions, exclusions, or alternative references, so an agent has no basis to choose this over citation, compatibility, 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?

No annotations are provided, so the description carries the full burden. It does add one meaningful behavioral detail: 'The body is discarded', which tells the agent the input is not stored or returned. However, it does not disclose the return format (e.g., boolean or status), whether any side effects occur, or why the other schema fields (url, host, zone) exist.

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 zero wasted words. The core operation is stated first, and the key behavioral caveat (discard) is placed immediately after. Excellent front-loading and economy.

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 no annotations and no output schema, the description is too thin. It doesn't explain what 'body' maps to in the schema, what the return value is, or how the url/host/zone parameters relate to validation. An agent would struggle to know exactly how to invoke this correctly, despite the clear core purpose.

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 adds no direct parameter-level meaning beyond the discard behavior, which is already stated in the schema's 'json' parameter description. This stays at the baseline 3 because the schema does 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 specific verb and resource: check whether a body is valid JSON. This clearly differentiates the tool from unrelated siblings like normalize-url or timezone, though it doesn't name the sibling it is not. The term 'body' is slightly ambiguous because the schema parameter is named 'json', which prevents a perfect 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 alternatives. There is no mention of prerequisites, exclusions, or scenarios where a different sibling would be more appropriate. The schema and sibling list provide no help either, leaving the agent to infer usage entirely 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.