내만집 (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 transparently discloses save-only behavior, SMS code sending, and the verify_code follow-up, but it also describes an operation that creates a reception and sends an SMS per call. This contradicts the idempotentHint:true annotation, which claims repeated identical calls have the same effect.

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 front-loaded with the core purpose, then behavior, usage conditions, and exclusions. Every sentence adds operational information, and despite its length it remains a tight, well-structured single-paragraph spec.

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 no output schema, the description still tells the agent what happens (6-digit code, reception number, verify step) and what the tool does not do. Combined with the fully described input schema, an agent has everything needed to call it 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 covers all 10 parameters with good descriptions, so the baseline is 3. The tool description adds useful situational semantics by explaining when to set trades, the consent workflow, and that it is not for cost estimation, exceeding schema-only guidance.

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 action (receive consultation/worker-matching inquiries), the exact resource (집주인 상담·작업자 매칭), and the scope (reception step 1). It also separates itself from cost estimation and worker-list lookup, making it distinguishable 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?

Explicitly says to use only when the user asks for consultation/worker connection/contact, lists the data to collect and the consent requirement, and names nmjib_cost_reference as the alternative for cost questions. This is complete when-vs-alternative 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?

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?

Annotations already cover read-only, idempotent, and non-destructive hints. The description adds valuable context by stating it provides only brand, product name, and specifications (not price or stock), and enumerates the categories. This goes beyond the annotation safety profile and informs the agent about output scope, which is useful. 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?

The description is somewhat long but each part is purposeful: it opens with the core function and the no-price caveat, then lists categories, gives examples, and ends with routing to the alternative. It is front-loaded and structured clearly, though it could be tightened slightly without losing meaning.

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 four optional parameters and no output schema, the description covers the purpose, scope, categories, and alternative for pricing. It does not explicitly describe the return format (e.g., list vs. single item), but it states the tool provides brand, product name, and specifications, which implies the output content. This is adequate for an agent to know when to call it and what to expect.

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 75% (brand, query, category have descriptions; limit has none). The description reinforces the meaning of brand, category, and keyword through the main sentence, but does not add new details about the parameters themselves, such as limit behavior or format expectations. Since coverage is above 50% but below 80%, the description adds modest value over the schema but doesn't fully compensate for the undocumented limit parameter.

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 finds interior materials and appliances by category, brand, and keyword, and explicitly notes it does not return price or stock. It also lists the exact categories and example queries, and distinguishes itself from the sibling nmjib_material_request by routing price/purchase inquiries there. This is a specific verb+resource with clear scope.

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 concrete when-to-use conditions with example queries like '내만집에 어떤 강마루 있어?' and '제일벽지 실크 벽지 목록', and explicitly says that for price/purchase, use nmjib_material_request or the app. This is explicit guidance on usage and 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?

The description states that calling the tool sends a 6-digit confirmation SMS and returns a reception number, implying a side effect on every call. This directly contradicts the annotation idempotentHint=true, which indicates that repeated identical calls should have the same effect as a single call. Sending a new SMS each time violates idempotency, so the description contradicts 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, well-organized paragraph that front-loads the purpose and then covers usage conditions, exclusions, and the verification flow. Each sentence adds value, though it is slightly long. It is efficient without being redundant.

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 11 parameters, no output schema, and the complexity of the SMS verification flow, the description covers the overall workflow, including the follow-up tool and exclusions. It tells the agent when to call and what to expect, though it does not specify the reception number format or error handling, which is a minor gap.

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 covers all 11 parameters with detailed descriptions (100% coverage), so the description does not need to add parameter semantics. It briefly mentions required fields (name, contact, items, quantity, region) and consent, but these are already in the schema. No additional meaning is provided beyond the schema, so baseline 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 clearly states the tool's purpose: to receive inquiries for material purchase or quotes, and it differentiates from siblings by explicitly naming the follow-up tool nmjib_verify_code and mentioning it is step 1. It also distinguishes from search for magazine guidance, making 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 explicitly states when to use the tool (only when the user explicitly asks for a material quote/purchase), what it does not do (does not provide prices, inventory, or product lists), and directs to alternatives (search for magazine, 담당자 회신 or app quote). It also describes the verification step with nmjib_verify_code, giving clear context for selection.

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=true and idempotentHint=true. The description adds valuable context: it mentions the internal schedule engine calculation, inclusion of parallel processes, curing waits, and reserve days. It also clarifies the output (per-bar days, daily schedule, total duration). 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?

The description is compact and front-loaded, leading with the core function, then the calculation details, then usage examples. It is not excessively verbose, though it packs several clauses into one sentence. Efficient for the information conveyed.

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 adequately specifies what the tool returns (per-bar days, daily schedule, total duration) and what inputs it accepts. It does not detail the exact output structure, but it is sufficient for an agent to know the tool's behavior.

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 single parameter 'pyeong' is already well-documented in the schema (default 30, min 10, max 80). The description reinforces it ('평수를 주면') and adds a hint about the typical range (15~65), but this is slightly inconsistent with the schema's wider range. Overall, the description adds little beyond what the schema provides.

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 returns a 22-step process order with business days and total duration for a given pyeong, with specific example queries. It distinguishes itself from siblings like nmjib_cost_reference or nmjib_checklist by focusing on schedule and sequence.

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 lists example questions (e.g., 'process order', 'how many days', 'wallpaper vs flooring first') that indicate when to use it. However, it does not explicitly mention alternatives or exclusions, leaving some inference to the agent.

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, the description discloses the success side effect (receipt is confirmed and delivered to the 담당자), the failure behavior (remaining attempts), the 10-minute expiry and resend limitations, and the minimal response scope. None of this contradicts the annotations (idempotent, non-destructive, not read-only); it enriches 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?

Four compact sentences front-load the verification purpose and then pack side effects, error handling, resend rules, and response scope into the remaining sentences. Every sentence carries distinct operational information with no filler.

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 small, flat tool with no output schema, the description covers the complete call flow: when it applies, what input is needed, what happens on success/wrong/expired/missing codes, and what the response will and will not contain. An agent has everything needed to invoke it 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 already documents all three parameters at 100% coverage, including the code being omitted when resend=true and the ticket pattern. The description adds the missing SMS and expiry conditions that trigger resend, but much of the parameter-level detail is already in the schema, so it only modestly exceeds the baseline.

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 a 6-digit code after stage 1 to complete identity confirmation, and explicitly lists the four stage-1 siblings that precede it. This makes the tool's role and position in the process unmistakable and clearly distinguishes it from the other nmjib_* 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 states when to call (after the listed stage-1 tools), how to handle wrong codes (remaining attempts), how to handle expiry (resend=true), and how to handle a missing SMS (call with resend=true). It also gives the 3-call and 1-minute limits, so an agent can decide between verify and resend without guessing.

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 cover readOnly, idempotent, and non-destructive behavior. The description adds meaningful context beyond that: queries are expected to be Korean natural language, and results contain ids for fetching full documents. This clarifies follow-up behavior 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 front-loaded with the main action and resource, but the long parenthetical enumeration of document types makes it verbose. While each item gives useful context, the list could be shortened without losing the core purpose, so it does not achieve the zero-waste standard of a 5.

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 search tool with no output schema, the description explains that results are ids to pass to fetch, which is essential for follow-up. Combined with annotations and schema, it covers the necessary call context, though edge cases like empty results or sort order are not addressed.

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 does not add parameter-specific details beyond what the schema already provides (e.g., query examples, kind enum, limit). The mention of content categories may inform query phrasing but does not enrich the meaning of individual parameters.

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 (검색한다) and the resource (내만집 반셀프 인테리어 공개 문서), and enumerates content categories to help agents understand scope. It does not explicitly distinguish this from sibling tools like nmjib_faq_search or nmjib_process_guide, so it lacks the explicit differentiation that would earn a 5.

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 implies usage by describing what is searchable and instructing to pass result ids to fetch for full text, which gives a workflow hint. However, it does not state when to prefer this tool over alternatives or provide any exclusion criteria, so guidance is merely implied.

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