ChronoKey

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

No annotations are provided, so the description carries the full burden. It discloses useful behavioral facts: the upstream sources (RDAP, Cloudflare DoH, Certificate Transparency) and cost/auth requirements (Pro subscription or $0.005 per call). However, it omits rate limits, failure behavior, and whether returns are cached or verbose, leaving real gaps for a priced aggregation call.

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 compact sentences with the core output front-loaded, then sources, then cost. No filler; every sentence carries distinct 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 and all parameters documented in the schema, the description covers purpose, data sources, and pricing adequately. Minor gap: it doesn't describe the shape of the aggregated response, but the essentials for invoking the tool are 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 description coverage is 100%, so the schema already documents all four parameters, their defaults, and the domain example. The description adds no parameter-level 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 and resource: one call returns WHOIS, DNS, and SSL certificate data for any domain. This is concrete and distinguishes the tool from the unrelated siblings (memory.*, extract.*, gas.price). It stops short of naming alternatives, but none are obviously needed.

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 when the tool is useful (aggregated domain intelligence in one call), but never states explicit when-to-use or when-not-to-use conditions, nor names an alternative. Pricing/subscription is mentioned, which hints at access conditions but is not usage 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses a concrete cost ($0.012 USD) and the network side effect of fetching only the first URL, but says nothing about failure behavior when the fetch fails, rate limits, or what happens to the extracted entities in the response.

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 short sentences that front-load the pipeline and append the cost. Every clause earns its place with no filler or repetition.

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?

There is no output schema and no annotations, so the description must cover the return contract. It says the fetched URL content is returned, but leaves ambiguous whether the extracted entities are also returned, how they are structured, or what happens on fetch failure.

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 there is a single parameter, so the schema already documents it fully. The description adds only that a URL will be pulled from the text, which the schema's description ('Text containing at least one URL') already conveys, 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 states a specific two-step pipeline — extract entities from text, then fetch the first URL found and return its content — so an agent knows exactly what the tool does. It does not explicitly distinguish itself from the sibling extract.and.summarize, which is the closest alternative, so it misses the top mark.

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 mechanics: use it when you need entity extraction plus the fetched content of the first embedded URL. There is no explicit when-not guidance and no mention of extract.and.summarize as the alternative for summarization, so the agent must infer the choice.

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?

No annotations exist, so the description carries the burden, and it does disclose a genuine behavioral trait: the fixed cost of $0.010 USD. Beyond that it says nothing about entity types extracted, how the summary is grouped, or failure/limit behavior (the 20k character cap is only in the 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?

Two short sentences, front-loaded with the operation and followed by the cost. Nothing is wasted 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?

With no output schema, the description should describe the return shape, and 'grouped summary' is vague about what the grouping key or entity structure is. For a single-parameter tool it is just adequate, not complete.

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?

There is a single parameter at 100% schema coverage, and the schema already documents the text field and its max length. 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?

States a specific two-stage operation (extract structured entities from text, then return a grouped summary), which is more informative than a restated name. However it does not distinguish itself from near-name siblings like extract.and.fetch, extract.confirm, extract.verified, or text.structure.

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 gives no indication of when to choose this tool over the many extract.* and text.structure siblings, nor any prerequisites or exclusions. The agent is left to infer usage 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?

With no annotations, the description carries the full burden and does disclose the key hidden trait: billing behavior, charging a $0.010 USD success bonus on accurate=true and nothing on accurate=false. It omits idempotency, token expiry, and whether the charge is reversible, which keeps it short of a 5.

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 purpose and then the two conditional outcomes. Every clause carries information; 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 simple 2-parameter tool with no output schema, the description covers the dependency and the cost side-effect, which is the main risk an agent could get wrong. It stops short of describing what the call returns, a minor gap given 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?

Schema description coverage is 100% and both parameters are documented in the schema, so the description need only avoid contradicting it. It adds no syntax, format, or constraint 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?

Specific verb ('Confirm') plus resource ('a previous extract.verified result') with an explicit dependency on the sibling tool extract.verified. An agent can distinguish this from extract.verified and the other extract.* siblings 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?

Clearly states the precondition (a prior extract.verified result) and branches on the accuracy outcome. It lacks an explicit 'do not call before verification' exclusion, but the dependency is unambiguous.

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?

With no annotations, the description carries the full behavioral burden and discloses two important traits: a $0.005 upfront charge and the return of a verification_token that must be passed to extract.confirm. It omits token expiry, failure/refund behavior, and what happens if confirmation never occurs, keeping it out of 5 territory.

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 short sentences, front-loaded with what the tool is and returns, followed by cost and the next step. Each sentence carries distinct information with 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?

With no annotations and no output schema, the description supplies the key facts an agent needs: the token return, the price, and the mandatory confirm step. It leaves some gaps around token lifetime and error behavior, but is complete enough to invoke 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?

Only one parameter exists and schema coverage is 100%, so the schema already documents the text input fully. The description adds nothing beyond the schema about the text argument, making the baseline 3 appropriate.

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?

"Verified extraction" plus the stated output ("standard entities plus a verification_token") tells the agent what it does and how it differs from the plain extraction siblings by implying a verification step. It does not explicitly distinguish itself from extract.and.fetch or extract.and.summarize, so it stops 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?

It specifies the required follow-up ("Call extract.confirm with the token to complete the verified flow") and the payment precondition, which is real usage context. However, it never states when to choose this over sibling extractors like extract.and.fetch or extract.and.summarize, so the guidance is implied rather than explicit.

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?

With no annotations, the description carries the full burden; it does disclose the cost model (Pro subscription or $0.003 USD per call), which is genuinely useful behavioral context an agent cannot get from schema. It omits rate limits, auth mechanics, and staleness/refresh semantics of 'real-time'.

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, zero filler, with the core capability front-loaded and the billing condition trailing. Every clause earns its place.

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 one-optional-param read tool this is close to sufficient, but with no output schema the description does not indicate what the returned gas price data looks like (per-chain base fee, priority fee, etc.), leaving the agent to guess at the response shape.

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 optional 'chains' parameter is fully documented with CAIP-2 format and default behavior. The description's chain enumeration corroborates the default set 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?

States a specific verb and resource (get real-time EIP-1559 gas prices) and enumerates the five covered chains, so the agent knows exactly what is returned and for where. No sibling tool covers gas pricing, so there is nothing to differentiate against, but the purpose itself is unambiguous.

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 never says when to reach for this tool versus alternatives, nor what preconditions exist beyond the paywall note. The pricing clause implies a gating condition but gives no guidance on selecting chains or when the default-all-five behavior is appropriate.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys a read-only status check and mentions 'free,' but it does not describe the response format, possible side effects, authentication needs, or error behavior. For a no-annotation tool, this leaves meaningful gaps.

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: 'Check server status (free).' It is front-loaded, contains no filler, and every part adds value. The parenthetical 'free' provides useful context without bloating the description.

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, simple health-check tool, the description is mostly complete: an agent knows what action to take and why. The absence of an output schema means the return value's exact shape is unspecified, but the core purpose is clear enough for an agent to invoke the tool and interpret the result reasonably.

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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none to explain. This is an appropriate non-issue for this tool.

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 and resource: 'Check server status.' This clearly distinguishes the tool from siblings like text.structure, timestamp, and uuid, which operate in completely different domains. The parenthetical 'free' adds a useful cost qualifier without obscuring the core purpose.

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 description: use this tool to check server status. However, there is no explicit guidance about when to prefer it over alternatives or when not to use it, although the sibling tools are unrelated in function. A minimal level of implied usage is present, but no direct selection criteria are provided.

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?

With no annotations, the description carries the full burden and does disclose non-obvious commercial context (Pro subscription or $0.005 per call), which an agent cannot get from the schema. However, it says nothing about behavior when the key is absent (error vs. null), whether the read is side-effect free, or any rate/latency characteristics.

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 short sentences, operation first, cost second. Every clause carries information and nothing is padded.

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 lookup with no output schema, the description omits what a caller receives on a miss and what the return value looks like. The pricing note is genuinely useful, but the miss-path behavior is the one gap an agent would want filled.

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%, though the schema's own descriptions for 'key' and 'namespace' are bare restatements. The description adds no format, case-sensitivity, or naming-convention detail beyond what the schema already declares, 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?

States a specific verb ('Retrieve') and resource ('a value by key') with the required scope ('from a namespace'), so the operation is unambiguous. It does not, however, distinguish itself from sibling memory.search, which an agent would reasonably confuse with a key-based lookup.

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 memory.search or memory.store. The only conditional statement is about billing, not about task selection, leaving the agent to infer that a key lookup differs from a query-based search.

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?

With no annotations, the description carries the full behavioral burden. It usefully discloses billing behavior ($0.010 USD, not covered by Pro subscription), which is non-obvious and valuable, but says nothing about return format, ranking semantics at the result level, or rate/permission constraints.

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 short sentences, front-loaded with what the tool does and followed by the one non-obvious operational fact (cost). 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 3-parameter read tool with no output schema, the description is adequate on mechanics and pricing but omits what results look like (ranked? scored?) and, critically, how it differs from memory.recall. The cost disclosure partially compensates, keeping it at minimum viable.

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 limit defaults, query bounds, and namespace all documented in the schema. The description adds no parameter-level meaning beyond BM25/ranking context, 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?

States a specific verb (full-text search) and resource (a namespace), plus the underlying mechanism (FTS5 with BM25 ranking), so the agent knows exactly what operation it performs. It does not, however, distinguish itself from the sibling memory.recall, 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?

The description contains no when-to-use guidance and never names or contrasts itself with memory.recall, the obvious alternative semantic-search sibling. The only context given is cost, which is a constraint rather than a usage rule.

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?

No annotations are provided, so the description carries the full behavioral burden. It does add genuinely useful non-schema context — the Pro subscription coverage and $0.005 per-call pricing — but omits overwrite semantics, authentication requirements, rate limits, and TTL expiry behavior, which are the traits that matter most for a write operation.

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 short sentences, zero filler, with the core action front-loaded and the cost note kept as a compact second sentence.

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 five-parameter write tool with no annotations and no output schema, the description covers the action and the cost but leaves the agent without overwrite/upsert semantics or confirmation of what is returned. It is minimally adequate rather than complete.

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 five parameters are self-documenting, making 3 the baseline. The description's mention of 'namespaced key' and 'optional TTL' restates what the schema already says and adds no format or default details (e.g., tags behavior or TTL default).

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 (Store) and resource (a value under a namespaced key) plus the optional TTL modifier. It is separable from siblings memory.recall and memory.search by the verb alone, but it never names those alternatives to sharpen the distinction.

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 condition for choosing store over recall/search, no note on whether it upserts or how it interacts with existing keys. Usage is only implied by the verb.

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?

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavioral facts — exact price ($5.00 USD) and term (30 days) — which is more than most mutation descriptions offer. However, it omits critical traits for a payment operation: whether it auto-renews, whether it is idempotent or errors if already subscribed, and how payment/authorization is handled.

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 with no filler; the price and duration are front-loaded before the entitlement list. Every clause earns its place by telling the agent the cost, the term, and what capabilities unlock.

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 purchase tool with no output schema and no annotations, the description covers the essentials: price, term, and the entitled tools, including the useful 'text.structure (standard mode)' vs the text.structure.deep sibling distinction. It falls short only on recurrence/renewal behavior and interaction with subscription.status.

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 there is nothing for the description to disambiguate; the schema is empty and self-consistent. Baseline of 4 applies for a correctly parameterless tool.

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 ('Subscribe') plus named resource ('ChronoKey Pro'), with price and duration attached so the agent knows exactly what transaction it is initiating. It also enumerates the entitlements granted, which distinguishes it from sibling status/introspection tools like subscription.status.

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 when to use it (when the agent or user needs access to the listed premium tools), but never states preconditions, alternatives, or what to do if already subscribed. With a sibling subscription.status present, an explicit 'check status first / do not re-subscribe' note would have been valuable and is missing.

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?

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It implies a read-only check but says nothing about authentication requirements, what happens if no subscription exists, rate limits, or the nature of the returned status.

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 precisely states the tool's purpose. Every word earns its place and no unnecessary detail is included.

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 is adequate for a simple read-only tool, but with no output schema, no annotations, and no parameters, it should ideally clarify the return value or behavior when the subscription is absent. These gaps are minor given the tool's low complexity.

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 there is no parameter information needed. Per the rubric, zero parameters yields a baseline of 4 when the schema coverage is complete, which it is (100%).

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 ('Check') and resource ('status of the Pro subscription'), and scopes it to the current MCP session. This distinguishes it from the sibling 'subscribe' tool, which would initiate a subscription rather than read its status.

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?

Implies usage context (checking status of the current session's Pro subscription), but does not explicitly state when to use it versus alternatives like 'subscribe' or what conditions trigger the call. No exclusions or prerequisites are mentioned.

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?

With no annotations, the description carries the full burden and does disclose meaningful behavior beyond the schema: per-call cost for each mode, subscription coverage for standard, and the extra entity classes deep produces (currencies, organizations, person names, embedded JSON). It does not mention latency, failure behavior past the 20k limit, or whether results are persisted.

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 dense sentences, front-loaded with the core action, then mode economics, then the optional flag. Every sentence informs a calling decision, though the pricing detail is slightly verbose relative to the extraction 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?

For a 3-parameter tool with no output schema and no annotations, the description covers cost, mode differences, and the optional flag well. The main gap is that it never enumerates what the default standard mode extracts, leaving the baseline output shape only partially characterized.

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 real meaning the schema lacks: it quantifies what each mode returns and what the cost tradeoff is, and clarifies include_referrals as an append operation. That goes beyond the schema's bare 'Tier' and 'Append complementary service suggestions'.

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 ('Extract structured entities from unstructured text') and immediately differentiates the two modes, which is exactly what distinguishes it from the sibling text.structure.deep. An agent can tell what it does and which tier it is choosing 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 gives mode-selection context (cost, and what deep adds) and explains include_referrals, which is implied guidance for parameter choice. However, it never says when to prefer this tool over alternatives such as extract.and.summarize, extract.verified, or text.structure.deep as a separate tool; usage must be inferred from the mode pricing.

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?

With no annotations, the description carries the full behavioral burden. It helpfully discloses exact cost ($0.020 USD) and that the tool is not covered by Pro subscription, but says nothing about output, processing behavior, or error conditions.

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 short sentences, each carrying distinct information: what the tool is, its cost, and its subscription status. It is front-loaded and has 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 low-complexity alias tool with one fully documented parameter, the description provides the key operational facts: it routes to text.structure deep mode, its price, and its subscription exclusion. It is nearly complete, though it still relies on the sibling tool's definition to explain the underlying behavior.

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 fully documents the single 'text' parameter, including minLength, maxLength, and purpose. The description adds no parameter-specific meaning beyond that, so the baseline score of 3 applies when schema coverage is complete.

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 that this tool is a convenience alias for text.structure with mode='deep', which distinguishes it from its sibling text.structure. However, it does not independently explain what deep structure extraction actually does, so full clarity depends on knowing the sibling tool.

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 when to use it: as a convenience wrapper for deep mode. It also discloses cost and Pro-subscription exclusion, which is useful. But it gives no explicit when-not guidance or comparison to using text.structure directly with mode='deep'.

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?

With no annotations, the description carries the full behavioral burden. It does disclose a genuinely useful trait not available in structured fields: a rate limit (10 free calls/day/session) and cost ($0.001/call or Pro coverage). However, it says nothing about safety profile, idempotency, or what "multiple formats" concretely returns, leaving real transparency gaps.

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 short sentences with the purpose front-loaded and pricing appended. Every sentence earns its place, though the billing sentence is adjacent to, rather than part of, the functional description.

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 one-optional-parameter, no-output-schema utility, the description is close to sufficient, but "multiple formats" is never unpacked and the return shape is unspecified. Given the tool's simplicity the gaps are minor but real.

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 timezone parameter is fully documented in the schema (IANA name, UTC default). The description adds no parameter-level information at all. 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?

The description gives a specific verb+resource ("Get the current time") and an immediate scope hint ("in multiple formats"). It does not differentiate from siblings, but none of the listed siblings (uuid, gas.price, health) overlap with time retrieval, so the lack of differentiation carries little cost. The phrase "multiple formats" is left unexplained, which keeps it from 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 any alternative, nor on the conditions that matter (e.g., which timezone to pass, or when formats are relevant). The only conditional content is billing, not usage. Adequate context is absent.

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?

With no annotations provided, the description carries the full disclosure burden, and it does disclose a meaningful behavioral trait: the free tier (first 10 calls/day/session) and the Pro-per-call pricing. That is exactly the kind of cost/rate-limit context an agent needs. It does not, however, mention determinism, collision behavior, or return format, so it is only partially complete.

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 short sentences, zero padding, and the functional purpose is front-loaded ahead of the billing detail. Every sentence earns its place.

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 zero-required-parameter generator with no output schema and full schema coverage, the description covers what an agent needs to decide whether to invoke it — including the cost implication of calling it repeatedly. Only minor gaps remain (output format is not described, though that is largely schema-implied).

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 `count` and `version` are already documented with defaults, ranges, and an enum. The description adds nothing beyond implying that more than one UUID can be requested; 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?

The description opens with a specific verb and resource: 'Generate one or more UUIDs.' It is unambiguous and, since no sibling tool produces UUIDs, sibling differentiation is not needed. It stops short of 5 only because it gives no detail on the kind of UUID produced beyond what the schema's version enum already conveys.

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 call this tool versus alternatives (e.g., `timestamp` or an ID generated elsewhere), nor any prerequisites or exclusions. The only context offered is the pricing/quota model, which is useful but is not usage guidance in the when/when-not sense.

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