Everything we hold about one domain: whether it is registered, what it costs to claim AND what it renews at, and where each number came from. Pass a domain name as the id, for example "atlas.io".
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A domain name. |
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| url | Yes | ||
| text | Yes | Everything we hold, as prose. | |
| title | Yes | ||
| metadata | Yes |
Changes observed during successful MCP inspections.
Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "metadata": {
+ "type": "object"
+ },
+ "text": {
+ "description": "Everything we hold, as prose.",
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "text",
+ "url",
+ "metadata"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden, and it does disclose the categories of returned data (registration status, claim vs renewal price, provenance). It implies a read operation but never states that explicitly, and gives no information about permissions, rate limits, or behavior on unknown/unregistered domains.
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?
Two front-loaded sentences that state scope first and the input convention second; no filler. Slightly dense capitalization ('AND') but structurally efficient and appropriately sized for a one-parameter 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?
An output schema exists, so return values need no prose explanation, and the single parameter is fully documented. The description covers what data is retrieved and the input format. The main remaining gap is the absence of any disambiguation from adjacent tools, which the usage dimension already penalizes.
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% and the schema already defines id as 'A domain name.', so the baseline is 3. The description adds meaning beyond that by giving a concrete example ('atlas.io'), clarifying the expected format is a bare domain with no scheme or path.
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 scope: it returns registration status, claim price, renewal price, and provenance for a single domain. 'Everything we hold about one domain' is a clear aggregate-fetch purpose. It does not, however, explicitly contrast itself with overlapping siblings such as quote_domain, check_live, or audit_domain, so the agent must infer the boundary.
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 explicit when-to-use or when-not-to-use guidance and no named alternative. The only 'how' instruction is the format of the id, which is parameter-level, not usage routing. With siblings like quote_domain and check_live that could plausibly overlap, an agent gets no help choosing.
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.