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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: spacing is ignored ('상시일기' and '상시 일기' yield the same result), matching is partial substring based, and word-overlap/semantic search is not supported. It doesn't mention pagination or ordering details, but the description covers key behavioral traits that an agent needs beyond the static schema. A 4 is appropriate given the annotations carry the read-only burden and the description adds meaningful matching behavior disclosure.

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 4 sentences, all dense with useful information. It front-loads the core purpose, then gives matching rules ('띄어쓰기를 무시한 부분 문자열 일치'), a negation constraint ('뜻 검색은 안 된다'), and a concrete follow-up routing instruction for quotations. No filler or repetition of schema fields that don't add value. Very efficient.

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 4 parameters, full schema coverage, and no output schema, the description covers the main gaps: matching semantics, what it can't do, and the retrieval next step (get_passage). It doesn't cover potential edge cases like limit=0 or result sorting order, but those are minor for an agent's correct invocation. Given the sibling context and annotations, this is reasonably complete, though not exhaustive about output format or pagination.

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 the baseline is 3. The description adds semantic value by explaining the matching semantics for the q parameter (space-insensitive substring matching), which is not explicitly in the parameter description. It also clarifies that mode has a phrase(default) vs all option, which aligns with the schema enum, but the description's matching rule gives more operational meaning. It doesn't describe how limit behaves beyond max count, but the schema already says '최대 건수(기본 10)'. The added q semantics justify a 4.

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?

Description opens with a clear verb+resource statement: '경전 원문 전문 검색' (search full scripture text). It goes beyond just naming the tool by specifying the object (scripture original texts) and the action (search), and it differentiates from siblings by noting this is full-text search over scripture texts, unlike search_sungga which presumably searches different material. The distinction is supported by the sibling list where other tools handle navigation (get_outline), retrieval (get_passage), related content (get_related), book listing (list_books), dictionary (lookup_dictionary), and another search (search_sungga).

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 gives explicit usage conditions: it matches partial strings ignoring spacing, it cannot do semantic/concept search, so users must search with words that actually appear in the text. It also directs the agent to use get_passage with the result's id to verify the full original text when quoting. This clearly distinguishes when to use this tool versus alternatives, naming the alternative get_passage explicitly for the follow-up step.

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