JSON validity

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 one meaningful behavior: 'Page content is not stored,' which is a genuine privacy/retention trait. However, it does not state whether the tool makes network requests, what side effects might occur, or what the return payload looks like beyond the stated fields.

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 filler. The most important output information is front-loaded, and the privacy caveat is a valuable second sentence. Nothing could be cut without losing meaning.

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 the description covers only the URL-citation path. The tool accepts four unrelated parameter types (URL, host, JSON, timezone), yet the description gives no hint of how they combine or when each is expected. An agent could not correctly invoke this tool for the json or zone parameters based on this 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 coverage is 100%, so the baseline is 3, but the description only explains behavior for the 'url' parameter. The 'json' and 'zone' parameters relate to validation/timezone checking, which are completely unaddressed by the description. This disconnect makes the description actively unhelpful for three of the four parameters, dropping the score below 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 states a clear action and resource: 'Return host, scheme, and HTTP status for a URL.' It names the specific outputs, so the agent knows what to expect. It does not explicitly differentiate from siblings beyond the 'Page content is not stored' caveat, which hints at the citation use case.

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 explicit when-to-use or when-not-to-use guidance is given. The 'Page content is not stored' sentence implies a lightweight citation use case but never names alternatives or conditions for choosing this tool over siblings. The agent is left to infer applicability from the URL-oriented verb phrase 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?

No annotations are provided, so the description carries the full behavioral burden. The 'No identifiers are retained' sentence is a useful privacy disclosure and aligns with the json parameter's 'discarded after the check', but the description does not say whether the tool makes external calls, what the classification result looks like, or whether any state changes occur.

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 purpose statement is front-loaded and the privacy guarantee earns its place. There is zero wasted wording.

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

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

For a tool with four heterogeneous optional parameters, no output schema, and no annotations, this description is insufficient. It does not state what is returned, how the parameters combine or conflict, what the classification categories are, or why a caller would prefer it over the 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%: url, host, json, and zone all have their own descriptions. The tool description adds no meaning about how these parameters relate to the classification and never mentions them, so the baseline 3 applies.

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 has a verb ('Show') and a high-level subject ('how this request is classified'), so it is more than a restatement of the tool name. However, it never defines what 'classified' returns or what 'compatibility' means, and it names no parameters or output, leaving the purpose vague and indistinguishable from siblings like citation and 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 about when to invoke this tool versus the sibling tools. The description mentions no conditions, prerequisites, or exclusions, so an agent must guess from the schema and sibling names which tool fits the task.

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 full behavioral disclosure. It states the tool does not return WHOIS or ownership data but gives no information about side effects, rate limits, or what happens with invalid inputs. The description is safe but sparsely informative.

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 for a tool with four dissimilar parameters. The single sentence could be expanded in a focused way without becoming verbose.

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 four unrelated-looking parameters, the description is not enough for an agent to confidently select and call this tool. It doesn't clarify which parameter is primary, what the return value is, or how the other parameters are used.

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 documents each parameter's basic role. However, the description adds almost no parameter context: it doesn't explain how 'url', 'host', 'json', and 'zone' relate to splitting a hostname, nor which are relevant for that operation. The mismatch between these parameters and the stated purpose is confusing.

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 mentions it excludes WHOIS or ownership data, which distinguishes it from domain-enrichment tools. However, it does not mention the actual URL/host parameters or the variance in other properties, making the scope less clear than it could be.

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 explicit guidance is provided about when to use this tool versus siblings or alternatives. The description only implies a narrow purpose (label splitting) without any exclusions or 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 full burden of behavioral disclosure. It says nothing about side effects, return values, whether the operation is read-only, or how it uses the four schema parameters. An agent cannot tell if calling this tool returns a list of timezone names or validates a supplied zone.

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 under-specified, which is not the same as being usefully concise. The six-word noun phrase contributes no actionable behavior beyond what the tool name already implies, so it does not earn its place as a meaningful definition.

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?

Although the input schema is well-documented, the tool-level description is incomplete: there is no output schema, no annotations, and no explanation of expected return shape, default behavior with zero parameters, or relationship to sibling tools. An agent is left guessing how to call iana-zones correctly.

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

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

Schema description coverage is 100%, and each parameter (url, host, json, zone) already has a clear explanation. The tool description adds no parameter-level meaning and does not explain how these parameters relate to 'IANA timezone names,' so the baseline score of 3 applies.

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 restates the tool name: 'Common IANA timezone names' is essentially an expansion of 'iana-zones.' It lacks a verb, so it does not say whether the tool lists, returns, validates, or normalizes timezone names. The added context 'for clock calls' is too weak to distinguish this from sibling tools like timezone 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 alternatives. The phrase 'for clock calls' hints at a use case, but it does not say what input to provide, what conditions justify calling it, or which sibling tools should be preferred instead.

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. It implies a read-only network fetch and discloses the truncated return format, but it does not mention failure behavior (e.g., 404, non-robots content), redirects, size limits, or whether authentication is ever needed.

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. It conveys the action, the target resource, and the precise scope of the return value efficiently.

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 network-fetching tool with no annotations and no output schema, the description is thin: an agent cannot tell what 'group counts' look like, which of the four generic parameters to supply, or how errors are surfaced. The mismatch between the stated purpose and the parameter schema deepens the incompleteness.

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 guidance. However, the schema parameter descriptions (e.g., 'JSON text to validate' and 'IANA timezone name') appear mismatched with a robots.txt fetching tool, and the description does nothing to clarify which parameters are actually 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 states a specific verb and resource ('Fetch a public robots.txt') and defines the return form ('return group counts only'), which clearly distinguishes it from a generic fetch tool and from the sibling 'citation'. It stops short of a 5 because 'group counts' is left undefined and no explicit differentiation from the sibling is 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 guidance is given on when to use this tool versus the sibling 'citation' or any alternative. The context is implied by the description, but there are no exclusions, prerequisites, or routing hints.

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 full responsibility for disclosing behavior, but it says nothing about what happens during the check, what the output looks like, whether anything is persisted, or what side effects occur. The schema's parameter description mentions that the JSON is discarded, but the main description adds no behavioral transparency.

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 short, but this is under-specification rather than effective conciseness. It provides no structured information and fails to convey the tool's purpose, inputs, 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?

The tool has four optional parameters, no annotations, and no output schema, yet the description consists of just two words. This is entirely inadequate for an agent to determine how to invoke the tool correctly or interpret its results, especially with a similarly named sibling tool available.

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 (url, host, json, zone) already has some documentation. However, the tool description does not explain how these parameters relate to 'JSON validity', and the mixed parameter meanings (URL, hostname, JSON text, timezone) remain unexplained in the description itself. 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 'JSON validity' is essentially a restatement of the tool name 'json-ok' and lacks a verb or explicit statement of what the tool does. It also does not differentiate this tool from the sibling tool 'validate-json', making the purpose 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 versus the clearly overlapping sibling 'validate-json'. The description provides no context, prerequisites, or conditions for appropriate use, leaving the agent to guess.

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 so by stating that query and fragment are dropped, which is non-obvious and important. It does not mention failure modes or return formatting, but for a normalization operation the key behavior is adequately conveyed.

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

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

The description is two terse sentences with no filler. The core output is front-loaded, and the important dropped-parts behavior is given in the second sentence. It is optimally concise.

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 only explains behavior related to 'url'. The purpose of 'host', 'json', and 'zone' is left unexplained, and there is no guidance on how these interact with normalization. This is a significant gap for an agent deciding what arguments to supply.

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 each parameter already has a description. The tool description adds no parameter-specific meaning and, in fact, only addresses the 'url' parameter while ignoring 'host', 'json', and 'zone' entirely, leaving the agent to reconcile the 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 states a specific verb and resource: 'Return origin, host, and path for a URL' and adds the behavioral detail that query and fragment are dropped. This clearly distinguishes it from a generic URL validator or fetcher.

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 use when the agent needs the origin, host, or path with query and fragment removed, so the context is somewhat clear. However, it does not explicitly say when to prefer this over siblings like 'url-clean' or 'http-validate', leaving the agent to infer the distinction.

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, and 'Short catalog of common HTTP status codes' discloses almost nothing. It is inferable that a catalog is read-only, but the description does not state side effects, whether it accepts network inputs (given the url and host parameters), or what the output looks like. It does not contradict annotations because none 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?

Seven words with zero filler and the key noun phrase front-loaded. It is appropriately short, though not a 5 because the brevity comes at the cost of omitting any behavioral or parameter 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?

The tool has 4 optional parameters, no output schema, and no annotations, so the description is the only source of context beside the schema. It does not explain what the tool returns, how url/host/json/zone relate to status codes, or whether network calls occur (which the url and host parameters make plausible). An agent would struggle to invoke this tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds no parameter meaning and creates a domain mismatch: the schema documents url, host, json, and zone, yet the description talks only about HTTP status codes. An agent cannot tell which parameters are relevant or how they map to the catalog, so the description actively reduces parameter clarity despite the schema being complete.

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 resource ('catalog of common HTTP status codes') but uses only a noun phrase with no verb—it never says whether the tool returns a list, looks up a code, or maps codes to reason phrases. Some differentiation from siblings (citation, compatibility, conductor) can be inferred from the domain, but the stated purpose conflicts with the input schema, which contains url, host, json, and zone parameters that have no obvious relation to status codes.

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. There are no conditions, exclusions, or references to sibling tools (citation, compatibility, conductor), so an agent has no basis for choosing status-catalog over its siblings beyond the terse domain 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?

No annotations are provided, so the description carries the full burden. It accurately indicates a read operation but does not disclose what happens with the unrelated url/host/json parameters, whether invalid IANA zone names produce errors, or what the returned time format is. The mismatch between the description (current time) and the schema (URL normalization/JSON validation) is a 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?

Eight words with no filler and the essential meaning front-loaded. Every word earns its place; it is terse but not impaired for a simple read operation.

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 the simple concept, the tool is incomplete for calling: zero required parameters contradict the need for a zone, the url/host/json parameters are unexplained in relation to the tool's purpose, and there is no output schema to define the return. An agent cannot confidently construct a correct call.

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 zone is described identically in both places ('IANA timezone name'). The description reinforces the key parameter but adds no detail about the other three parameters, so the schema does the heavy lifting. 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 the operation clearly: return the current time for a named IANA timezone, which distinguishes it from siblings like citation and normalize. However, it ignores three schema parameters (url, host, json) that appear unrelated to time, creating ambiguity about the tool's actual scope.

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?

Provides no guidance on when to use timezone versus citation, compatibility, inspect, or normalize. It neither states prerequisites (e.g., zone is effectively required despite the schema marking it optional) nor when not to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Current UTC timestamp' hints that this is a read-only operation, but it does not state the return format (ISO string, Unix epoch), whether parameters are accepted or discarded, or any other behavioral context. The disconnect between the one-liner and the 4-parameter schema adds confusion rather than transparency.

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?

Four words with zero filler, perfectly front-loaded. The size is appropriate for a trivial time lookup, though the brevity comes at the cost of substance that is better penalized in other dimensions.

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 four seemingly unrelated parameters, a one-phrase description is far from sufficient. An agent lacks critical information: parameter relevance, output format, and how this tool differs from the sibling 'timezone' tool. This is functionally inadequate for 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%, which sets a baseline of 3, but the description adds nothing about the parameters and the schema's parameters (url, host, json, zone) appear entirely irrelevant to fetching a current UTC timestamp. An agent cannot tell which, if any, parameters actually affect the call, and the description does not clarify the relationship.

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's output — the current UTC timestamp — which is a clear basic purpose. However, it lacks a verb, does not differentiate itself from the sibling tool 'timezone', and is undermined by an input schema describing url/host/json/zone parameters that have nothing to do with getting the current 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 description offers no guidance on when to use this tool versus alternatives like 'timezone'. There are no usage conditions, exclusions, or mention of whether the declared parameters are used or ignored, so an agent has no basis for choosing or invoking it correctly.

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 description discloses a useful behavioral trait: 'The body is discarded' implies the operation is non-persistent and side-effect-free. However, with no annotations and no output schema, it does not explain return values, error handling, or what happens with invalid JSON, leaving a notable 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?

Two short sentences are front-loaded and contain no filler. The purpose and a key behavioral note are stated directly, making the description easy to parse quickly.

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

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

For a tool with four parameters, no output schema, and no annotations, the description is too sparse. It does not specify which parameter holds the JSON body, what a successful or failed validation returns, or how to interpret the extraneous parameters. More detail is needed for an agent to invoke it correctly.

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

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

Schema descriptions cover all four parameters, so the baseline is 3. The description itself adds no parameter-level meaning, leaving the agent to infer that the 'json' parameter is the relevant one. It does not clarify why 'url', 'host', and 'zone' are present or how they relate to the validation.

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 verb and resource: 'Check whether a body is valid JSON.' This conveys the core purpose without ambiguity. However, it does not explicitly differentiate itself from sibling tools like '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?

No guidance is given on when to use this tool versus alternatives. It does not mention conditions, exclusions, or which sibling tool to prefer in different scenarios. The sentence 'Check whether a body is valid JSON' implies context but never states it explicitly.

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