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 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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 states 'The body is discarded,' which implies a side effect, but it does not describe the return value (e.g., boolean, error message), error handling, or whether the tool has any other effects. The description is too thin to fully inform an agent about the tool's 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 extremely concise, consisting of two short sentences with no wasted words. It front-loads the primary purpose. However, the brevity comes at the cost of missing essential usage and behavioral details, which is a structural trade-off but not a verbosity issue.
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 validation tool, the description omits critical information: the return format, how to handle invalid JSON, and the relevance of the other three schema parameters. Without an output schema, the agent cannot know what to expect. The description also fails to connect this tool to the sibling set, leaving the agent to guess when it should be 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?
The schema provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds the term 'body' to refer to the JSON input, but it does not clarify which parameter that corresponds to, nor does it add meaning to the url, host, or zone parameters. The added value is minimal but not 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 clearly states the tool's function: 'Check whether a body is valid JSON.' It uses a specific verb (check) and resource (body/JSON), and it is distinguishable from sibling tools that deal with URLs, timezones, or domains. However, it does not explicitly map 'body' to the 'json' parameter in the schema, leaving slight ambiguity about which input is validated.
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. It does not mention prerequisites, such as needing a URL or specific context, nor does it state when not to use it. The description only says what it does, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.