원불교 교서

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral detail beyond annotations: without part it returns 편/품 list, with part it returns 절 list including ids. It stops short of describing exact output shape or error handling, but this is sufficient for a read-only outline tool.

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 three short sentences with no filler. It front-loads the resource, then efficiently gives conditional behavior and the intended use case. Every sentence 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?

For a simple two-parameter read-only tool with no output schema, the description covers the two invocation modes, the optional parameter, and the use case. A minor gap is that the no-part list is not explicitly said to include ids, but the overall purpose is clear enough for an agent to invoke the tool 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?

Schema coverage is 100%, so the baseline is 3; the schema already documents book IDs and part partial matching. The description adds the conditional semantics of the optional part parameter and notes the returned data includes ids, which helps the agent decide whether to pass part. This goes slightly beyond the schema without repeating it.

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 resource (책의 차례, a book's table of contents) and a clear action: retrieve structural navigation. It distinguishes two invocation modes (with or without part) and contrasts itself with lookup/search tools via the phrase '특정 자리를 알고 찾아갈 때 .'.

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 explicitly says the tool is for navigating to a specific known location ('특정 자리를 알고 찾아갈 때 다'), which implies it should be used when the agent already knows the structural place. It does not explicitly name sibling alternatives or state when not to use it, but the usage context is clear enough.

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 establish read-only/non-destructive behavior. The description adds the concrete output inventory (paragraph, footnotes, coords, adjacent verses, URL) and a normative citation rule, which is useful behavioral context beyond the 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?

Two short, information-dense sentences are front-loaded with the core result and followed by the citation rule. No filler or 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 simple two-parameter read tool with no output schema, the description covers the essential return contents, the id provenance via schema, and the intended citation use. It does not explain coordinates, but the enumeration is sufficient for selection and 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 100%: id and book are already well-described, including allowed book identifiers and the [book/id] format from search results. The description itself adds no parameter detail, so baseline 3 applies.

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 the resource (a single verse) and the returned content (full original text including main paragraphs, footnotes, coords, neighboring verses, URL), so an agent knows what the tool retrieves. It is clear but names no sibling tool, so differentiation from get_outline/get_related is implicit rather than explicit.

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 second sentence makes the use case explicit: any quotation/citation must be based on original text confirmed by this tool. This is strong when-to-use guidance, but there is no explicit when-not-to-use or 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 convey readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior beyond that: the types of connections considered (dictionary relation graph, shared footnote terms, human-approved resonance) and the key trait that results may have no character overlap with the query passage. This gives the agent a clear model of what the tool returns and why.

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 compact and front-loaded with the core purpose: '한 절에 이어진 관련 개념·관련 구절'. The parenthetical explanations are dense but each adds meaningful detail about relationship sources. It is slightly dense, but no sentence 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 read-only tool with no output schema, the description explains the kind of results returned, the relationship criteria, and why the tool adds value beyond search. It does not describe output format, ordering, or empty-result behavior, but the core context needed to select and call the tool is present.

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 input schema already covers both parameters fully: id is described as 절 id and book as 책 id with the list of valid values. The description does not add parameter-specific details, but with 100% schema coverage the baseline of 3 is appropriate.

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 and resource: it retrieves related concepts and passages linked to a given passage via dictionary relations, shared footnote words, and human-approved resonance. It also distinguishes itself from search tools by explicitly noting that retrieved passages may not share overlapping characters, so an agent can tell it apart from search_scripture.

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 concrete guidance on when this tool is valuable: when related passages cannot be found by keyword search because they share no overlapping characters. It implies use for semantic/curated relatedness rather than text search, though it does not explicitly name sibling alternatives or state when not to use the tool.

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 mark the tool as read-only and non-destructive. The description adds behavioral context by specifying the exact output contents (book list and section counts) and its role as the recommended first call, which is useful beyond the 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 a single, efficient sentence that front-loads the core purpose and follows with the usage scenario. Every word 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?

For a no-parameter, read-only list tool with no output schema, the description is complete: it states what is returned, how many items, and when to call it. No critical context is missing.

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 has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it correctly implies that no input is required to retrieve the complete list.

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: it lists the 15 Won-Buddhist scriptures along with their section counts. It also differentiates the tool from siblings by framing it as the initial discovery step when the user does not know which books exist.

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 clear usage context: call this first when you do not know which books are available. It does not explicitly name alternatives or state when not to use it, but the guidance is sufficient for this simple list tool.

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?

Beyond the read-only annotations, it disclosures a nontrivial truncation behavior: long entries return only the first section plus a section list, requiring a follow-up call with section. It also discloses the exact-one-hit shortcut and the id-overrides-q behavior, which are practical execution details an agent needs.

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 dense sentences with no filler: resource identity, q/id semantics, and long-entry handling are each covered in one focused sentence. The most important usage modes are front-loaded, and every sentence 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?

For a read-only lookup tool with all parameters documented and no output schema, this description covers the key operational edge cases: single-hit vs multi-hit behavior, direct id lookup, and the truncation/section workflow. Nothing essential for correct invocation is missing.

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 value by explaining the source of id (get_passage footnote markers), the exact-match behavior for q, and the two-step section workflow for long entries. This exceeds what the parameter descriptions alone 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: '원불교 대사전 4,523항목. q로 ... 찾는다' and 'id를 주면 그 항목'. It clearly identifies the tool as a dictionary lookup with multiple access modes, and the dictionary scope separates it from siblings like search_scripture or 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?

Gives clear invocation contexts: q for headword/hanja/definition search, id for direct lookup, and section for re-reading truncated long entries. The cross-reference to get_passage's [대사전 ****] footnote is a concrete routing cue. It doesn't explicitly list when-not-to-use alternatives, hence not a full 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 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.

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

Annotations already cover read-only/non-destructive behavior. The description adds meaningful behavioral detail beyond annotations, especially that a bare number is treated as a hymn number rather than a lyrics query, and that the corpus is limited to 201 hymns.

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?

Two short sentences, each earning its place: the first states the main search capability and scope, the second clarifies an important edge case. No redundant filler or repetition of schema details.

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 2-parameter search tool with full schema coverage and read-only annotations, the description is largely complete. It could be slightly stronger by explicitly naming the return behavior or sibling distinction, but nothing essential is missing 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 coverage is 100%, so the baseline is 3. The description adds genuine value by explicitly clarifying that a numeric-only q triggers song-number lookup rather than lyric search, removing ambiguity that the schema alone leaves open.

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?

Describes a specific action: searching 원불교 성가 201곡 by title, lyrics, or number. This clearly distinguishes it from sibling tools like search_scripture or lookup_dictionary by naming the exact resource and the special numeric behavior.

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 clear context for when to use the tool (when searching hymns by title, lyrics, or number) and explains the numeric-input special case. It does not explicitly name alternative tools or exclusions, but the resource scope makes the intended use apparent.

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