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

Annotations already mark the tool as read-only and closed-world, and the description adds substantial behavioral detail: validation requires all but at most the first 3 terms to agree with at least 6 known terms, 'ext=True' pulls DATA plus b-file terms, conjectural lines are excluded, and new terms are returned from n = offset + n_terms. It also warns that the relation is the entry's own claim, which is valuable context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the central question and packs useful detail, but it is a dense single paragraph with many parenthetical asides and nested clauses that make it harder to scan than necessary. Every sentence carries information, but the structure could be clearer.

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 complex, multi-step tool with no output schema, the description explains the core algorithm, validation rules, conjectural skipping, and partial return behavior. However, it leaves parameter semantics for 'anum' and 'max_new' unclear and does not fully specify the return structure beyond 'new terms from n = offset + n_terms on.'

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 for all three parameters. It explains the effect of 'ext' ('ext=True: DATA + b-file') but does not define 'anum' (presumably the OEIS A-number) or 'max_new' (presumably the maximum number of new terms to return), leaving two 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?

The description states a specific action: extending an OEIS entry from its own stated relations by parsing FORMULA lines and transform phrases, validating against known terms, and returning new terms. It distinguishes itself implicitly from retrieval siblings by focusing on extension rather than lookup, though it does not name alternatives.

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: call this tool when you want to extend a sequence using the entry's own claimed relations. The description notes that conjectural lines are skipped, but it does not explicitly state when to prefer this over siblings like guess_recurrence or identify_transform, nor does it describe any preconditions.

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 safety is covered. The description adds useful context beyond annotations: it specifies data comes from a local clone, requires git lfs, skips comments, and returns (n, a(n)) pairs. However, it does not describe error behavior if the b-file is missing or the output format in 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?

The description is two sentences, front-loading what the tool returns and then clarifying parameter behavior. It is efficient with no wasted words, though the second sentence could be slightly more precise about how start/count work.

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 read-only tool with 3 parameters and no output schema, the description covers the main data source, format, and comment skipping. However, it leaves gaps in parameter semantics (especially start/count and anum) and does not mention what happens when the b-file is not available, which are important for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It states 'start/count select lines' but does not clarify whether start is a line index or an n-value, nor does it explain the 'anum' parameter. The semantics are too vague for a tool with entirely undocumented 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 clearly identifies the resource (lines of the entry's b-file from the local oeisdata clone) and the data format (n, a(n) pairs). It does not explicitly differentiate from siblings like get_entry or get_raw_entry, but the focus on b-file lines is specific enough to distinguish it from generic entry retrieval.

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 mentions the condition 'when it was fetched with git lfs' but that is about data availability, not when to use this tool versus alternatives. There is no guidance on when to prefer get_bfile over get_entry or get_raw_entry, nor any exclusions or prerequisites for usage.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, and the description is consistent with a safe, snapshot-local read. It adds real behavioral detail beyond the annotations: which fields are returned by default, that terms and offset always come back, that ext swaps DATA for up to 256 b-file terms, and that max_chars truncates long text 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-loaded with the resource, then parameter-by-parameter notes with zero filler; the closing pointer to get_raw_entry is well placed. The compact multi-line style is scannable but reads more like terse spec notes than prose.

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 still conveys enough about the return shape (terms and offset always present, field selection controls the rest) for an agent to call and consume it correctly. It stops short of describing the overall response structure or whether truncation is signaled, which is the remaining gap for a five-parameter 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 full burden and does: it documents anum's accepted alternative formats ('108', 'a108'), the exact enum-like set of field names plus the default set and 'all', and the effect of ext, max_terms, and max_chars. Every one of the five parameters is given meaning the bare schema lacks.

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 resource (one OEIS entry) plus its source (the snapshot), and explicitly differentiates from get_raw_entry for internal-format records. It does not, however, distinguish itself from get_summaries or get_bfile, which an agent might reasonably confuse with 'one entry' retrieval.

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?

Names a concrete alternative and the condition selecting it ('for the exact internal-format record ... use get_raw_entry'), and implicitly routes to the 'ext' path when real b-file terms are wanted. No guidance is given on when to prefer get_summaries or get_bfile over this tool, so the alternative map is incomplete.

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 the safety profile is covered. The description adds useful behavior about exact stored format and extra %E lines, but it omits how max_chars affects truncation or output size.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is a single front-loaded sentence with no filler. The parenthetical format-token list is dense but directly supports the meaning of 'raw internal format' and 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?

The read-only annotations and output schema reduce what the description must cover, and it does a good job describing the returned format and sibling distinction. However, invocation is still under-specified because neither the schema nor the description explains anum format or max_chars truncation 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?

Schema description coverage is 0%, so the description should compensate, but it never explains anum or max_chars. The word 'entry' weakly implies anum, yet max_chars and its truncation semantics are completely unaddressed.

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 precisely states that this returns the entry record exactly as stored in oeisdata, including internal-format lines and %E extension lines. It also explicitly distinguishes the result from get_entry, so an agent can identify the tool 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 mention that this includes %E extension lines that get_entry does not carry gives clear context for when this tool is preferable to the sibling. It stops short of an explicit when-to-use/when-not-to-use statement and does not discuss max_chars.

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 safety is covered. The description adds one genuinely useful behavior — unknown A-numbers return an error — but does not say whether the whole call fails or only the offending items, nor whether there is a cap on how many entries can be requested at once.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence, front-loaded with the batch-summary purpose followed by the returned fields and the error behavior. Compact and nearly waste-free, with only mild awkwardness in 'the first n_terms terms'.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values needn't be restated, but for a 2-parameter tool with zero schema coverage the description leaves the key input (anums) undefined and omits batch-size limits and partial-failure semantics. The gap is too large for the available structured data to cover.

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 both parameters and it does not. It never explains what an 'A-number' is (the required anums array), whether ordering is preserved, or what the default of 12 means for n_terms.

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-shaped resource (summaries) and enumerates exactly what a summary contains: name, keywords, offset, term count, and first terms. It reads as a batch/lightweight counterpart to get_entry, though it does not name that sibling to sharpen the contrast.

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?

'many entries at once' implies a batch use case and the n_terms limit implies a lightweight preview, but there is no explicit when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer get_entry when full entries are needed, despite that being the closest sibling.

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 only declare readOnlyHint=true and openWorldHint=false, so the description carries the rest, and it does: it discloses the (r,d) search order by unknown count, the two-stage verification (mod a 61-bit prime, then exactly over Z), the `spare` over-determination requirement, and the caveat 'A guess, not a proof'. It even documents result fields (`spare_equations`, `integral`) that would otherwise be invisible since there is no output schema. Minor omissions are cost/runtime and failure behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in the first sentence before the procedural detail, and set notation is used economically. The paragraph is dense but each clause (input modes, search order, verification stages, result fields) carries distinct information, with little 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?

For a genuinely complex search tool with 8 parameters and no output schema, the description supplies the algorithm, the input modes, and the meaning of two return fields, which is most of what an agent needs. The remaining gaps — which parameter caps order/degree/prediction count and how it relates to sibling tools — keep it short of 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 coverage is 0% across 8 parameters, so the description must compensate. It explains `terms` (comma-separated, offset = n of first term), `anum`, `ext` (DATA + b-file terms), and `spare` (extra equations beyond unknowns) well, but `max_order`, `max_degree`, and `n_predict` are never named — only implicitly referenced via 'r', 'd', and 'predict further terms', leaving three of eight params ambiguous.

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 (guess) and a precisely characterized resource (a P-recursive/holonomic recurrence with deg p_i <= d) plus the secondary action of predicting further terms. It is clear enough to distinguish from generic term-search tools, though it never names a sibling such as identify_transform or extend_from_formulas, so sibling differentiation is left implicit.

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 rather than stated: it says to supply either `terms` with an offset or an `anum`, which tells the agent how to feed the tool but not when to prefer it over identify_transform or extend_from_formulas. There are no explicit when-not conditions or alternatives named, so the agent must infer placement.

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 only declare readOnlyHint/openWorldHint=false; the description adds substantial behavior on top: the depth-to-time curve, the time_budget cutoff producing complete=false, the minimum common-run thresholds per depth (6/8/10 terms), and the match_extends_query vs query_extends_match asymmetry. The closing caveat that hits are empirical identities to be proved is exactly the kind of context 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?

The core question and the input modes are front-loaded, and every later sentence conveys operational information (timing, hit criteria, hit interpretation). The long parenthetical catalogue of ~140 transforms is illustrative padding that could be shortened without losing much.

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 7-parameter, no-output-schema tool this covers a lot: what hits mean, how the two sides of a hit are labeled, and the timeout flag. It falls short only on the unexplained ext/limit parameters and their defaults, which an agent would need before tuning a search.

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 whole burden: it explains terms, offset ('the n of the first term'), anum, depth (1-3), and time_budget semantics well. However, 'ext' and 'limit' are never mentioned, and the defaults (depth 2, limit 15, offset 0) are undocumented in prose, so two of seven parameters remain opaque.

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 question form ('Is this sequence a simple transform of a known OEIS sequence?') plus a memorable analogy ('A local superseeker'), so the verb+resource is unambiguous. It is clearly distinct from siblings like search_terms, guess_recurrence, and extend_from_formulas: this one applies transforms and looks each result up in the term index.

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 explicitly states the two input modes ('Give either terms ... or an anum') and the cost/benefit tradeoff by depth (depth 1 ~1s, depth 2 ~20k lookups, tens of seconds). What's missing is an explicit statement of when to prefer this over search_terms or guess_recurrence, so it stops short of full alternative 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 safety is covered. The description adds useful scope information — that the response covers both the loaded snapshot identity and the indexed content — but says nothing about result shape, staleness, or cost.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence that front-loads the two pieces of information returned. No filler, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-argument, read-only introspection tool with no output schema, the description conveys enough for correct invocation: it is cheap, safe, and reveals snapshot/index state. It could be marginally stronger by indicating this is a diagnostic/no-argument call.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies since no parameter explanation is needed.

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 the tool reports which snapshot is loaded and what content is indexed, which is a specific, well-scoped purpose. It does not, however, contrast itself with sibling inspection tools such as get_summaries or get_entry, so an agent must infer 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?

Usage is only implied: an agent can infer this is a state/introspection call useful before searching or after a snapshot change, but the description never says when to call it or when to prefer a sibling. No exclusions or prerequisites 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real value by disclosing the index eligibility threshold and the shape of each hit (A-number, name, keywords, offset, `at`, `n`). It omits ordering of results for the default mode and any note on `limit`/pagination, so there are remaining behavioral 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?

Front-loaded with the purpose, then per-parameter notes in a compact block with no filler. The formatting is slightly cramped and the parenthetical about "tinier queries are too generic to index" is a touch verbose, but every line carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Because there is no output schema, describing the hit fields is essential and is done well. For a 5-parameter search tool the only meaningful omission is `limit` and result ordering; otherwise an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage the description must compensate, and it does for terms (comma-separated format with an example and minimum-length rule), ext (DATA plus b-files), sub (maximal common runs) and min_run. Only `limit` is left completely undefined, leaving one of five 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?

"Find sequences containing the given terms consecutively, like the OEIS search box" gives a specific verb and resource plus an intuitive analogy. It implicitly separates itself from text search (this matches terms, not text), but never names search_text or search_terms_batch as alternatives, so sibling differentiation is only partial.

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

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

It states a concrete eligibility rule (at least 4 consecutive terms with |term| >= 10) and explains the two modes with their appropriate situations, e.g. sub is "useful when the query has a wrong term or a different start." It does not say when to prefer search_text, search_terms_batch, or get_entry instead.

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 safety is covered; the description adds genuinely new behavioral detail: it returns per-query totals plus A-numbers with match positions, and generic queries fail with an error rather than returning empty hits. That failure mode is the kind of thing that would otherwise trip up an agent. It doesn't mention batching limits or cost, which keeps 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 with the core action front-loaded and the return/error behavior following in priority order. The inline `limit` reference is efficient rather than redundant. Minor waste in the parenthetical about sub=False, but it earns its place by anchoring semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description's return-value prose is bonus rather than necessity, and it covers the essential contract (counts, A-numbers, positions, error-on-generic). The gap is `ext`, an entirely unexplained parameter in a tool whose schema documents nothing; for a 3-parameter tool with 0% coverage that omission matters.

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 explains `queries` (comma-separated term strings) and references `limit` ('up to `limit` of their A-numbers'). However `ext` (boolean, default false) is never mentioned, and 'list of comma-separated term strings' is slightly ambiguous against the schema's array-of-strings type. Useful but partial compensation.

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 ('Run many exact term searches at once') and pins down its relationship to the sibling search_terms, including the sub=False variant it corresponds to. An agent can distinguish it from search_terms and search_text 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?

The 'many at once' framing plus the reference to search_terms gives clear context for when this batched form is the right pick. It stops short of an explicit exclusion (e.g. 'use search_terms for a single query' or a threshold on batch size), so it's clear but not fully prescriptive.

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

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

The description adds useful behavior beyond the readOnlyHint and openWorldHint annotations: it says matching is case-insensitive, distinguishes fast literal scans from regex, explains that hits are returned in A-number order, and describes what each hit contains. It does not discuss limits or pagination, but the annotations already cover the safety profile.

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 the core action and then systematically covers pattern, fields, and result shape. The examples are useful rather than wasteful, and there is no redundant restatement of the tool name.

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 search tool with annotations and no output schema, the description is largely complete: it explains matching semantics, fields, default field, result ordering, and snippet behavior. The main remaining gap is that limit and snippet_chars are not explained, though their defaults are visible in 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 description coverage is 0%, so the description must carry parameter meaning. It explains pattern and fields well, including allowed field names and the default, but it does not describe the limit or snippet_chars parameters, leaving two of four 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?

The description clearly states a specific verb and resource: find sequences whose text fields match a word, phrase, or regex, with case-insensitive behavior. It is more specific than the tool name alone, but it does not explicitly differentiate itself from sibling tools such as search_terms or search_terms_batch.

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 through the pattern and fields explanation, including examples of plain text and regex searches. However, it does not explicitly say when to use this tool versus search_terms or search_terms_batch, nor does it state exclusions or prerequisites.

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