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 |
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 present, the description carries the full burden of transparency. It does disclose that 'Page content is not stored,' which is a useful side-effect note. However, it does not mention other behaviors like network requests, rate limits, or error handling, leaving several behavioral aspects undisclosed.
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 succinct, consisting of two short sentences. It conveys the core functionality and a key privacy note without any fluff, making it easy to read and process.
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 gives a basic idea of what the tool does but omits critical context. It lacks information about the other parameters, the output format (despite mentioning fields), and any constraints or prerequisites. Given the additional parameters and sibling tools, this level of detail is insufficient for an agent to reliably select and invoke 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?
The description mismatches the input schema. It discusses 'URL' as the primary input and mentions output fields (host, scheme, HTTP status), but the schema includes additional parameters (host, json, zone) that are not explained. This creates confusion about the role of each parameter, especially since one parameter is named 'host' but the description implies host is an output.
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 function: 'Return host, scheme, and HTTP status for a URL.' This is specific and indicates the core action. However, it does not mention the other parameters (host, json, zone), which slightly reduces clarity about the tool's full 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 provides no explicit guidance on when to use this tool versus the sibling tools (e.g., normalize-url, status-catalog). It only mentions a privacy aspect ('Page content is not stored'), but does not explain the intended use cases or selection criteria.
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.