PNTR

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, covering the safety profile. The description adds only the precondition that the subdomain must already exist; it says nothing about duplicate/conflicting records, what happens on failure, or whether adding the same record twice creates duplicates.

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?

A single sentence with the action and scope front-loaded and no filler. Nothing is wasted.

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 mutation tool with four parameters, full schema coverage, and annotations, the description is thin but not inadequate. It omits preconditions and record-conflict behavior that an agent would benefit from knowing before adding a DNS record.

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 all four parameters (including the MX-only priority rule and the record_type enum) are already documented in the schema. The description adds no parameter detail beyond that, so the baseline 3 applies.

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?

States a specific verb (Add) and resource (DNS record) plus a scope qualifier (to an existing subdomain), so an agent immediately knows this is a record-creation tool. It does not distinguish itself from sibling tools beyond the obvious add/delete pairing with delete_dns_record, so it falls short of a 5.

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 when-to-use guidance, no mention of prerequisites (e.g., the subdomain must already be registered), and no routing to alternatives. The only implied usage comes from the phrase 'existing subdomain,' which is a constraint rather than guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations, which only flag destructive/idempotent/openWorld. It discloses that only PNTR can write the name, that one value per subdomain replaces the previous value, that the record expires after 7 days or on subdomain delete/disable, and that GitHub sign-in is required.

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?

A single dense paragraph that front-loads the action, then the condition, the alternative to avoid, and the prerequisites/lifecycle. Every sentence carries distinct operational information; nothing is repeated from the schema or annotations.

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 two-parameter mutation with no output schema, it covers the trigger, the exclusion, prerequisites, value format, replacement semantics, expiry/cleanup behavior, and auth requirement. An agent has everything needed to call it correctly and knows why it might fail.

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 is 3; the description earns an extra point by adding a correctness constraint the schema does not state — the value must name that subdomain exactly, with the literal vc-domain-verify=<name>.pntr.dev,<code> shape and a one-value-per-subdomain cardinality rule.

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?

States a specific verb and resource: publish the Vercel ownership TXT value for one of your subdomains. It also names the exact DNS name it writes (_vercel.pntr.dev), which disambiguates it from the generic DNS siblings without needing to open the schema.

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?

Gives the precise triggering condition (Vercel reports the domain linked to another account and asks for a TXT at _vercel.pntr.dev) and an explicit negative instruction: do not use add_dns_record for this name. It also states the prerequisite that the subdomain must already point at Vercel.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered by structured data. The description adds no behavioral context of its own — no mention of rate limits, auth requirements, or what the check actually consults.

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?

A single front-loaded sentence with no filler; the purpose is stated immediately and nothing is redundant.

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 low-complexity, read-only, closed-world check with fully documented parameters and rich annotations, the description is nearly sufficient. It could be improved by noting how the availability result should be interpreted, but the agent has enough 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?

Schema description coverage is 100%, including the useful note that the name is given 'without the domain part', so the schema carries the parameter burden. The description restates only the resource and adds no syntax, format, or constraint detail beyond it.

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 gives a specific verb+resource ('Check if a subdomain name is available') and clearly differs in intent from sibling mutations like register_subdomain or delete_subdomain. It stops short of explicitly naming those siblings, so the differentiation is implied rather than stated.

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 guidance or named alternative; the only hint is the word 'available', which weakly implies a pre-registration check. Nothing tells the agent what to do with a positive or negative result, or that register_subdomain is the follow-up action.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of irreversibility, permission requirements, or downstream effects on the parent subdomain.

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?

A single efficient sentence with no filler, correctly front-loaded with the operation and resource. It is terse to the point of omitting useful context, which keeps it just shy of a 5.

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 two-parameter delete whose destructive and non-idempotent nature is fully captured by annotations, the description is minimally sufficient. Still, it omits any note on irreversibility or side effects, which would be valuable even with annotations present.

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 both parameters are documented in the schema itself. The description adds no semantic detail (e.g., format, sourcing) beyond what the schema provides, warranting the baseline 3.

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 verb (delete) and resource (DNS record) with scope qualifier (from a subdomain), so the agent knows exactly what is being operated on. It does not, however, distinguish itself from the sibling delete_subdomain, so it falls short of a 5.

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 alternatives (e.g., delete_subdomain), no prerequisites, and no caveats. The agent must infer usage entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no note on irreversibility, cascading effects on DNS records, or permissions required — so it contributes no behavioral context of its own.

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?

It is a single short sentence with zero padding, so it is not verbose. However, the brevity is a symptom of under-specification rather than efficiency — the sentence conveys no more than the title already does.

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 two-parameter destructive tool, the annotations cover the safety profile and the schema fully documents both parameters with no output schema needed. The description itself is minimal but the surrounding structured data leaves nothing critical missing for correct invocation.

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% and both parameters (id, confirm) are documented in the schema, including the "must be true" constraint. The description adds nothing to parameter meaning, so the baseline 3 applies.

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?

Tautological: description restates name/title.

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 when-to-use guidance, no mention of the confirm requirement as a precondition, and no routing to alternatives such as toggle_subdomain (likely the reversible disable) versus this irreversible delete. The agent must infer everything from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful constraint that results are limited to domains eligible for subdomain registration, but says nothing about result volume, ordering, or pagination.

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?

A single short sentence with the resource and scope front-loaded. Nothing is wasted and no filler is present.

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 zero-parameter read-only list with rich annotations, the definition is nearly sufficient. It would be slightly stronger if it indicated the shape or scope of the returned domain list, since no output schema exists.

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 tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond confirming the call is unfiltered, which it does implicitly with 'all available domains'.

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?

States a specific verb and resource ('List all available domains') and adds a scope qualifier ('for subdomain registration') that separates it from siblings like list_subdomains. However, it doesn't explicitly name an alternative, so differentiation is inferential rather than stated.

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 phrase 'for subdomain registration' implies this is the discovery step preceding register_subdomain, but there is no explicit when-to-use statement or named alternative such as list_subdomains. Usage is implied rather than directed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the email-enabled precondition, which annotations do not capture, but says nothing about result volume, pagination, or behavior on a subdomain with no email.

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?

A single short sentence that front-loads the action and scope, with the precondition in parentheses. There is no filler or redundancy.

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 annotated read with one required parameter this is close to sufficient, and the precondition is a real addition. It stops short of describing the returned listing (no output schema exists to compensate) or any limits on how many emails come back.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents subdomain_id. The description adds no format, ID-source, or selection guidance beyond restating the subdomain scope, so the baseline 3 applies.

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 gives a specific verb (list) and resource (received emails) scoped to a subdomain, which is clear and distinct from the sibling 'read_email' by the list-vs-single framing. It does not explicitly name that sibling, so differentiation is left to inference.

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?

It states a prerequisite ('requires email to be enabled') which is genuinely useful context for when the call will work. However, it never routes the agent among the plausible alternatives (read_email, wait_for_email) or explains what happens when email is disabled.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the capture prerequisite, which is real behavioral context, but says nothing about pagination, result limits, or what an empty list means.

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 compact sentence with the resource stated up front and the prerequisite parenthetically attached. No waste, though it is terse enough to omit useful routing detail.

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 one-parameter read tool with strong annotations and no output schema, the definition is minimally adequate. It omits any hint of result shape, pagination, or how it relates to read_request, which would help an agent choose 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% with a single required subdomain_id, so the schema carries the param documentation. The description adds only that the listing is scoped to a subdomain, which mirrors the schema rather than extending it, matching the baseline 3.

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?

Names a specific verb (List) and resource (captured HTTP requests) scoped to a subdomain, which is clear enough for an agent to act on. It does not explicitly differentiate itself from the sibling read_request, but the plural 'List' vs singular 'read_request' distinction is inferable.

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?

Provides one concrete prerequisite ('requires capture to be enabled'), which is genuine usage context. However, it gives no guidance on when to use this versus read_request for fetching a single request, leaving the selection to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds only the scope qualifier 'registered', and says nothing about pagination, sorting, or whether results span all 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?

A single short sentence with no filler, front-loading the verb and resource. It is efficient, though it borders on under-specification rather than pure conciseness.

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 no-parameter, read-only listing this is close to adequate, and annotations carry the safety context. But with no output schema, the description gives no hint about what a result looks like or whether the list is scoped to an account or domain, leaving a real gap.

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 tool takes zero parameters, so the baseline is 4. The schema and the description agree that no input is required, leaving nothing to mis-specify.

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?

States a specific verb (List) and resource (your registered subdomains), so the operation is unambiguous. It does not differentiate from the closely named sibling list_domains, which an agent must choose between.

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 versus list_domains or check_subdomain, nor any exclusions or preconditions. The agent is left to infer the correct choice from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds only that the full content including the body is returned, which is a modest extra detail over the annotations.

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?

A single tight sentence with no waste, front-loading the verb and resource. It is arguably too terse given the guidance gaps, but nothing is redundant.

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 low-complexity two-parameter read tool whose annotations carry the safety profile, the description is nearly sufficient. It hints at the return payload ('full content, including the body'), though it doesn't say whether headers or attachments are included.

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 both parameters are documented, and the schema's email_id description usefully points at list_emails as the source. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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?

Specific verb+resource: reading a received email's full content including the body. This implicitly distinguishes it from list_emails (which enumerates) and wait_for_email (which blocks for arrival), but it never names those siblings explicitly.

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 when-to-use or when-not-to-use guidance. The agent is left to infer that this is the follow-up to list_emails after obtaining an email_id, and nothing distinguishes it from wait_for_email or read_request.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint false, and openWorldHint false, so the safety profile is covered. The description adds value by disclosing the return content (headers, body, truncation state), which is not in the annotations and is useful without an output schema.

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?

A single front-loaded sentence that states the action and return contents with zero waste. It is appropriately sized for a simple read-by-ID 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?

Given the low complexity (2 required params, no nested objects) and the absence of an output schema, the description sufficiently explains what is returned. Annotations cover the safety profile, and no critical call-time information is missing.

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 both parameters (request_id, subdomain_id) are fully documented in the schema. The description adds no parameter-specific meaning beyond what the schema provides, so baseline 3 applies.

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?

States a specific verb (read) and resource (captured HTTP request's stored detail), and enumerates the detail returned (headers, body, truncation flag). This differentiates it from list_requests and wait_for_request without needing to open the schema.

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 usage (retrieve stored detail for a known request) but offers no explicit when-to-use, when-not-to-use, or alternative routing. It omits that request_id typically comes from list_requests and that wait_for_request exists for new requests.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=false, so the mutation and safety profile is covered. The description usefully adds that DNS configuration is a separate, later step, but says nothing about name uniqueness, reversibility, or permissions. Adequate but not rich beyond the annotations.

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?

A single front-loaded sentence with a parenthetical routing hint. No filler, no redundancy, and the primary action precedes the follow-up guidance.

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?

With no output schema, complete parameter docs, and annotations covering the safety profile, the description is nearly sufficient for correct invocation. Minor gaps remain around success behavior and naming constraints, which keep it from a 5.

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 all three parameters (name, domain_id, description) are already documented in the schema. The description adds no format, naming-rule, or scoping detail beyond what the schema provides; baseline 3 applies.

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?

States a specific verb and resource ('Register a new subdomain name'), which is immediately distinguishable from the sibling verbs delete_subdomain and toggle_subdomain. The parenthetical further clarifies the boundary with add_dns_record, so the agent knows this tool stops at registration.

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?

Explicitly names the follow-up tool and its condition ('use add_dns_record to configure DNS afterwards'), giving a clear sequencing rule. It does not state prerequisites (e.g. domain_id must already exist) or when-not-to-use, so it falls short of a full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is structured. The description adds genuine context with an expiry behavior not present in annotations (removed automatically after 7 days) and states what is being destroyed. However, it does not state what happens if no verification exists, which matters given idempotentHint=false, so it adds value without fully covering the mutations' edge 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?

Two sentences, both front-loaded with the action and the resource first, then the selection criterion. There is no redundant restatement of the title and 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 single-parameter, fully documented tool with rich annotations and no output schema, the description supplies everything needed to choose and invoke it. The one gap: nothing about the outcome when the verification is already absent, which is relevant because the tool is flagged non-idempotent.

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 single parameter is documented in the schema as 'Subdomain ID (from list_subdomains)'. The description only alludes to it as 'one of your subdomains' and adds no format, sourcing, or scoping detail beyond the schema, so the baseline of 3 applies.

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 verb ('Take down') and a specific resource ('the Vercel ownership value that add_vercel_verification published'), and links that resource explicitly to its counterpart sibling tool. An agent can distinguish it from add_vercel_verification and from delete_dns_record without opening any schema.

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?

It gives a clear conditional for use ('when the value is no longer needed or was added by mistake') and hints at a when-not condition via the 7-day auto-expiry, which tells the agent that waiting is an alternative to acting. What is missing is an explicit pointer back to add_vercel_verification as the inverse operation, so the routing guidance is strong but not complete.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds real context beyond the annotations: patch semantics ('Omitted fields keep their current value'), the restore-default path, and a rejection rule for browser-rendering content types. It doesn't spell out the destructive consequence explicitly, but dangerous behaviour (overwriting the live response) is implied and consistent with destructiveHint=true.

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?

Front-loads the core purpose and default behaviour, then layers in override, patch, restore, and rejection rules. Every sentence carries information, though the density is close to the upper limit of what stays scannable.

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 mutation tool with no output schema, the description covers default behaviour, patch semantics, reset, and validation constraints. It omits auth/permission requirements and the response of the call itself, which are minor gaps given the annotation coverage.

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 baseline would be 3, but the description adds semantics the schema lacks — omitted fields retain current values and certain content types are outright rejected. These constraints materially affect how the agent sets the 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?

States a specific verb+resource ('Set what a capture-enabled subdomain answers with') and immediately explains the default behaviour (JSON acknowledgement) that gets overridden. An agent can distinguish this from toggle_capture, which only enables/disables capture rather than defining the response.

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?

Gives a concrete use case ('returning 500 to trigger its retry logic') and states the reset semantics ('Send an empty body to restore the default acknowledgement'). It doesn't explicitly name sibling alternatives like toggle_capture, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare destructiveHint=true, meaning the tool can destroy data. The description adds important context: enabling terminates the hostname at pntr and logs every inbound request, and requires no existing DNS records. It doesn't explicitly state that disabling stops capture or that enabling may overwrite existing routing, but it goes beyond annotations.

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 sentences, front-loaded with the core action and followed by key behavioral detail and prerequisite. No waste, but not maximally efficient.

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 mutation tool with no output schema, the description covers the main action, effect, and prerequisite. However, it lacks details on what 'destructive' means in this context (e.g., what happens to existing capture settings or DNS records when toggling) and doesn't clarify whether disabling also removes logs. Adequate but with clear gaps.

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 schema fully documents both parameters. The description adds no parameter-specific syntax or format details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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?

States a specific verb (Enable or disable) and resource (HTTP request capture for a subdomain). It's clear what the tool does, though it doesn't explicitly distinguish itself from siblings like toggle_subdomain or toggle_wildcard—but those are different resources.

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 usage (the feature of capturing requests) and mentions list_requests/read_request for viewing logs, but does not give explicit when-to-use guidance versus alternatives or when-not-to-use. The prerequisite is stated but not framed as a usage condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is carried by structured data. The description adds nothing beyond that: it does not say what disabling does to already-received or queued mail, whether the change is reversible, or what permissions are required — the key questions for a destructive toggle. Note that the boolean setter semantics implied by the schema suggest idempotency, which sits awkwardly against idempotentHint=false, but this tension originates in the annotations rather than contradicting anything the description claims.

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?

A single eight-word sentence with the action and scope front-loaded and zero filler. Nothing is redundant or buried.

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 schema is complete and annotations cover the safety profile, so the mechanical inputs are fully specified. However, for a destructive state change with no output schema, the description leaves the agent without consequences (what disabling forfeits), prerequisite ordering, or result behavior — meaningful gaps for this tool type.

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% and both parameters ('enabled' as true/false for email, 'subdomain_id') are documented in the schema itself. The description adds no syntax, format, or edge-case detail beyond stating that email receiving is toggled, so the baseline 3 applies.

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?

States a specific verb pair (enable/disable) and the resource (email receiving for a subdomain), which is more precise than the title's 'email inbox'. It separates this from sibling toggles like toggle_subdomain and toggle_wildcard by naming the email-receiving scope, though it never explicitly names those 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 versus toggle_subdomain, toggle_capture, or toggle_wildcard, and no mention of prerequisites such as the subdomain needing to be registered first. The agent must infer all usage conditions from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, but the description adds genuinely non-obvious behavior: disabling removes DNS records while retaining config, enabling re-creates them, and only enabled subdomains count toward the per-tier limit. It does not cover error conditions (e.g., limit exceeded) or whether the DNS removal is immediate/propagated.

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?

Three sentences, no filler, front-loaded with the action and immediately followed by the consequential side effects and quota rule. Every sentence adds information an agent needs.

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 two-parameter mutation with no output schema, the description covers what changes and the quota implication. It stops short of stating failure modes (tier limit exceeded, unknown subdomain_id) and whether the call returns the updated state, which would fully close the loop.

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% with only two parameters, so the schema already documents both fields; the description adds no syntax or format detail beyond the boolean semantics the schema states. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

States a specific verb pair ('enable or disable') and resource ('a subdomain'), matching the title and clearly separable from siblings like register_subdomain, delete_subdomain, and check_subdomain. An agent can tell what state change this performs without opening the schema.

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 explains the effects of each direction but never states when to use this over register_subdomain/delete_subdomain or what prerequisites apply (e.g., subdomain must exist, tier limit reached). Usage is implied by the effects rather than explicitly routed against alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the write/destructive nature is covered. The description adds real value beyond them: the premium-plan entitlement requirement and the non-obvious behavior that the wildcard mirrors the first A/AAAA/CNAME record. It still omits what happens to the wildcard entry on disable.

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 compact sentences, front-loaded with the action and scoped by the example and the premium caveat. 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 two-parameter toggle with no output schema and annotations covering the safety profile, the description covers the essentials plus the premium gate and mirroring behavior. Minor gaps remain around failure on non-premium plans and the effect on existing records.

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% and both required parameters are documented in the schema, so the baseline is 3. The description's mention of the subdomain target adds only ambient context, no format or constraint detail 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?

States a specific verb (enable/disable) and resource (wildcard DNS for a subdomain), with the concrete example '*.myapp.pntr.dev' pinning down the concept. It is clearly distinguishable from siblings like toggle_subdomain, toggle_capture, and toggle_email.

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?

Usage is implied by the toggle framing and the 'Premium feature' note acts as a soft prerequisite, but there is no explicit guidance on when to use this versus adding a record directly with add_dns_record, nor any when-not condition.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely new behavior: a 25-second ceiling, first-match-only semantics, and that the email body is returned. It does not say what happens when the timeout expires with no match (error vs. empty), which is the one remaining behavioral 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?

Two tight sentences, front-loaded with the wait/matching scope before the use case. No filler and nothing repeated needlessly.

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?

With no output schema, the description steps in by describing the return value ('first matching email with its body'), and all six parameters are covered. Only the no-match/timeout outcome is left unspecified, a minor gap for a 6-param blocking tool.

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 documents each filter's matching mode, so the description mostly restates it (exact recipient, exact sender, substring, lower bound). It consolidates the matching semantics in one place but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 verb and resource ('Wait ... for an email'), specifies the matching scope (exact recipient, optional exact sender, subject substring, RFC3339 lower bound), and states the return ('first matching email with its body'). It implicitly separates itself from read_email/list_emails by being a blocking wait, but it never names a sibling to make the distinction explicit.

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?

It gives a clear when-to-use context ('deterministic OTP, magic-link, and signup tests'), which tells the agent the intended scenario. It stops short of naming alternatives or stating exclusions, so an agent must infer that read_email/list_emails are the non-blocking options.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description usefully adds the 25-second cap and the shape of the returned payload (headers, body, truncation flag), but it never says what happens when no request matches within the timeout, which is the single most important behavioral trait for a blocking tool.

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 dense sentences with zero filler; the wait duration and resource are front-loaded before the filter list and return shape. Every clause carries information.

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?

With no output schema, the description correctly carries the return-value burden (headers, body, truncation flag). It is nearly complete for an 8-parameter polling tool; the gap is the unstated timeout/no-match outcome.

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 is 3. The description goes beyond the schema by stating that header_name matching is case-insensitive (the schema only says 'Optional HTTP header name') and by framing since as an RFC3339 lower bound, though it omits timeout_seconds entirely.

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 verb (wait), resource (captured HTTP request), and blocking scope (up to 25 seconds), which cleanly separates it from read_request and list_requests. It does not, however, name any sibling explicitly, so the differentiation is inferential rather than stated.

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 blocking semantics imply the use case (poll for an inbound request rather than inspect already-stored ones), but there is no explicit statement of when to prefer this over read_request, list_requests, or wait_for_email. Usage is implied, not guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.