Agent Field Kit

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

Annotations already declare readOnlyHint and openWorldHint=false, so 'Read-only' is largely redundant but not contradictory. The description earns credit for behavior annotations cannot express: the operation is 'Free' (no quota/cost), it returns 'headlines plus next_since', and the caller is instructed to store the cursor for the next poll — a genuinely useful protocol detail.

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 tight sentences with the purpose, the date format, and the return/cursor contract front-loaded and no filler. The opening 'Free.' fragment is slightly gimmicky but does carry real signal about cost, so it earns its two words.

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 compensates by describing the return shape (headlines plus next_since) and the polling contract. The only real gap is the undocumented `limit` parameter and any note on what happens when nothing has changed since the given date.

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 0%, so the schema carries only types and a 30-char maxLength. The description rescues the required `since` by specifying accepted formats (YYYY-MM-DD or ISO UTC), but says nothing about `limit` (integer, 1-100), leaving one of two parameters undocumented in both places.

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?

It names a specific resource (Agent Field Kit's cyber-defense advisories) and a specific scope (what's new or updated since a date), and the cursor-based 'only fetch changes' framing separates it from bulk siblings like get_cyber_advisories and search_advisories without the caller opening a 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 states the usage context clearly ('pass it on your next scheduled poll so you only fetch changes'), which tells the agent this is the incremental-polling tool rather than the full-listing one. It never names an alternative sibling explicitly, so the agent must infer which tool to avoid, but the use case 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?

Annotations already declare readOnlyHint and openWorldHint=false, but the description adds real context beyond them: a Bearer API key is required, inputs are not stored, results are ordered 'free steps first', and kits are returned alongside advisories. Only the absence of any rate-limit or result-size note 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?

Purpose and return values come first, with constraints and auth notes trailing. Four short clauses with no filler, though the punctuation is dense and could be split more cleanly.

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 one parameter and no output schema, the description covers what goes in, the entry syntax, the auth requirement, and what comes back (advisories, free steps, kits). Missing only input limits, which are minor for a single-string-array 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 description coverage is 0%, so the description carries the burden, and it does: entries are frameworks, bots, platforms, or packages with optional versions, and package syntax is 'name==version' (PyPI style). It omits the schema's 50-item and 80-character limits, so not fully compensating.

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 concrete verb and resource: given components an agent runs on, return matching advisories and kits. It is distinguishable from sibling advisories tools because it takes a whole stack rather than a single product or query, though 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?

The phrase 'components an agent runs on' implies the use context, and 'PREMIUM (Bearer API key)' flags a prerequisite. However, it never states when to prefer this over search_advisories, get_advisory, or get_cyber_advisories, so the agent must infer the selection 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?

Goes well past the annotations by clarifying that nothing is charged at creation time, that payment happens on the hosted page, the refund policy, and a launch-gating error code ('checkout_not_open'). It is consistent with readOnlyHint=false, idempotentHint=false and destructiveHint=false, and adds facts an agent could not derive from structured fields.

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 action and the critical 'does NOT charge' clarification before the pricing block. The price and refund sentences are somewhat list-like but each carries decision-relevant information for a purchasing agent.

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 usefully discloses the return shape (URL or 'checkout_not_open') and the payment handoff, which is the key behavioral risk for this mutation tool. Only minor gaps remain, such as behavior on invalid or unlaunched product ids beyond the single error string.

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 67%, with email and agent_name already described in the schema; the description adds pricing context for a few product tiers but never maps prices to the 23-value product_id enum, so most enum members remain self-descriptive only. Baseline 3 is appropriate given the schema does most of the work.

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 ('Create a Stripe-hosted checkout for one Agent Field Kit product') and names the return value (its URL). It does not explicitly differentiate itself from the nearby request_kit or get_product siblings, so the agent must infer that this is the paid path versus a free kit request.

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 transactional language and the embedded gate ('a human, or an agent with explicit payment authority, must pay on the returned page'), which is genuinely useful guidance about who can complete the flow. However, there is no explicit when-to-use-this vs. request_kit/get_product routing or any stated preconditions beyond payment authority.

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 and openWorldHint=false, so 'Read-only' is redundant, but the description adds substantial non-annotation context: the Bearer-key auth requirement and exactly what free users receive (headline, first steps, sources) versus subscribers (patch status, fixed version, affected check, verification, matching kit). That gating behavior is not derivable from structured fields.

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 tight sentences, front-loaded with the core action and then the tiered content breakdown. The parenthetical feature list is dense but every item carries information; nothing is 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?

There is no output schema, so the description must explain what comes back, and it does so concretely for both free and subscriber tiers. The remaining gap is the id's origin/format, which an agent would need before it can call the tool successfully.

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 0% for the single required 'id' parameter, and the description adds no meaning beyond the word 'id' – it never says what an advisory id looks like, where to obtain one, or whether it must come from a search result. With low coverage the description is expected to compensate and does not.

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 one advisory by id'), and 'one ... by id' implicitly distinguishes it from the list/search siblings like search_advisories and get_cyber_advisories. It does not name an alternative explicitly, so sibling 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 description makes it clear you call this when you have a specific advisory id, and it discloses the free-vs-subscriber split, but it never says when to prefer this over search_advisories or get_cyber_advisories. Usage is implied rather than guided.

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 and openWorldHint, so safety is covered. The description earns credit by disclosing the tier-gating behavior (free = headlines from last 30 days; subscribers = full detail and history), which is a real result-shaping constraint not present in any structured field.

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 leads with purpose, then tiers, then read-only, then filters. Dense but every clause carries information; the parenthetical component examples are slightly bulky but justified given the 0% schema coverage.

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 read-only list tool with no output schema, the description covers purpose, filtering, tier-dependent return depth, and component syntax. The gap is 'limit' — no default, no hint that results are capped/paginated — so an agent cannot fully predict result volume.

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 0%, so the description must carry the load. It supplies the date format for 'since' (matching the pattern) and, more valuably, concrete component syntax including the qualified form 'package:pypi/litellm' that the bare maxLength:80 schema does not convey. It says nothing about 'limit', leaving one of three parameters undocumented.

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 ('Sourced cyber-defense advisories') and scopes it to AI agent stacks with concrete component categories. It is clear what the tool returns, though it never names sibling alternatives like search_advisories or get_advisory to sharpen the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains the two filter axes (date and/or component) and that free vs. subscriber tiers change the depth of what comes back, which implies when it is useful. However, there is no explicit when-to-use-this-vs-search_advisories/get_advisory guidance, leaving the agent to infer routing.

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 and openWorldHint=false, so 'Read-only' is largely redundant. However, 'PREMIUM (Bearer API key)' is a genuine behavioral disclosure not present in the structured fields — an agent needs to know this call is gated behind paid authentication and will fail without a Bearer key.

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 with the gating condition and payload front-loaded; nothing is padded. The only weak element is the redundant 'Read-only' clause, which merely echoes the 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?

With no output schema, the description does a reasonable job sketching what comes back (advisory dataset, stack index, kit versions), which is adequate for a read-only fetch. It falls short on the one input parameter and on whether the return is complete or incremental, leaving an agent guessing how to use 'since'.

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 0% and there is one parameter ('since') whose meaning, format, and optionality are documented nowhere. The description makes no reference to the time filter at all, so it fails to compensate for the coverage gap even though the regex does hint at a YYYY-MM-DD format.

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 the concrete payload ('Full advisory dataset plus stack index and kit versions') and the consumer ('Cyber Defense Dashboard kit to auto-update'), which is more specific than a restatement of the name. It implicitly distinguishes itself from siblings like get_advisory or get_cyber_advisories by advertising a complete, bulk dataset, but it never names those alternatives 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?

Usage is only inferable: this is the aggregated dataset for dashboard auto-update, and the PREMIUM/Bearer tag implies a gated tier. There is no explicit statement of when to pick this over get_cyber_advisories or changes_since, and no note on prerequisites beyond the implicit auth requirement.

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 cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds real context beyond them: a paid tier with Bearer API key auth, the exact checklist domains returned, and a verification level per item. It does not discuss rate limits or result size, but the auth requirement is exactly the kind of disclosure annotations cannot carry.

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 but well-ordered sentence block: access tier first, then scope, then contents, then the independent-guidance disclaimer. Almost every clause carries information; the vendor-affiliation disclaimer is marginally useful given PREMIUM framing.

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 listing the checklist areas plus 'config surfaces and a verification level', giving the agent a reasonable picture of the return shape. Missing only the sibling routing and any clarity about the stack enum values; annotations handle the read-only safety profile.

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 0%, so the description must carry the parameter meaning, and it only offers 'one agent stack' to explain the required 'stack' enum of 24 product values. That establishes cardinality and scope but not what qualifies as a valid stack or how enum values map to checklist content.

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 (hardening checklist for one agent stack) and enumerates the covered domains: key rotation, OAuth revocation, plugin review, approval gates, logging. It is clear what the tool returns, but it never distinguishes itself from the close sibling check_my_stack or get_advisory, so an agent must guess which one fits.

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?

'For one agent stack' implies a scope but gives no when-to-use condition and names no alternative. Siblings check_my_stack and get_advisory plausibly overlap, and nothing here tells the agent which to pick or when this tool is inappropriate. Only the PREMIUM/Bearer prerequisite hints at a calling precondition.

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 and openWorldHint=false, and the description's only behavioral statement, 'Read-only,' simply restates them. It adds no context beyond the annotations — no behavior for an unrecognized id, no note about whether results are cached or 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, front-loaded sentences with zero filler: the action and scope come first, and the safety qualifier follows. Nothing could be removed without losing 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?

For a one-parameter read-only lookup with annotations covering safety and no output schema, the essentials are present, but routing against search_products and any statement about invalid-id behavior are absent. It is adequate but leaves obvious gaps an agent would have to resolve by trial.

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 0% for the single 'id' parameter, so the description carries the burden but contributes only 'by id'. The schema's enum of 23 valid product slugs compensates by fully enumerating legal values, but the description adds no format or sourcing guidance (e.g., that ids are catalog slugs).

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 (Get), resource (Agent Field Kit product), and scope (one, by id), which implicitly separates it from the sibling search_products. It never names that sibling, but an agent can still tell this is a direct identifier lookup rather than a search.

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 only implied by the phrase 'by id' — the agent must infer that this is the tool for fetching a known product while search_products handles discovery. No explicit when-to-use, prerequisites, or error handling for an unknown id are given.

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 mark this as a non-destructive, non-read-only write. The description adds value beyond them: a rate limit ('Max 5 requests/hour') and a privacy/consent rule for the email field. It does not describe the response or what happens after a request is recorded, keeping it from 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?

Three tight sentences, front-loaded with the core action, then inputs, then the email caveat and rate limit. Every sentence earns its place with no padding.

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?

No output schema and all parameters optional, so the description is the main guidance. It covers the mutation's privacy, consent, and rate-limit constraints well, but leaves agent_name and notify semantics unexplained.

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 0%, so the description carries the burden. It explains topics, idea, tier, and the email/notify pairing, but omits agent_name and never clarifies the notify boolean directly. It covers most but not all six 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?

The description names a specific verb and resource: submitting a request for a new kit to Agent Field Kit. It is clear the tool captures demand for future kits, which distinguishes it from the sibling vote_agent_poll, though it does not explicitly name that sibling.

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 input guidance ('Pick topics and/or describe an idea; optional price tier') which implies when to use it. However, there is no explicit when-to-use versus alternatives guidance, and the relationship to vote_agent_poll (also a signal/feedback tool) is left for the agent to infer.

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 and openWorldHint=false, and the description's 'Read-only' merely repeats that. The tiering disclosure (free headlines vs subscriber full detail) does add real behavioral context about result depth, but throttling, pagination, and error behavior are unaddressed.

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 fragments, front-loaded with what the tool searches and immediately followed by example queries. Efficient, though the sentence fragments border on telegraphic.

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 convey return shape; it partially does by indicating headlines for free users and 'full detail and fix-it briefs' for subscribers. However, it omits result count/pagination behavior and the unused limit parameter, leaving gaps for a search 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 description coverage is 0%, so the description must carry parameter meaning. The example keywords ('litellm', 'mcp oauth', 'railway') clarify the query parameter's expected syntax reasonably well, but the limit parameter is never mentioned and no constraints are explained.

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?

Specifies a clear verb (keyword search) and resource (Agent Field Kit cyber-defense advisories), with representative query examples that anchor the domain. It is distinguishable from single-item siblings like get_advisory, though no sibling is named 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?

The free-vs-subscriber note implies when the tool suffices (headlines) versus when a fuller lookup is needed, but it never states explicit when-to-use or when-not-to-use conditions or names an alternative tool.

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 only behavioral claim, 'Read-only,' merely restates the readOnlyHint=true annotation, so it earns no credit. With annotations present the bar is lower, but the description still omits result count behavior, pagination/limit handling, and what happens when no query is supplied.

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, front-loaded sentences with the search scope stated first. It is efficient, though the trailing 'Read-only' sentence duplicates the annotation rather than adding 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, three undocumented parameters, and only a safety annotation, the description is too thin. It should at least explain the type filter values, the limit default, and the shape of returned results.

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 0%, so the description must compensate. It hints that 'keyword' maps to query and its enumeration of 'templates, bundles and licenses' mirrors the type enum, but the limit parameter (1-20) and query length constraint are never explained.

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 (Search) and resource (Agent Field Kit templates, bundles and licenses) plus the matching method (by keyword). It is distinguishable from siblings like get_product and search_advisories, though it never explicitly contrasts itself with them.

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, when-not-to-use, or alternative tooling is given. The agent must infer that this is for exploratory lookup versus get_product for fetching a known item; nothing in the description helps it choose.

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 establish a non-read-only, non-idempotent, non-destructive mutation. The description adds meaningful context beyond that: a rate limit ('Max 3 votes/day per network'), a return behavior ('Returns live results after voting'), and a data-quality caveat ('Self-selected, not a scientific sample'). Fewer details on failure modes, but this is solid added value.

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?

Purpose and question are front-loaded, followed by consent constraint, mechanics, result, and limit. Dense but every sentence carries information; no obvious padding.

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 the description covers the return behavior, rate limit, and consent constraint, which are the key things an agent needs. Only the undocumented 'other'/'agent_name' parameters leave a gap, which is minor against the otherwise rich disclosure.

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 0%, so the description must compensate. 'Multi-select' does explain the array nature of the required 'choices' parameter, but the 'other' free-text field and 'agent_name' parameter are never mentioned, leaving two of three params undocumented anywhere.

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 (Vote), the exact resource (Agent Field Kit's poll, quoted question), and its scope. No sibling tool covers polls, so there is no ambiguity; an agent immediately knows what this does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the conditions for use – 'on behalf of the person you act for, only with their consent and with their real answer' – which is explicit when-to-use guidance. It does not name alternatives, but none of the sibling tools are relevant substitutes.

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