내만집 (nmjib) — Korean semi-self interior renovation

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral details beyond those annotations: it returns the full markdown body and notes the source URL appears at the end. No contradiction with 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?

One efficient, front-loaded sentence carries all essential meaning. The examples are compact and directly aid correct usage without excessive detail.

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 single-parameter, read-only tool, the description is largely complete: it states input format, accepted id types, output content type, and the presence of a source URL. Only minor open areas remain such as explicit not-found behavior, which is not essential at this complexity level.

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 the single parameter completely. The description enriches it slightly with examples of accepted id formats (magazine/30pyeong-cost, guide/process-order) and URL acceptance, but the schema and description mostly overlap.

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 clearly states the action (fetch full document body in markdown) and the resource (docs identified by search id or nmjib.com URL). It is clear enough to be understood, but it does not explicitly differentiate itself from sibling tools beyond the generic 'full body' framing.

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 practical usage context: use IDs from search results or nmjib.com URLs. This tells an agent when to call the tool, though it does not explicitly name alternatives or state when not to use it.

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 and idempotentHint, so the read-only nature is covered. The description adds meaningful behavioral context: phase definitions, item counts, and the fact that the process parameter groups during-phase checks by process, plus the implicit return of a checklist rather than an action. It does not contradict 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 dense sentence plus an example-clause sentence. It is front-loaded with the tool name and scope, packs a lot of information into few words, and avoids filler, though a slight restructuring could make the phase rules even easier to scan.

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 this is a simple read-only checklist lookup with two parameters and no nested/output schema, the description is complete enough for an agent to know how and when to call it. The only minor gap is that it doesn't explicitly describe the shape of the returned checklist, but the contextual signal (no output schema) makes that less crucial.

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%, and the schema already explains phase and process parameters. The description adds extra semantic info such as the breakdown of 36/22/22 items per phase and the examples of process values (mok, lock, tile, wallpaper). This goes beyond the ordinary schema descriptions without being redundant.

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 clearly identifies the tool as a construction checklist for the inner door, breaking it down into three phases (pre, during, post) with concrete item counts, and gives example queries that map to user intents. This separates it from sibling tools like the process guide, cost reference, and FAQ search.

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 examples of when to use the tool: 'What should I prepare before construction', 'What to check when working', and 'inspection before move-in'. It clearly covers common use cases, though it does not explicitly name sibling tools to exclude, so it lacks a full 'when not to use' statement.

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 description discloses important side effects beyond what annotations carry: it sends a 6-digit SMS to the user, returns a request number, and only saves data without any read-back path. It also explains the consent handling and office chain. These details are critical for an agent to know before invoking the tool and are not captured in 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 dense and contains no redundant words: each sentence adds a distinct piece of purpose, side effect, flow, or exclusion. It is a single paragraph, so scanning could be easier with slight formatting, but the content justify the length.

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 write-only tool with a 2-step verification process, this is complete: the description covers the purpose, the exact conditions, the SMS side effect, the completion step, and the alternative tools. Nothing needed for an agent to call it correctly is missing, even with no output schema 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 covers 100% of the parameters, so the baseline is a bit higher with valuable additions: the description tells the agent the exact fields (name, phone, region, pyeong, scope) to ask for and the consent condition, and it links the phone parameter to the SMS verification flow. This is below 5 only because the schema already carries the detailed field semantics, especially for consent and phone.

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 explicitly states a specific verb and resource: the tool '접수(registers)' a homeowner's consultation/estimate inquiry, and it distinguishes itself from related tools by explicitly saying it is not a cost-calculation tool and that its completion requires 'nmjib_verify_code'. This leaves no ambiguity about what the tool does and what it does not do.

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 provides clear selection criteria: call this tool only when the user explicitly asks for a consultation, use 'nmjib_cost_reference' for cost questions, use the app for exact prices, and complete the flow via 'nmjib_verify_code' after receiving the 6-digit SMS. This is explicit, condition with alternatives and no ambiguity.

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 readOnlyHint, idempotentHint, and destructiveHint: false. The description adds meaningful behavioral context beyond these: the data is aggregated from real reviews, returns a short sentence plus reference date and source URL, and is not a unit price or quote amount. This gives agents a realistic expectation of the output type without contradicting 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 moderately compact: one scoping sentence with concrete topic examples, one sentence describing return composition, one caveat disclaiming exact pricing, and one sentence on the topic param. It front-loads the subject scope and keeps sentences short; the 'not a quote' caveat could appear slightly earlier, but the structure is mostly effective.

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 there is no output schema, the description compensates by explicitly stating what the tool returns (a short sentence, reference date, source URL) and clarifying the data is a review-aggregated range, not a quote. For one optional parameter and read-only semantics, this is sufficient context 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?

The schema documents the single optional `topic` parameter at 100% coverage with examples and empty-topic behavior. The description enriches that by enumerating acceptable topic categories (평, 방, 장르, etc.) and specifying that there are about 30 topics, which goes beyond the schema. This adds real value for the agent when deciding what to pass.

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 deliverable: aggregated interior cost ranges for 30 topics across floor type, room type, and construction process, returning a short sentence with reference date and source URL. It also explicitly disambiguates itself as a review-aggregated reference rather than a quote tool, which clearly separates it from sibling tools like nmjib_checklist and nmjib_faq_search.

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 parameter-level guidance ('topic을 주면 그 주제만', empty means the full table) and implies the tool is for cost references. However, it never explicitly says when to use this tool instead of its siblings or when not to use it, leaving alternatives differentiation to inference.

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, and non-destructive behavior. The description adds useful context beyond that: it returns the closest matching question, each answer carries a source URL, and the scope is limited to indexed public FAQ pairs. That is meaningful behavioral disclosure since there is no output schema.

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 tight sentences: it states the resource and operation, positions the tool relative to 'search', and ends with the return-attribution behavior. No filler words or redundant restating of the tool name.

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 (2 params, no output schema) and the description covers the main behavior: finding closest FAQ pairs, source URLs on answers, and when to prefer it. The only small gap is the absence of explicit mention of the result-count behavior, but the schema's constraints on 'limit' largely cover that.

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 schema itself covers the 'query' parameter (Korean question text), leaving roughly 50% of the parameters undocumented—the 'limit' parameter has only type/constraints and no prose. The description does not explain 'limit' or add any parameter-specific meaning, so it fails to compensate for the missing schema description.

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: finding the closest Q&A pair among the hundreds of FAQ pairs in the '내만집' public documents. It also differentiates the tool from the sibling 'search' by saying it is for short, direct answers, making the purpose unmistakable.

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 to use this tool instead of 'search' when a short and direct answer is needed, naming the alternative. It does not provide an explicit 'when not to use' clause, but the guidance is clear and actionable.

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 annotations, it discloses that the tool persists without readback, sends a 6-digit SMS to the responsible person's phone, returns a receipt number, and must be completed via nmjib_verify_code. It also sets expectations by stating it will not reveal pricing/margin/terms — exactly the kind of behavioral context an agent needs for this stateful, consent-gated flow.

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 four sentences are dense and each earns its place: purpose, storage behavior, side-effect/verification flow, consent requirement, and a limitation. It is slightly longer than the leanest possible definition, but there is no filler or repetition.

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 9-parameter, 6-required intake tool with no output schema, the description covers the full workflow: what fields to ask for, when consent is required, what happens on call (SMS + receipt number), how to complete via nmjib_verify_code, and what the tool will not disclose. Nothing an agent needs to invoke it correctly 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 already 100%, so the baseline is 3, but the description adds semantic value by naming the essential fields to collect (company, manager, contact, category, items) and by explaining consent conditions and the phone-number/SMS-code relationship. This is more than the schema provides without being redundant.

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 action and resource: '자재·가전·조명·가구 업체가 ... 입점을 문의할 때 접수한다'. It also states '저장만 하고 되읽지 않는다', which immediately separates this write/intake tool from read/search siblings.

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 explicit when/when-not conditions: use only when the user is a supplier representative and explicitly wants to register, after consent is obtained (consent=true), and it explicitly says it does not provide purchase price/margin/terms. It names the follow-up nmjib_verify_code but does not name an alternative intake tool for non-partner requests, so it stops just short of a top score.

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, idempotentHint, and destructiveHint, covering safety. The description adds that it calculates business days by process group and total based on schedule engine data. However, it does not describe the output format, edge cases (e.g., pyeong outside 15–65), or how the 22-step order is returned, leaving some behavioral ambiguity. This is adequate but not rich.

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 dense sentence that packs the 22-step detail, pyeong range, engine data reference, and example usage. It is front-loaded with the core function and includes useful query examples. No wasted words, though the length is a bit compressed; it remains clearly structured.

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 only one parameter and no output schema, the description explains it calculates business days by group and total, which gives a basic expectation. However, it is ambiguous whether the return includes the 22-step order itself or just the day breakdown, and it doesn't specify error handling or behavior outside the stated range. For a simple calculator, this is acceptable but not fully complete.

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% for the single parameter pyeong, which already has a description ('공급/전용 평수'). The tool description repeats that the input is pyeong and mentions a range of 15~65, which slightly conflicts with schema min/max (10/80). It does not add significant new meaning beyond the schema's own description, 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?

The description clearly states the tool's function: it takes a pyeong value and calculates interior process order (22 steps) and standard business days by process group. It distinguishes itself from siblings (checklist, cost reference, FAQ search) by focusing on schedule/order. The example questions ('process order', 'how many days', 'what comes first') make the purpose unambiguous.

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 provides direct usage context by listing the exact question types it answers ('공정 순서', '며칠 걸리나', '도배 마루 뭐가 먼저'). It implies usage for schedule-related queries but does not explicitly mention exclusions or alternatives. This is clear context without explicit when-not-to-use 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?

Even with annotations present, the description adds substantial behavioral context: success confirms the receipt and only then delivers it to the 담당자, wrong codes report remaining attempts, codes expire after 10 minutes, resend is limited to 3 times with 1-minute intervals, and the response contains only status and next step. This goes well beyond the structured metadata.

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 dense but front-loaded with the primary purpose, then efficiently covers success, failure, expiry, resend, and return-value restrictions. Every sentence earns its place, with no filler or repetition of annotation 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 3-parameter tool with no output schema, the description fully covers the lifecycle: prerequisites, success behavior, error handling, expiry, resend limits, and the restricted return payload. It gives an agent enough information to call the tool correctly and interpret the outcome.

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% and the schema already documents the 6-digit code, resend flag, and ticket pattern with an example. The description reinforces the real-world flow (e.g., omit code when resend=true), but does not need to compensate for any schema gap, so the baseline score 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 names a specific action: verifying the 6-digit code received by SMS to complete identity verification after receipt step 1, and explicitly references the predecessor tools (nmjib_worker_apply, nmjib_consult_request, nmjib_partner_inquiry). The title '접수 2단계' and the tool name together make its role distinct from siblings.

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 clearly states when to call the tool: after a step-1 receipt, when the user has a code, and when resend is needed due to expiry or missing SMS. It does not explicitly state when not to use it or name an alternative, but the sequencing against the listed step-1 tools 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?

The description discloses side effects and behavior beyond annotations: it states '저장만 하고 아무 데이터도 되읽지 않는다' (only writes, no reads), that a 6-digit SMS is sent to the applicant's phone, and that the response contains a receipt number. It also clarifies the registration is not complete until verification via nmjib_verify_code. These details are not captured by the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=true) and add valuable context without contradicting them.

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 relatively long but each sentence contributes: purpose, side effect (SMS), return value, usage condition, workflow steps, trade list, post-registration outcome, and exclusions. It is front-loaded with the core action and side effect. While slightly dense, the complexity of the tool (multi-step flow, 11 parameters) warrants the length, and it avoids fluff.

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 has 11 parameters, 5 required, and no output schema, the description is remarkably complete. It covers the action, side effects (SMS), return value (접수번호), the required user-facing steps (asking for info and obtaining consent), the follow-up tool (nmjib_verify_code), post-registration behavior (offers via SMS/알림톡), and exclusions (no search/조회). An agent can call it correctly with this information alone.

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 describes all parameters at 100% coverage, so the baseline is 3. The description adds value by prescribing the workflow: which parameters to ask first ('먼저 이름·연락처·공정·지역을 물어보고') and emphasizing the consent requirement with privacy details (also in schema). It repeats the trade list, which is redundant, but the sequencing and consent emphasis go beyond schema, justifying 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?

The description opens with a specific verb and resource: '시공 작업자(팀·개인)가 내만집에 등록을 신청한다' – clearly stating it registers construction workers. It differentiates from siblings by explicitly stating it has no search/조회/연락처 열람 features and by referencing nmjib_verify_code as the follow-up step, so an agent can distinguish it from related 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?

The description gives explicit usage conditions: '사용자가 스스로 "내만집에 작업자로 등록하고 싶다/작업 받고 싶다"고 할 때만 쓴다' and instructs to first ask for name, contact, trade, and region, then read privacy info and obtain consent before calling. It also names the next tool (nmjib_verify_code) and explains the verification flow, leaving no ambiguity about when to use this tool versus 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 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.