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?
The description explicitly states 'The body is discarded,' which clarifies that the tool does not persist or modify data. This is a useful behavioral note. However, it does not mention what the tool returns (e.g., a boolean success/failure), which could be important for the agent to know.
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 exceptionally concise, consisting of two short sentences. It conveys the core functionality without any unnecessary words or fluff. This is ideal for a simple 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?
The description leaves significant gaps in context. It does not explain why url, host, and timezone parameters are present, nor does it clarify their relationship to the validation task. An agent might be confused about whether these parameters are required or how they affect the operation. The minimal description is insufficient for fully understanding the tool's interface.
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. While the schema provides descriptions for each parameter, those descriptions are largely inconsistent with the tool's purpose (e.g., 'HTTPS URL to normalize or cite' for url, 'IANA timezone name' for timezone). The only relevant parameter is 'json,' but the description's mention of 'body' does not explicitly map to it. The description adds no clarity to the parameter list.
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.' The verb 'check' and resource 'body' are specific, and the tool name 'validate-json' aligns perfectly. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it implicitly suggests using it for JSON validation, there is no mention of scenarios, edge cases, or comparison with other tools. The usage is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear, distinct purpose: URL parsing, HTTP status codes, timezone handling, JSON validation, and robots.txt fetching. Even overlapping areas like URL tools focus on different aspects (origin/path vs. host/scheme vs. domain labels).
All tool names follow a consistent lowercase-with-hyphens convention (e.g., normalize-url, validate-json). No camelCase, underscores, or mixed styles, making the naming pattern predictable and uniform.
With 11 tools, the set sits within the typical 3-15 range. The domain is a mix of unrelated utilities (URL, time, JSON, HTTP), which feels slightly unfocused but not excessive.
The tools cover common operations for their respective areas: URL parsing, time/UTC, JSON validation, and HTTP status. Minor gaps exist (e.g., no URL encoding/decoding or generic HTTP request tool), but the current set is reasonably comprehensive for its stated purposes.