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

Annotations already declare readOnly, non-destructive, open-world and non-idempotent, so the safety profile is covered. The description adds useful context ('display cap, not a game rule', 'positions are preserved' for replace), but says nothing about service availability, failure modes, or result ordering for a tool that depends on a local browser service.

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 sentence is front-loaded and the Args block is compact, with each line contributing parameter meaning rather than restating the name. Sphinx-style formatting is slightly verbose but not wasteful.

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 an output schema present and annotations covering safety, the description need only explain intent and inputs, which it does for a tool with no required parameters. The remaining omission is how the team summaries are scoped or ranked, which matters for interpreting 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 carry the burden, and it does: all six parameters get meaning, including the defense/def_ids duality, region coding (1/2/0), the 1-6 limit as a display cap, and a concrete replace syntax example with position semantics. Only minor gaps remain, such as array-length rules or what 'six-digit ids' means numerically.

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 first sentence gives a specific verb and resource ('Look up defence teams for a lineup') and names the backing service ('local arena browser service'). It is clearly distinct from the character/portrait/memory siblings, though it does not explicitly say so.

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: the agent learns that def_ids is an alternative to defense 'if you already have them' and that region=0 disables filtering, but there is no explicit when-to-use/when-not guidance and no mention of the sibling tools as alternatives.

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

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

Annotations already declare readOnly, openWorld, non-destructive, and non-idempotent behavior. The description adds useful behavioral detail: free-form query tags/count/orientation are parsed, size controls preview versus full-size file, and negative tags are sent to the board as “-tag”.

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 its purpose and then uses a compact Args structure. Every line adds parameter meaning or behavioral context without repetition or wasted 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description is sufficient for invocation, though it could add minor context about the source/board or empty-result 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 carries the full burden. It documents all six parameters with meaningful semantics: query examples and parsing behavior, count range 1–10, size meanings, orientation values, extra canonical booru tags, and negative exclusion syntax.

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 (“illustration”) and notes support for Chinese or English free-form requests. It does not explicitly differentiate from sibling tools, though none of the listed siblings appear to be illustration-search 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?

The use case is implied through the Chinese/English request example and the parameter explanations. There is no explicit guidance on when not to use this tool or which sibling to use instead, so the guidance is adequate but not complete.

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

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

Annotations already declare the mutation profile (readOnly=false, destructive=false, idempotent=true), and the description adds real value beyond them: the term is persisted as an alias and the correction is timestamped in a log. It could go further on what happens if the term is already aliased to a different character, but the persistence and logging disclosure is substantive.

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 core behavior in one sentence, then the persistence detail, then a compact Args block. Slight redundancy between the opening sentence and the Args block for char_id, but nothing is wasted.

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

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

For a small mutation tool with an output schema and annotations, the description covers what changes, what is logged, and what each argument means. Remaining gaps (collision behavior when a term is already aliased) are minor and not required 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?

With 0% schema description coverage the description must carry the load, and it documents all three parameters: term is the raw user text with a concrete example, char_id accepts an id or any known name (matching the anyOf int/string union), and note is optional free text. That is meaningfully more than the bare schema titles provide.

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 ('teach the table that term refers to a character') and frames itself as 'the manual fix for a wrong match', which separates it from automatic matchers like character_match and from character_update. An agent can tell what this does 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 phrase 'the manual fix for a wrong match' gives clear context for when to reach for it, distinguishing it from the automatic matching path. It stops short of explicitly naming the alternative sibling (character_match) or stating when not to use it, so it misses the top band.

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 annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation. The description adds useful behavior by explaining that the lookup maps identifiers to an arena id and that the limit parameter controls how many candidates are returned.

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 short and front-loaded with the core mapping behavior. The Args section is tightly scoped to the two parameters and includes examples that earn their 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?

An output schema exists, so the description need not explain return structure, and the annotations already cover safety traits. The remaining gap is that it does not explain how ambiguous matches are handled or when another character-related sibling should be preferred.

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 does define both parameters: query accepts character names, nicknames, uids, or ids with concrete examples, and limit returns between 1 and 10 candidates.

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: mapping a character name, nickname, uid, or id to an arena id. It is clear what the tool does, but it does not explicitly distinguish itself from related siblings such as character_match or character_correct.

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 examples of accepted query values imply when the tool is useful, but there is no explicit guidance on when to use it versus character_match, character_correct, or arena_lookup. Usage is inferable but not directly stated.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so safety is covered. The description adds genuine behavior beyond that: it discloses that `matched_on` and `score` carry trust signal, that results are ranked, and that a threshold can yield an empty result set — enough for the agent to handle the no-match case. It does not discuss scoring methodology, tie-breaking, or how many candidates typically clear the default threshold, which a ranking tool would ideally address.

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 three-sentence preamble front-loads purpose then the failure condition then the decision guidance, and the Args block is scannable. Every sentence earns its place; only the trailing newline-separated docstring formatting is slightly verbose, but nothing is wasted.

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

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

An output schema exists, so return shape needn't be documented, and the description still usefully previews `score` and `matched_on` as interpretation aids. For a 3-parameter read-only ranking tool the coverage is nearly complete; only scoring semantics and defaults are absent.

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, and it largely does: it explains `query` accepts a name in any script with CJK, kana and romaji examples, gives `top_k` a 1-20 range that the schema omits, and defines `threshold` as a 0-1 minimum whose effect is that nothing below it is returned. It does not state the defaults (5 / 0.45) or how the score is scaled, leaving a small gap.

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 first sentence states a specific verb and resource: rank characters by name similarity to a query. It is clearly distinguishable from an exact lookup, and the second sentence reinforces the fuzzy-matching nature by framing it as the fallback when a name is not in the table. It never names `character_lookup` explicitly, so sibling routing relies on inference.

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

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

It gives a concrete triggering condition — a lookup failed because the name is absent — and a downstream action policy: use `score` and `matched_on` to decide whether to ask the user rather than guess. There is no explicit exclusion (e.g. 'do not use when you have an exact ID'), which keeps it a step below a 5.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), so the bar is lower, and the description still adds real value: it names the write target (local overlay file), guarantees the packaged table is untouched, and gives the cautionary rationale that a wrong alias is worse than a missing one. It omits what happens on an unknown char_id with no name, or whether an overlay file is created if absent.

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 line, followed by motivation and then an Args block, so the agent reads the important content first. The Args block is somewhat verbose relative to an already-titled schema, but each entry adds examples the schema lacks, so little is wasted.

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

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

An output schema exists, so return values need no explanation, and annotations cover read-only/idempotency. For a six-parameter mutation with a local overlay side effect, the description explains the write target and non-destructiveness of the packaged data; the remaining gap is failure behavior (unknown char_id, missing name) and valid server values.

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 it documents all six parameters with meaning plus examples (six-digit arena id, Chinese name, alias list, Japanese name, servers, removal list). The gap is `servers`: 'servers the character exists on' gives no valid set of values or enum hint, and it doesn't say whether `name` overwrites an existing entry.

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 first sentence states a specific verb and resource: add a character or extend its aliases in the local overlay file, and explicitly notes that the packaged table is never modified. It contrasts with the read-side siblings (character_lookup, character_match) implicitly through 'overlay file' mutation, but never names character_correct, which is the nearest ambiguous 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?

Usage context is implied by the Japan-first publishing note, which explains why an agent would pass `jp` immediately. However, there is no explicit when-to-use/when-not guidance and no routing to siblings such as character_lookup (read) or character_correct (fix an existing entry), leaving the agent to infer which of the two mutation-ish tools to call.

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 annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world behavior. The description adds useful context about local memory, result limits, and scope modes, though it repeats the read-only trait rather than adding new safety or auth details.

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 definition is compact and front-loaded, with the core purpose first and a well-structured Args block covering the three parameters. Every part contributes useful information given the empty schema descriptions.

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 tool is simple, annotations cover safety, and an output schema exists, so return values need not be described. The description covers all parameters adequately but leaves scope-mode semantics and when-to-use guidance slightly under-specified.

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 compensates well by explaining query as keywords or a sentence, limit as maximum hits from 1-20, and scope as 'all', 'session', or 'global'. It does not explain what each scope mode means, leaving a small semantic gap.

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: 'Search the assistant's local memory store.' It is clearly distinguishable from sibling memory_stats and other non-memory search tools, though it does not explicitly name or contrast any 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 implies the tool is used for searching local memory, but gives no explicit guidance on when to use it instead of alternatives such as memory_stats. There are no when-not conditions or alternative-tool 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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds only that the store is 'local' and that output is a count plus a size — useful framing but nothing beyond structured data. No mention of cost, latency, or whether counts span all tables.

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

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

A single sentence with no filler, front-loading both the action and the specific metrics returned. Nothing could be trimmed 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?

With an output schema present and no parameters, the description needn't explain return values or argument formats, and the annotations cover safety. It is essentially complete; only scope (which tables/counters are tallied) is left unstated.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; noting that the reported metrics are counts and size is a small bonus.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb 'Report' with a concrete object: row counts and database size of the local memory store. This is clearly distinguishable from memory_search (querying content) and service_health (service status) 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?

Usage is only implied: an agent can infer this is the diagnostic/size-check tool, but the description never states when to reach for it instead of memory_search or service_health, nor any preconditions. Adequate for an obvious zero-arg stats call, but no explicit routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds real value beyond that by defining what min_score means behaviorally — 'similarity floor below which the portrait counts as unknown' — telling the agent how low-confidence results are reported, and by enumerating accepted input encodings.

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 front-loaded sentence states the purpose, then a compact Args block gives exactly the per-parameter detail the schema lacks. No repetition of schema types, no filler, nothing an agent must scan past.

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 three-parameter read-only tool with an output schema (so return values need no explanation), the description covers inputs and the unknown-result rule adequately. It stops short of explaining how multiple images are batched in the response or the ordering/size of the candidate list, which would fully close the loop.

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

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

Schema coverage is 0%, so the description must carry the burden and it does: images accepts a file path, base64 raw bytes, or a data URI; top_k is candidates per portrait bounded 1-10; min_score is a 0-1 similarity floor. Every parameter gains syntax or range meaning beyond the bare schema types.

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 — identifying which characters appear in cropped portrait images — which is concrete enough to act on. It does not distinguish itself from the sibling tools character_match or character_lookup, which an agent might plausibly confuse with identification, so it falls short of a 5.

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

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

The phrase 'cropped portrait images' implicitly scopes the input (cropped portraits, not full art or free-form images), which is useful implied usage guidance. However there is no explicit when-to-use versus character_match/character_lookup, no prerequisites, and no stated 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds that it actively 'probes' services (a live check, not a cached read), which is real context beyond the annotations, but it says nothing about latency, timeouts, or what a failed probe looks like.

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, front-loaded with the action and the scope, with no filler or redundant restatement of the title. Nothing could be trimmed without losing meaning.

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 need not be described, and annotations cover the safety profile for a zero-parameter tool. What remains thin is which services constitute 'the stack' and whether probing has any cost, but for a simple diagnostic call the description is sufficient to invoke it correctly.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (probe) plus a specific resource (local services of the assistant stack) and the outcome (report their status). Sibling tools cover entirely different domains (art_search, memory_search, character_lookup), so no differentiation text is needed. The only softness is that 'the assistant stack' is not enumerated.

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 infers this is a diagnostics/status check to run when the stack may be unhealthy. There is no explicit 'use when', no exclusions, and no statement about when a different tool would be the right call.

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