JSON byte count, body discarded
Return host, scheme, and HTTP status for a URL. Page content is not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only notes that page content is not stored, but does not disclose other potential side effects or behaviors (e.g., network calls, caching, or failure modes).
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 and easy to read, but it omits mention of several parameters, making it structurally incomplete. It is not overly verbose, but the brevity sacrifices necessary 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?
The tool appears to have multiple unrelated parameters, no output schema, and no explanation of how the parameters interact with the stated purpose. The description is insufficient to understand how to correctly 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?
All four parameters have descriptions, but they seem mismatched with the stated purpose (e.g., 'json' implies validation, 'zone' implies timezone). The main description does not explain how these parameters are used, making their semantics 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 it returns host, scheme, and HTTP status for a URL, but it does not explain how the parameters 'json' and 'zone' relate to this purpose, leaving the tool's full scope unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling tools (e.g., normalize-url, validate-json, timezone), and no alternative conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show how this request is classified. No identifiers are retained.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral information is the privacy note 'No identifiers are retained', which is helpful but does not disclose other side effects, external dependencies, or whether the tool modifies any state. Without annotations, the description fails to provide adequate 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 concise and readable, but it is too brief to convey the necessary meaning. It avoids verbosity, yet the sentence structure leaves critical details unstated, making it less useful than a more explicit description would be.
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 heterogeneous parameters and no output schema, the description is severely incomplete. The agent cannot infer what results to expect, how the parameters interact, or what 'classification' means in this context. The description fails to provide the information needed to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter names (url, host, json, zone) are self-explanatory, but their descriptions are generic and seem copied from other tools (e.g., 'HTTPS URL to normalize or cite' suggests unrelated functionality). The description does not explain how these parameters relate to the classification logic or each other.
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 'Show how this request is classified' but fails to specify what kind of classification is performed, which inputs are used, or what 'compatibility' refers to. The verb 'Show' indicates a read operation, but the actual functionality remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like validate-json, normalize-url, or status-catalog. The description does not distinguish its purpose from alternatives or offer any selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Split a hostname into labels without WHOIS or ownership data.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral side effects, inputs, or outputs. It is unclear what the tool actually does with the provided parameters (url, host, json, timezone), and whether it has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is not effective. It lacks essential information and the single sentence is unclear. Conciseness is not beneficial when it omits critical details needed to understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools (e.g., normalize-url, validate-json), the description does not explain how this tool fits into the broader context. There is no output schema or further details, leaving the tool's functionality and relationship to the parameters completely unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameters (url, host, json, timezone) are not explained in the description. Their names are generic and the description does not map them to the stated action of splitting a hostname into labels. The schema provides no additional context beyond field names.
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 'Split a hostname into labels without WHOIS or data' is vague and confusing. It does not clearly state the tool's purpose, and the mention of 'without WHOIS or data' is ambiguous. It fails to distinguish this tool from siblings like normalize-url 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 guidance is provided on when to use this tool versus alternatives. The description does not mention any use cases, prerequisites, or context where this tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Common IANA timezone names for clock calls.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It fails to disclose whether the tool is read-only, makes network calls, returns data, or has side effects. The vague wording gives no behavioral insight.
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 single-sentence description is concise and front-loaded with the key term 'IANA timezone names', but the brevity sacrifices essential clarity. Structure is acceptable, yet the content is insufficient to convey the tool's 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?
With 4 parameters, no output schema, and no annotations, the description carries a heavy context burden. One vague sentence is insufficient—an agent cannot determine what the tool does, what it returns, or how to construct a valid 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?
While schema coverage is 100%, the parameter descriptions appear mismatched with the tool's purpose—url, host, and json relate to other tools (normalize-url, validate-json), while only zone relates to IANA timezones. The tool description adds no clarification about which parameters are relevant or how they are used.
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 'Common IANA timezone names for clock calls' is vague. It names a resource (IANA timezone names) but lacks a clear verb—does it list, validate, or look up these names? 'For clock calls' is ambiguous jargon. It doesn't clearly distinguish from sibling tools like timezone or utc-time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool over alternatives. Sibling tools include timezone and utc-time, which likely overlap, but the description provides no conditions or criteria for choosing iana-zones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a public robots.txt and return group counts only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'Fetch' implying network access, but does not disclose side effects, error behavior, rate limits, or whether it modifies anything. With no annotations provided, the transparency is limited to stating the output format. More detail would be needed for the agent to understand 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 concise and to the point, but it omits essential information about parameters and usage. While brevity is good, the structure lacks any breakdown of inputs or outputs, making it less effective than it could be.
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 given the context. The presence of irrelevant parameters (json, zone) and lack of explanation for them makes the tool contextually confusing. It does not provide enough information for an agent to correctly invoke it without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter descriptions are generic and mismatched. 'url' and 'host' plausibly relate to fetching robots.txt, but 'json' and 'zone' are irrelevant and described with boilerplate text (e.g., 'JSON text to validate' and 'IANA timezone name') that does not clarify their role. The description does not rescue the schema, leaving the agent confused about why these parameters exist.
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 ('Fetch') and resource ('public robots.txt') and specifies the output ('return group counts only'). This distinguishes it from sibling tools like validate-json or timezone, which have different purposes. However, it could be slightly more explicit about the intended 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?
There is no guidance on when to use this tool versus alternatives. While the purpose is clear, the description does not mention conditions, prerequisites, or situations where this tool is preferred. This lack of usage direction reduces its utility.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
JSON byte count, body discarded
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
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 mentions 'body discarded' but gives no insight into what the tool actually does, what it returns, whether it makes network requests, or any side effects. This is severely lacking for a tool with four 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 extremely terse (7 words), but this is under-specification, not conciseness. It front-loads 'JSON byte count' but provides no supporting context or structure, so it does not earn its place as useful 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?
With four parameters, none required, no output schema, and no annotations, the description is completely inadequate. An agent cannot infer what inputs are needed, what the output format is, or what error conditions might occur. This is a grossly incomplete definition for a tool of this complexity.
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%, giving each parameter a one-line description (e.g., 'JSON text to validate; discarded after the check'). However, the tool description adds nothing to explain how these parameters relate to each other or to the stated 'JSON byte count' purpose. It is unclear why URL, host, and zone are needed if the tool only counts JSON bytes, so the description fails to add meaningful semantics 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 'JSON byte count, body discarded' is a fragment, not a full sentence. It doesn't state a clear verb+resource action or explain what the tool does with the URL, host, or zone parameters. It fails to distinguish this tool from siblings like validate-json or normalize-url, leaving the agent guessing its 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. The description gives no context about the intended use case, prerequisites, or conditions under which this tool should be selected over its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return origin, host, and path for a URL. Query and fragment are dropped.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does mention that query and fragment are dropped, which is useful, but it does not disclose other important behaviors such as URL validation, handling of invalid inputs, return format, or whether any network request is made.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively communicates the core behavior without unnecessary words or redundancy.
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 does not provide sufficient context for an agent to use the tool correctly. It omits return format, error behavior, and does not address the seemingly unrelated parameters in the schema. The mismatch between the description and the input schema leaves too much ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema includes four parameters (url, host, json, zone) with descriptions that are largely irrelevant to normalizing a URL. The description only clarifies the 'url' parameter by implication, and does not resolve the confusion caused by the unrelated 'host', 'json', and 'zone' parameters. This is a serious semantic 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 clearly states the tool's purpose: it returns the origin, host, and path of a URL and explicitly drops query and fragment components. This is a specific, action-oriented description with a clear resource and 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?
The description does not mention when to use this tool versus alternatives. Given the sibling tools include domain-shape, inspect-robots, and status-catalog, explicit guidance on when normalize-url is appropriate would be valuable, but none is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Short catalog of common HTTP status codes.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not explicitly state whether the tool is read-only or has side effects. While a catalog implies no modifications, this is not stated, and the mismatch of parameters further obscures behavior. No annotations are available to supplement the description.
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 and free of fluff, which is concise. However, it omits essential information about parameters and usage, so the brevity works against clarity. It is not well-structured for the agent's needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, the description should still explain what the tool returns, how parameters are used, and how it differs from siblings. It lacks all of this. The parameter mismatch and missing output details make the tool unusable as described.
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 descriptions cover 100% of parameters, the descriptions (e.g., 'HTTPS URL to normalize or cite', 'JSON text to validate') are clearly copied from other tools and are nonsensical for a status-code catalog. The description fails to explain how these parameters should be used, making them misleading.
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 provides a 'Short catalog of common HTTP status codes', which gives a basic purpose. However, it is vague about what operations are supported (e.g., lookup, list) and how the provided parameters relate to that purpose, leaving the agent uncertain about how to use it.
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 tools (e.g., for status code lookup vs. URL normalization or JSON validation). There is no mention of prerequisites or typical use cases, making it impossible to differentiate from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current time in a named IANA timezone.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
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 'current time' without specifying output format, behavior on invalid zones, or that only the 'zone' parameter is used while url, host, and json are ignored. This is a significant omission for a tool with 4 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?
A single sentence with no fluff. It is concise and front-loads the core behavior. Every word earns its place, though it could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (but likely only one matters), no output schema, and no annotations, the description is far from complete. It does not mention error handling, return format, or that other parameters are ignored. An agent would need to guess or inspect the schema to understand the actual usage, which is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, so the baseline is 3, but the description adds no meaning beyond the schema. It does not clarify that only 'zone' is relevant or explain the presence of unrelated parameters (url, host, json). The description fails to help an agent understand which parameters matter, making the tool harder to invoke correctly.
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 core function: returning the current time for a named IANA timezone. It uses a specific verb ('Current time') and resource ('named IANA timezone'). However, it does not differentiate from siblings like utc-time or iana-zones, and the schema includes unrelated parameters (url, host, json) that muddy the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as utc-time (for UTC) or iana-zones (for zone listings). The description does not mention exclusions, prerequisites, or when it is inappropriate. The usage context is only implied by the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current UTC timestamp.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
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 only says it returns a timestamp and does not mention how the parameters affect the result, whether it performs any side effects, or whether it is read-only. This is insufficient for a tool with such seemingly unrelated 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 very short and front-loaded, but it is under-specified given the parameter complexity. It is concise but lacks necessary detail, making it borderline between appropriate brevity and insufficient specification.
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 no output schema, so the description should clarify what is returned (it does mention a timestamp), but it fails to explain how the parameters are used or why they exist. The agent cannot correctly invoke the tool without understanding the role of the parameters, so the description is incomplete for a tool with this many inputs.
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 nothing about how these parameters influence the timestamp, and the parameters appear disconnected from the tool's stated purpose. However, since the schema documents them, 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 'Current UTC timestamp' states a clear purpose, but it does not explain how the four parameters (url, host, json, zone) relate to generating a timestamp. It also fails to distinguish this tool from the sibling 'timezone' tool, leaving the agent to guess when to use which.
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 like 'timezone' or 'iana-zones'. No context is given for appropriate use cases, nor are any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a body is valid JSON. The body is discarded.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | HTTPS URL to normalize or cite | |
| host | No | Public hostname | |
| json | No | JSON text to validate; discarded after the check | |
| zone | No | IANA timezone name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says the body is discarded. It does not state what the tool returns, how success or failure is indicated, or whether it reads the request body rather than the json parameter.
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 sentence with no fluff, and the action is front-loaded. It loses a point because the parameter ambiguity is not addressed, but the text itself is appropriately 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?
With four parameters and no output schema, the description leaves major gaps: which parameter is the body, what result is produced, and why url, host, and zone are included. The tool cannot be used effectively based on 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?
Although schema coverage is 100%, the descriptions for url, host, and zone are generic and irrelevant to JSON validation. The json parameter is clear, but its relationship to the 'body' mentioned in the description is ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The core purpose is clear: check whether a body is valid JSON. However, the presence of unrelated parameters like url, host, and zone muddies the overall scope and makes the actual object of validation 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 sibling tools. No mention of alternatives like json-bytes or any validation workflow context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
citationcompatibilitydomain-shapeiana-zonesinspect-robotsjson-bytesnormalize-urlstatus-catalogtimezoneutc-timevalidate-jsonClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Check whether text is valid JSON. The body is discarded.
Add one secure layer between your agents and this server.
Score is being calculated.