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 usefully discloses that wait=true polls until completion or waitSeconds, but it omits other behavioral details such as cache behavior, token cost of raw output, and 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?

A single compact sentence with the core operation front-loaded and no wasted wording. It efficiently conveys the id lookup and the optional polling behavior.

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 tool with no output schema and no annotations, the description is somewhat thin. It covers the core get-by-id and wait behavior, but it does not describe what the run result contains or how status/result data is returned.

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 50%, and the description compensates by explaining the important wait and waitSeconds semantics. The remaining parameters are either self-explanatory or documented in the schema, though the description does not add meaning for raw, noCache, or maxChars.

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 an Exa Agent run by id. It is clearly a retrieval tool, but it does not explicitly distinguish itself from siblings like exa_agent_run or exa_agent_manage.

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 by saying to get a run by id and explains the wait=true polling behavior. It does not state when to use this versus exa_agent_run or exa_agent_manage, nor does it give exclusions.

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 at all, the description carries the full behavioral burden and delivers almost none of it: it never says that delete is permanent or cancel is irreversible, whether either is idempotent, what permissions or key scope is needed, or what happens to a run's events after deletion. 'Remove a run' is the only hint of destructiveness, and it is euphemistic rather than explicit.

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 sentence, no filler, each clause maps to exactly one action — structurally clean and easy to scan. The terseness borders on under-specification rather than verbosity, so the compactness is only mildly a virtue.

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?

A four-mode tool with two destructive operations, no annotations, no output schema, and 25% schema coverage needs far more than one line. Nothing is said about return shapes, pagination, error conditions, or irreversibility, leaving significant gaps for anything beyond the happy path.

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 only 25% — the id parameter is documented in the schema, but limit and cursor have bare types with no description in either place. The description does not compensate: it says list returns 'recent runs on every key' but never explains what limit does, how cursor pagination works, or whether cursor/limit are ignored by events/cancel/delete.

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?

Uses a compact glossary form to bind each of the four enum actions to a specific behavior ('cancel = stop a running run', 'delete = remove a run'), so the agent can tell what each branch of the tool does. It does not differentiate the tool from close siblings like exa_agent_get or exa_agent_run, which likely overlap on retrieving a single run.

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 action glossary implies which action does what, but there is no explicit when-to-use guidance, no statement of which action to prefer over exa_agent_get/exa_agent_run, and no preconditions (e.g. that events/cancel/delete require an id, or that list is account-wide). The agent must infer selection rules from a single line.

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 burden and does well: it discloses async behavior, the default waitSeconds wait of 120, that a still-running call returns a run id for exa_agent_get, cost tiers per mode/effort, and a usage-based cap of $1/run. It does not cover auth/permissions or rate-limit behavior, so it is strong but not exhaustive.

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 front-loaded with purpose and exclusions, then packs cost and wait behavior into two dense but purposeful sentences. Every clause adds decision-relevant information for an agent; there is 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?

Given a 14-parameter, no-annotation, no-output-schema tool, the description covers the essential operational picture: async execution, waiting, fallback run id, cost model, and sibling alternatives. It leaves detailed parameter semantics and output schema usage to the well-documented input schema, so it is complete enough for correct invocation, though a bit more on structured output behavior could help.

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 93%, so the baseline is 3, but the description adds real meaning beyond the schema by mapping mode and effort to cost/quality tiers ('fast = minimal ($0.012) · auto = low ($0.025) · max = ultra ... capped at $1/run') and by stating the waitSeconds default and run-id fallback. Minor parameters like inputData and outputSchema are left to the schema, which is acceptable given coverage.

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 — async multi-step Exa Agent run for deep research — and enumerates concrete use cases like list-building, row enrichment, multi-hop research, and structured JSON with citations. It explicitly distinguishes itself from exa_search and exa_answer, so an agent can route correctly without inspecting schemas.

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 explicit when-to-use guidance via the deep research use cases and an explicit when-not-to-use clause: 'Not for simple lookups (use exa_search or exa_answer).' It also explains the wait/fallback path to exa_agent_get, covering alternatives and follow-up behavior.

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 it does disclose two genuinely useful traits: the answer is model-synthesized with citations, and each call costs $0.005. However, it says nothing about the local cache that the noCache parameter implies, about latency/rate limits, or about how maxChars truncation affects the returned answer.

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, zero waste, with the core behavior and the routing alternative both front-loaded. The parenthetical price is the only aside and it 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 an 8-param tool with a nested outputSchema object and no annotations, the description covers what the tool does and when to pick it, which is the main risk of misselection. It is thin on the behavioral envelope — caching, output size, and the customization parameters — but not inadequate for correct invocation of the required query.

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?

Eight parameters at 63% schema description coverage, and the description mentions none of them. systemPrompt and userLocation are undocumented in both schema and description, and the cost/size tradeoffs of raw, text, and maxChars — the most decision-relevant knobs here — are left entirely to 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 and resource chain ('Ask a question; Exa searches and writes a short cited answer itself') and distinguishes the result shape from raw-source retrieval by naming exa_search. An agent knows immediately this returns a synthesized, cited answer rather than documents.

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 gives the selection rule: 'Good for quick facts' here, and 'For research where you read the sources yourself, use exa_search' as the alternative with the condition that selects it. Cost is also disclosed, which is decision-relevant for an agent choosing between tools.

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 zero annotations the description carries the full burden and does well: it discloses partial-failure semantics ("Failed URLs are listed; the call fails only when every URL failed"), a paid-plan restriction on Snapshot, and the default output mode. It omits auth/rate-limit behavior and per-URL cost expectations beyond the Snapshot note, 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?

Four tight clauses, zero filler, front-loaded with the core purpose before capabilities and failure behavior. Every sentence carries distinct information an agent would otherwise have to infer.

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 16-parameter tool with no annotations and no output schema, the description covers default behavior, failure semantics, plan gating, and capability modes. What it lacks is guidance on parameter interplay (e.g. content mode vs maxChars vs summaryQuery) and expected return shape, though the schema absorbs most of that.

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 94%, so the schema already explains nearly every parameter, including maxAgeHours semantics and Snapshot exclusivity. The description only restates the maxAgeHours=0 → live crawl mapping and the Snapshot paid-plan caveat, adding little beyond what the schema supplies; baseline 3 is correct.

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?

"Get clean content of known URLs (no search)" states a specific verb and resource and explicitly carves out the boundary against exa_search. An agent can tell instantly that this is a fetch-by-URL tool, not a discovery 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 "(no search)" qualifier and the list of capability modes (live crawl, subpage crawl, link/image extraction, snapshot) give clear context for when this tool applies. It stops short of naming siblings like exa_search or exa_find_similar as explicit alternatives, and leaves the choice among modes to the schema.

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 non-obvious side effect that the seed page is fetched/read before searching, plus the deprecated-endpoint lineage. It says nothing about cost, rate limits, permissions, or whether results are cached (cache behavior is only exposed as a parameter).

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 the core purpose and mechanism before the deprecation and mode notes. The '/findSimilar' deprecation reference is useful for migration context but is the least load-bearing 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?

A 10-parameter tool with no annotations and no output schema: the description covers what it does and the mode/type interaction, but says nothing about what the results look like, cost of the call, or how to get full page content (e.g. via exa_contents). Adequate but with clear gaps for an agent deciding whether to call it.

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 60%, so the schema covers the well-documented params (mode, focus, maxChars, noCache, excludeSourceDomain). The description's real contribution is the non-obvious interaction that search type follows the mode the way exa_search does — which explains the otherwise undocumented 'type' enum. It adds little for content, numResults, or raw.

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 and resource ('Find pages similar to a seed URL') and grounds it with concrete use cases (competitors, alternatives, related papers). It also explains the mechanism — read the seed page, run a semantic search from it — which distinguishes it from a plain query-based search like exa_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: the presence of a required seed URL tells the agent this is the tool for similarity-from-example, but the description never states when to prefer it over exa_search or exa_answer. The exa_search reference is about type-following behavior, not about tool selection.

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 usefully discloses key masking and that reset clears cooldowns and disables something, but it leaves important behavior ambiguous: what exactly is disabled, whether reset is destructive or reversible, and whether reset applies to all keys or only the aliased 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?

Two dense sentences with no filler. The key metrics and the reset side effect are front-loaded and easy to parse.

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 covers the status metrics and reset effect, but for a mutation-capable tool with no annotations and no output schema, it should more completely specify reset scope, side effects, and default behavior. It is adequate but has 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 only 50%, and the schema already documents alias while action lacks a schema description. The description adds meaning for action=reset, but does not clarify status behavior when action is omitted or how alias interacts with reset beyond what the schema says.

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 a specific verb and resource: show health, cooldowns, requests, and tracked spend for each Exa key. It also distinguishes the reset mode, and the tool is obviously separate from the search/agent 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?

The description implies status monitoring and describes what action=reset does, but it does not explicitly say when to use status versus reset, when reset is appropriate, or whether an alias is required when resetting a single key.

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 to lean on, the description carries the full burden and does so: it discloses the configuration is global ('applies to every agent and session on this machine'), quantifies latency and dollar cost per mode, and names the EXA_AGENT_MAX_COST cap (default $1/run) that bounds the max tier. That is exactly the blast-radius context an agent needs before mutating shared state.

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-loaded with the verb and resource, then the mode tiers, then the global-scope warning and the usage restriction. The cost/latency figures are dense but each is decision-relevant; the tier list reads as a single run-on block rather than scannable lines.

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-param, zero-required configuration tool with no output schema, everything needed to call it safely is present: what the modes buy, what the setting affects globally, and when not to touch it. Return shape for the show case is the only minor omission and is inferable from the schema.

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 is 3; the description exceeds it by unpacking each enum value into concrete latency, cost, and downstream effect (lite vs auto vs deep-reasoning search, agent effort minimal/low/ultra). The reset parameter is left entirely to the schema, which keeps this short of a 5.

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 pair of verbs and a precise resource: show or set the server-wide default quality mode applied when a call omits type/effort. None of the exa_* siblings touch server configuration, so an agent can place it immediately 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?

Explicit scoping on both sides: the mode only takes effect when a call sets no type/effort, and the description closes with the constraint 'Only set it when the user asks'. Omission-as-read is spelled out in the schema, so both the when and the when-not are covered.

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 full burden, and it does well: it discloses latency per mode (fast <1s, auto ~2s, max 7-20s) and the default of 10 results. It omits auth/plan constraints (e.g. snapshotAsOf is paid-only, noted only in the schema) and caching behavior beyond a pointer.

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 what the tool returns and then layers mode guidance and filter advice. Every sentence carries information, though the inline mode latency list partially duplicates the `mode` enum 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 30-parameter tool with no output schema, the description covers the highest-leverage decisions: mode/type selection, content mode, filter discipline, and structured extraction via outputSchema. Per-parameter details like numResults defaults, raw, subpages, and snapshot constraints are left to the schema, which documents them at 97% 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 97%, so baseline is 3; the description still adds value by explaining the mode-vs-type precedence ('Search type comes from the mode unless you set `type`') and by advising that filters be reserved for enforced constraints rather than soft preferences. It also explains the outputSchema/systemPrompt pairing for extracted fields.

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?

Opens with a specific verb+resource: 'Search the live web with Exa; returns ranked pages with query-relevant highlights (10 results)', which also states the default result shape. It does not explicitly contrast itself with siblings like exa_answer, exa_find_similar, or exa_contents, so differentiation relies on names rather than the description.

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 real steering: 'Put recency and source preferences in the query text; use filters only when they must be enforced' and points to exa_mode for the current server mode. It lacks an explicit statement of when to prefer exa_answer or exa_find_similar over this tool.

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