ISO 639 language tag ja.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does add one useful privacy trait ('Page content is not stored'), but it does not disclose whether the tool makes network requests, what side effects occur, how json/zone inputs behave, or any rate/auth limitations. This is insufficient for a tool with no annotation coverage.
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 concise sentences with the core behavior front-loaded and no filler. The privacy note is relevant and earns its place. However, the brevity is achieved by omitting the json/zone behaviors, making it concise but incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and no annotations, and the description covers only the URL-related behavior. The tool accepts four parameters spanning URL, host, JSON, and timezone, but the description gives no context for json/zone or how they relate to 'citation'. An agent cannot determine whether this tool overlaps with validate-json or timezone.
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 actively undermines parameter clarity by listing 'host' as an output while the schema defines it as an input. It also ignores json and zone entirely, so an agent cannot infer their roles from the description. This ambiguity prevents the description from adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Return host, scheme, and HTTP status for a URL') and adds a privacy note. However, the input schema includes json and zone parameters that the description ignores, so the stated purpose is incomplete and may mislead an agent about the tool's full scope. It also does not differentiate the tool from siblings like normalize-url or status-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 guidance on when to use this tool versus siblings such as normalize-url, status-catalog, validate-json, or timezone. The description implies URL checking but provides no selection criteria, exclusions, or alternative routing.
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 privacy note 'No identifiers are retained' adds some transparency, but the description does not disclose whether the tool has side effects, what it returns, or how it behaves beyond classification. No annotations compensate for this lack of detail.
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 unnecessary detail, which is concise. However, the brevity contributes to vagueness, so it does not fully earn a top score.
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 vague description and lack of output schema, the tool's purpose, behavior, and expected result are not sufficiently explained. More context is needed for an agent to know when and how 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?
Each parameter has a schema-level description, but the overall description does not explain how the parameters relate to the classification logic. The parameter descriptions are present but add little semantic context beyond their 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 'Show how this request is classified' is vague and does not specify what kind of classification is performed or what the tool actually does. 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical use cases, or conditions under which this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
The description includes a negative claim ('without WHOIS or data') which hints at what the tool does not do, but it is vague and does not disclose side effects, permissions, or data handling. No annotations are present to supplement 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 very short but the wording is unclear and potentially misleading. The phrase 'without WHOIS or data' adds confusion rather than clarity, making it inefficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for the tool's complexity. It does not describe expected inputs, outputs, or relationships to the parameter set, and the mismatch between the stated purpose and the given parameters leaves the agent without sufficient context 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?
The description does not explain any of the parameters (url, host, json, timezone). Although the schema provides descriptions, they are generic and mismatched (e.g., 'json' as 'JSON text to validate'), and the tool description adds no clarification or connection to the actual purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action ('Split a hostname into labels'), which is specific and distinguishes it from sibling tools like normalize-url or validate-json. However, the phrase 'without WHOIS or data' is ambiguous and may confuse about the tool's exact 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of appropriate contexts, limitations, or comparisons to sibling tools, leaving the agent without direction.
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 behavioral burden, but it says nothing about what the tool returns, whether it is a read-only lookup, or how invocation behaves. It only names the content ('IANA timezone names') without disclosing the tool's actual 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 brief and front-loaded, but it is under-specified rather than appropriately concise. It omits the operational meaning that the tool name and schema leave ambiguous, so the single sentence does not carry enough useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, and with four mostly unrelated optional parameters, this description is far too thin for an agent to know how to call the tool or interpret its result. The mismatch between the description (timezone names) and the parameters (url, host, json) makes the gap especially severe.
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 applies; the schema already documents url, host, json, and zone. The description adds no param meaning, and it does not clarify why url/host/json appear alongside 'zone' or which parameters a clock-call use case should pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun phrase — 'Common IANA timezone names for clock calls' — with no verb or operation, so it does not explicitly state that the tool lists, returns, or resolves zones. It mostly restates the tool name 'iana-zones' and does not differentiate it 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 choose this tool over alternatives such as timezone, utc-time, or normalize-url. The phrase 'for clock calls' is the only hint, and no prerequisites, exclusions, or sibling comparisons are provided.
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?
With no annotations, the description carries the full burden. It discloses that only counts are returned, not the full robots.txt, and that the target must be public. However, it does not mention network failure behavior, redirects, or how the target URL/host is resolved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence. Every word earns its place, and 'group counts only' prevents over/under expectation of the output.
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 and no annotations, and the description does not explain how the four optional parameters select the robots.txt to fetch or what happens on fetch failure. Given the mismatched parameter descriptions, an agent lacks enough information to call it reliably.
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 applies. However, the schema's parameter descriptions are generic ('JSON text to validate', 'IANA timezone name') and do not clearly connect to robots.txt. The description adds no mapping between url/host and the fetch target.
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 the exact resource ('public robots.txt') and the exact output ('group counts only') with a specific verb ('Fetch'). It also distinguishes this tool from siblings like validate-json, normalize-url, and iana-zones, none of which target robots.txt.
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 the use case (inspect a site's robots.txt group counts) but never states when to prefer it over siblings or when not to use it. No alternatives or exclusion conditions are named, so an agent must infer applicability 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.
ISO 639 language tag ja.
| 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 must carry the full burden of behavioral disclosure. It reveals nothing about side effects, return values, or how the parameters (url, host, json, zone) relate to the tool's function. The tool name suggests a language constant but the parameters imply other operations, creating confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but it is under-specified rather than concise. It omits essential functional details, so it is not 'earned' conciseness but rather an empty placeholder.
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 four parameters and no output schema, the description is grossly incomplete. It does not explain what operation is performed, what the expected output is, or how the parameters interact. The description is inadequate for an agent to call 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 each parameter already has a description. The tool description adds no parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate. However, the apparent mismatch between the tool name and parameter domains is a concern, but that is not penalized here.
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 'ISO 639 language tag ja' merely restates the tool name (lang-ja) and does not state any action, resource, or behavior. It is a tautology and provides no differentiation from siblings.
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, when not to use it, or which alternatives (siblings) might be more appropriate. The description is silent on usage context entirely.
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?
The description discloses that query and fragment are dropped, which is helpful behavioral information. However, with no annotations, it does not cover potential errors, return format, or expected behavior for malformed URLs, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. It states the primary output and the key transformation in two short sentences with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers its core function, but the presence of extraneous schema parameters and lack of return format or error behavior make the overall context incomplete. The tool description does not fully account for the provided schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains four parameters, but the description only explains the 'url' parameter. The descriptions for 'host', 'json', and 'zone' appear irrelevant to a URL normalization tool and are not reconciled in the description, causing significant semantic confusion.
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 origin, host, and path for a URL and drops query and fragment. It uses a specific verb and resource, and is distinct from sibling tools like validate-json or inspect-robots, though it does not explicitly name a sibling.
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 describes what it does but not the conditions under which a user should choose it over other tools such as citation or inspect-robots.
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?
With no annotations provided, the description bears the full burden of disclosing behavior. It only states that the tool is a catalog, but does not explain how the parameters affect the output, whether the tool performs any side effects, or what the response format looks like. This is insufficient 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 brief and contains no redundant words, which supports conciseness. However, the structure is a single noun phrase without any verb or action orientation, making it functionally incomplete rather than appropriately structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks any context about return values, error handling, or how the tool integrates with the sibling tools. Given the mismatch between the purpose and parameters, the description is far from complete for an agent to understand when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema covers 100% of parameters with descriptions, those descriptions (e.g., 'HTTPS URL to normalize or cite', 'IANA timezone name') are unrelated to the stated purpose of HTTP status codes. The description adds no meaning linking the parameters to the tool's function, so the parameter semantics are effectively unexplained.
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 'Short catalog of common HTTP status codes' states a noun phrase rather than a verb, leaving unclear what action the tool performs (e.g., retrieve, list, or explain). It also does not differentiate from sibling tools like validate-json or normalize-url, and the parameters (url, host, json, zone) bear no apparent relation to HTTP status codes, making the stated purpose misleading.
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. There is no mention of scenarios, prerequisites, or conditions that would make this tool the appropriate choice, especially given the unrelated parameter set.
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?
There are no annotations at all, so the description must carry full behavioral burden, but it only states a fact, not the tool's behavior. It does not disclose the output format, error behavior for invalid zones, whether the time is formatted, or that the operation is read-only. This is too thin for a agent-facing description without other structured metadata.
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 that directly and immediately conveys the core operation. No waste or filler. This is a model of conciseness, though it leaves key usage details unsaid.
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 no output schema, no annotations, and an input schema with several irrelevant properties, the description does not consistently equip an agent to invoke the tool successfully. It does not clarify which parameters are ignored, what this result looks like, or how it differs from nearby times-related 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?
Although the schema has 100% description coverage, it contains three parameters ('url', 'host', 'json') unrelated to the timezone purpose, and the description does not clarify that only 'zone' is relevant. The description adds nothing beyond the schema's own parameter descriptions and fails to correct a potential misuse where an agent could supply irrelevant properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific result type ('current time') and the exact resource ('named IANA timezone'), making the core purpose intelligible. It is naturally distinguished from utc-time by the named timezone aspect, though it lacks an explicit verb and sibling awareness. Overall it is clear but not quite as explicit as a full 'get current time from a zone' phrase.
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 vs alternatives such as utc-time or iana-zones. It does not mention prerequisites, typical queries, or why an agent should pick this over siblings. The reader must infer the use case from the description alone.
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, the description must disclose behavioral details, but it only states 'Current UTC timestamp.' It does not explain the return format, precision, timezone handling, or whether the four schema parameters are accepted or ignored. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, nearly a label rather than a full sentence. While short is good, the brevity sacrifices necessary behavioral and usage detail, making it under-specified rather than efficiently complete.
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 tool's apparent simplicity, the description omits the return format, ignores the four-input schema, and provides no differentiation from timezone-related siblings. The absence of an output schema and annotations raises the burden, which this single phrase does not meet.
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 parameter-specific meaning, and it fails to clarify that url, host, json, and zone appear unrelated to fetching the current UTC time.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: returning the current UTC timestamp. It distinguishes the tool from siblings like timezone and iana-zones by focusing on UTC time, though it lacks an explicit verb such as 'returns' or 'gets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of siblings like timezone or iana-zones. The description implies a simple use case but provides no context, exclusions, or alternatives.
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, so the description carries the full burden. It does disclose that 'the body is discarded,' which is a useful behavioral trait (no persistence). However, it fails to clarify that the schema contains unrelated parameters (url, host, zone) that appear to be ignored, and it does not mention error behavior or return format. The description is too sparse to fully inform the agent about side effects or constraints.
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 (two sentences) and front-loaded with the core purpose. However, it is under-specified; it omits critical information about parameter usage and potential side effects. The brevity is not a virtue here because it leaves gaps that the agent must infer.
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's apparent simplicity, the description is incomplete. It does not explain how the json parameter should be provided (e.g., as a string), what the return value is, or how the unrelated schema parameters are handled. With no output schema and no annotations, the description should cover these aspects. The presence of four parameters with only one relevant to the tool's purpose is a significant gap that the description does not address.
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 a description. However, the description does not add value beyond the schema and fails to explain why url, host, and zone are present when the tool only validates JSON. The 'body' terminology conflicts with the 'json' parameter, and the description does not clarify that only the json field is used. This creates confusion and does not compensate for the extraneous parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check whether a body is valid JSON.' This is a specific verb (check) and resource (JSON validity). It distinguishes from siblings like normalize-url and timezone, which are unrelated. However, the term 'body' is slightly ambiguous and not aligned with the schema's 'json' parameter, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any conditions, exclusions, or related tools. For a validation tool, it might be obvious, but the lack of any context about when to prefer it over other tools (e.g., compatibility or status-catalog) leaves the agent without routing information.
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-robotslang-janormalize-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!
Add one secure layer between your agents and this server.
Each tool has a unique, well-defined purpose with no overlapping functionality. For example, 'normalize-url' and 'validate-json' address distinct concerns, and time-related tools are clearly separated.
Tool names follow a mix of conventions: some are verb-object (normalize-url, validate-json, inspect-robots), while others are noun phrases (citation, compatibility, timezone). This inconsistency makes the naming pattern less predictable.
With 11 tools, the count is reasonable and not excessive. Each tool covers a separate utility, though a few could arguably be merged (e.g., timezone and utc-time), but the number is still within a sensible range.
The server name 'Language ja' suggests a language-related domain, yet the tools cover miscellaneous web utilities (URL handling, HTTP status, time, JSON). This mismatch and lack of a cohesive domain make the surface feel incomplete for any specific purpose.