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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavioral context beyond that: result records expose an id that must be passed to fetch to obtain body text, and the query must be a Korean natural-language phrase. No contradiction with annotations; the search operation matches the read-only/idempotent hints.

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 key facts — scope, Korean query, id-to-fetch hand-off — are front-loaded in the first and last sentences. However, the middle is a dense parenthetical run-on enumerating every guide chapter and question-type topic; informative but heavy, and it resists quick scanning. The description earns its length through scope documentation yet would benefit from tighter structure (e.g., bullets or shorter clauses).

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 the tool searches a large, heterogeneous corpus with no output schema, the description is solid: it defines the discoverable content, the query language, and the result-id-to-fetch workflow that compensates for the absent return schema. Minor gaps remain — no statement about limit pagination behavior or empty-result handling — but for a read-only search tool whose safety is covered by annotations, the coverage is adequate. No output schema exists, so describing the id hand-off meaningfully fills that void.

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 100% — query carries an example, kind lists its enum values, and limit documents the default and bounds. The description reinforces the query-language expectation (Korean) and references the result id, but adds little parameter detail beyond the schema. Per the high-coverage baseline, a 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?

The description opens with a specific verb-resource pair — 'searches 내만집(nmjib.com)의 반셀프 인테리어 공개 문서' — and enumerates the exact scope (165 magazine articles, method guides, 18 guide chapters by topic). It also states the Korean natural-language query mode and routes results to the sibling fetch via id, disambiguating it from the document-type-specific sibling tools.

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 makes the general-purpose role of the tool clear by listing every document category it spans (magazines, method guides, 18 guide types), implicitly setting it apart from siblings like nmjib_process_guide or nmjib_checklist, which target single document kinds. It also specifies the input style (Korean natural language) and the hand-off to fetch for full text. It stops short of explicitly stating when NOT to use it or naming an alternative condition, so a point is held back.

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