내만집 (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?

Annotations only cover the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description adds the real behavioural payload: it saves without readback, sends a 6-digit SMS to the phone, returns a receipt number, and must be completed via nmjib_verify_code. The consent/privacy precondition and the explicit 'no worker contacts returned' limit are exactly the kind of side-effect disclosure annotations cannot carry.

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?

Dense but every clause is functional: the two-step handoff, the consent gate, the trades conditional, and the cost-tool exclusion each prevent a distinct failure mode. The core action is front-loaded in the first sentence, with constraints following in descending priority.

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 10-parameter write tool with no output schema, the description supplies what the schema cannot: the return value (접수번호), the completion path (nmjib_verify_code), the SMS side effect, and the consent obligation. An agent has everything needed to invoke it and continue the flow.

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%, so the schema already documents all ten parameters including the trades vocabulary and the consent fields, which sets the baseline at 3. The description adds genuine routing value beyond that by stating the conditional for trades ('작업자가 필요한 공정이 정해져 있으면 trades 에 넣는다') and the order in which the other fields should be collected.

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 (집주인 상담·작업자 매칭 문의를 접수한다) and scopes it precisely. It explicitly distinguishes itself from siblings by naming nmjib_cost_reference for cost questions and declaring it does not return worker lists/contacts, so an agent can route without opening another schema.

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 an explicit trigger condition ('사용자가 명시적으로 상담 받고 싶다/작업자 연결해 달라/연락 달라 할 때만') plus a prerequisite sequence (ask for name/contact/region/pyeong/scope, get consent, then consent=true). It also names the alternative for a neighbouring intent (금액 질문은 nmjib_cost_reference), covering when-not-to-use.

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 declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds non-obvious domain context: that price and stock quantity are deliberately absent and only brand/name/spec are exposed, which prevents an agent from promising unavailable data.

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?

Purpose, scope and alternatives are front-loaded in the first two sentences; the 20-item category list is verbose but earns its place since the schema has no enum. Only minor trimming would be possible without losing signal.

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, four-parameter search tool with no output schema, the description covers scope, the returned field set, category vocabulary and the fallback route for purchase intents. It stops short of describing result ordering, pagination, or behavior when no match is found.

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 75%, with brand and query already documented. The description adds real value by enumerating the full allowed category vocabulary (마루/바닥재, 벽 마감, 몰딩 …), which the schema does not encode as an enum, materially improving category matching.

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 ('내만집 스토어에 등록된 인테리어 자재 상품을 카테고리·브랜드·키워드로 찾는다') and explicitly bounds what is returned (brand, product name, spec only; no price or stock). It also separates itself from the purchase-oriented sibling nmjib_material_request.

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?

Provides concrete trigger phrasings ('내만집에 어떤 강마루 있어?', '제일벽지 실크 벽지 목록') and explicitly routes price/purchase intents to nmjib_material_request or the web app. Both when-to-use and when-not-to-use are covered.

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?

Goes well beyond the annotations (readOnlyHint=false, idempotent=true, destructive=false): it discloses that the call only saves and reads nothing back, that a 6-digit verification SMS is sent to the applicant's phone, that the response returns an intake number that must be confirmed via nmjib_verify_code, and that downstream quote requests arrive with 0 fee. This is exactly the operational context annotations cannot carry.

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?

Front-loaded with purpose, then behavior, then usage conditions — a logical order. It is dense with useful content, but the enumerated trade list duplicates the schema's trades description, which is the one clearly redundant passage.

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?

No output schema exists, and the description compensates by describing the return value (intake number) and the follow-up verification flow. For an 11-parameter mutation tool with an SMS handshake, nothing an agent needs to call it correctly appears 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 description coverage is 100%, so the schema already documents every parameter including the trade vocabulary and consent terms. The description largely repeats the trades list and consent flow already present in the schema, adding little new parameter-level meaning. 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?

States a specific verb+resource: registering a construction worker (team or individual) with 내만집. It also distinguishes itself from the sibling nmjib_verify_code by naming that tool as the explicit next step, so an agent can route correctly without opening schemas.

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 an explicit trigger ('사용자가 스스로 등록하고 싶다/작업 받고 싶다고 할 때만') plus a required prerequisite sequence (ask name/contact/trade/region, read the privacy notice, obtain consent=true before calling). It also states the non-capability boundary — no worker search, lookup, or contact viewing — which prevents misuse against sibling lookup tools.

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 the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is low. The description adds genuinely useful behavior: the query language is Korean natural language, and results are a two-step retrieval whose ids feed the fetch tool. It stops short of describing result shape or ranking/pagination behavior.

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 purpose is front-loaded in the first clause, but the description then dumps roughly thirty individual guide titles into a single parenthetical. That enumeration inflates token cost without helping an agent decide or invoke; a category-level summary would carry the same information at a fraction of 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 read-only search tool with 100% schema coverage and no output schema, the description supplies what the schema cannot: corpus scope, Korean NL input, and the id→fetch follow-up. Only the result shape (fields returned, snippet vs. full text) is left implicit.

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, kind (enum), and limit are all documented with examples and bounds in the schema itself. The description adds no syntax, format, or defaulting detail beyond that, so the 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 a specific verb and resource: searching 내만집(nmjib.com)'s public self-renovation documents, and the long parenthetical makes the covered corpus concrete (magazines, method guides, guide chapters). It also clarifies the two-step flow (take result id → fetch). It does not, however, differentiate itself from the sibling nmjib_faq_search, which is a comparable search tool.

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?

Usage is implied: query in Korean natural language, then pass the returned id to fetch for the full text. There is no explicit statement of when to prefer this over nmjib_faq_search, nmjib_process_guide, or nmjib_cost_reference, and no exclusions or preconditions.

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