assembly_search

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

With no annotations, the description carries the full burden and does substantial work: it discloses that the local index is limited to previously fetched content, that remote matching is morphological so terms may split-match, that auto defers remote until local is empty, and that verification requires opening url/offset. Auth, rate limits, and result-size behavior are not covered, so not 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?

The purpose is front-loaded in the first phrase, then two numbered mode blocks plus a default-behavior clause and a verification clause. Every sentence carries payload; density is high for a single paragraph but nothing is redundant with the schema.

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 12-parameter hybrid local/remote search with no annotations and no output schema, the description supplies the mode-selection logic, matching semantics, fallback behavior, and citation-verification procedure via hit.url/offset and next_offset. What remains (per-field filtering, pagination sizes) is covered by the rich 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 92%, so the baseline is 3, but the description adds real meaning beyond the schema for the query tokenization (spaces ignored, AND of all terms, quoted phrases) and especially for remote=auto (remote consulted only on zero local hits), which the schema only labels '기본 auto'. Parameters like speaker, committee, and sources get no prose treatment and rely entirely on schema descriptions.

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

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

States a specific verb+resource (통합 전문 검색) and explicitly enumerates what is searched: 이 MCP로 가져온 회의록 발언·자막·검토보고서·국감 보고서 본문 plus remote 국회도서관 회의록. The '이미 가져온 것만' scoping implicitly separates it from the fetch-oriented siblings, but no sibling is named, so an agent must infer the boundary with assembly_meeting_speeches or assembly_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?

Gives clear context for each mode: local for anything already fetched regardless of date, remote for meetings never fetched, and the default auto only falls back to remote when local returns 0 hits. It also tells the agent to open hit.url/offset to verify before citing. No explicit alternatives or 'do not use when' routing to sibling tools, which keeps it below a 5.

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