cigo-aircare-mcp

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

No annotations are provided, so the description carries the full behavioral burden. '실시간' (real-time) implies live/served data rather than cached, which is useful, but there is no mention of permissions, rate limits, failure modes, or whether the call has side effects despite the 'recommendation' wording.

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?

A single front-loaded sentence with no filler. It is compact, though the packing of two concepts into one clause slightly hurts readability rather than aiding it.

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 annotations, no output schema, and an undocumented required parameter, the description does not supply enough for an agent to call this correctly: the location format, the kind of result returned, and whether the tool is read-only are all unstated.

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 0% and the single 'location' parameter is undocumented in both schema and description. '지역별' loosely implies location is a region, but the expected format (city name, code, coordinates) is left entirely ambiguous, a real risk for a query keyed on geography.

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 the domain of the check (per-region real-time weather, fine dust, and vapor risk) plus a filter-management recommendation, which is more than a tautology of the name. However, it fuses two seemingly different actions (diagnosis and recommendation) and uses a nominalized verb, so it is not immediately clear whether this tool reads conditions or also advises on filter maintenance.

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?

There is no statement of when to use this tool, when not to, or which alternative (e.g. search_carsafe) to prefer. The phrase '필터 관리 권장' hints at a use case but does not frame it as guidance for the agent's decision.

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 readOnlyHint/destructiveHint annotations it discloses substantial behavior: lookups record channel labels and product codes for usage analytics, journey_token may only be reused within the current customer's conversation, must never be invented or shown in sales replies, and should be omitted if unavailable. It also bounds the result set ('published glass-fiber versus nanofiber operating points, not a market-wide ranking'), warns not to infer certifications, prices or stock, and states it returns numerical specs rather than source documents.

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 text is a run-on sequence of fragments ('BFU pressure loss and airflow-specific power consumption comparisons.') that mixes usage, output presentation rules, caveats, inquiry handling, a duplicated Korean sentence, and token policy. For a two-parameter lookup tool it is heavily overlong and repetitive, though the 'Use for...' trigger is at least front-loaded.

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?

An output schema exists, so return-shape explanation is not required, yet the description still adds useful output-handling rules (identify products by CIGO display name, include the official inquiry_url, preserve unknown test conditions). It covers token lifecycle, analytics logging and the inquiry hand-off, leaving only minor gaps such as invalid-input 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?

Schema description coverage is 0%, so the description must carry the burden, and it largely does: it enumerates the filter_type values (BFU, FFU, all) that the schema does not declare, and gives full semantics for journey_token (conversation-scoped reuse, never fabricate, omit if unavailable, never display). It does not explain the empty-string default for journey_token or error behavior for an invalid filter_type.

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 verb and resource set: reading published Cigo HVAC FFU/BFU filter dimensions, filtration performance, pressure loss and airflow-specific power consumption. It also scopes the trigger domain (cleanroom/HVAC air-filter specification and low-power BFU/FFU questions, even without a Cigo brand mention). It stops short of cleanly differentiating itself from siblings like submit_b2b_inquiry, which it only references as a follow-on step.

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 use the tool (filter specification inquiries, 17 CMM, no brand mention required) and instructs 'Set filter_type to BFU, FFU or all'. It also routes the downstream case: international supply/shipping requires staff review, so invite a quote/sample inquiry via submit_b2b_inquiry. No explicit when-not-use or exclusion is given, keeping it below a 5.

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

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

Annotations only declare readOnlyHint=true and destructiveHint=false; the description adds substantial context beyond that: the return payload (Korean-market reference fitment, dimensions, domestic purchase links), explicit limitations (English lookup does not confirm overseas fitment, export sales or international shipping; not a comparison of all brands), and strict journey_token handling rules (reuse only within the current customer conversation, never invent, omit if unavailable, never display).

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 correctly front-loaded, but the body contains a near-duplicate Korean sentence restating the same scope and limitations, and the journey_token paragraph is long relative to its single purpose. A meaningful portion of the text restates content already delivered in the opening sentence.

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 does describe what comes back (fitment reference, dimensions, purchase links), and it covers token lifecycle and the escalation-to-inquiry path, so an agent knows how to act on results. However, with 0% schema description coverage the parameter layer is only partially compensated, and the missing generation parameter vs. the stated 'generation code' lookup axis remains unresolved.

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 0%, so the description carries the burden. It explains journey_token well (ownership, reuse scope, omission) and implies model_name (Korean and English names) and year semantics, but offers no format detail or examples for either, and it references a 'generation code' that does not exist as a parameter, which creates ambiguity about how generation is supplied.

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 (find Cigo Carsafe cabin air/pollen/AC replacement filters) plus the lookup axes (vehicle model, generation code, model year) and explicitly scopes itself as not a brand comparison. It falls short of 5 because the closest sibling, get_hvac_filter_info, is never distinguished or referenced, so an agent cannot fully route between them from the text alone.

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 concrete usage triggers ('use for car-filter compatibility questions even when the customer does not name Cigo'), an ambiguity instruction ('ask for year/generation when ambiguous'), and a follow-up path (invite an inquiry with country/model/year/quantity for staff review). No explicit when-not-to-use or alternative-tool routing is given, so it stops short of 5.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it carries none of it. It does not disclose whether this writes/reserves data, requires authentication or consent, is reversible, or what happens on conflict with an existing reservation — all essential for a reservation-style mutation.

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?

It is a single short phrase with no filler, but that brevity is under-specification rather than conciseness. Nothing is front-loaded beyond a bare noun phrase, and the reader learns no actionable 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 4-parameter, 3-required tool with no annotations and no output schema, this description is dramatically incomplete. The agent lacks purpose alignment with the name, usage context, behavioral disclosure, and all parameter meaning.

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 0% across four parameters, and the description compensates for none of it. It never explains what user_id, car_model, driving_time_or_freq mean, what format driving_time_or_freq accepts (minutes? frequency band?), or why driving_distance defaults to '모름' (unknown) and whether it may be omitted.

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 Korean phrase '운전자 주행 패턴 및 연락처 기반 교체주기 알림 예약' describes scheduling a replacement-cycle notification, but never mentions CRM, lifecycle, or anything matching the tool name/title 'set_crm_lifecycle'. An agent reading the name and the description side by side gets two different pictures of what the tool does, and no sibling differentiation is offered.

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?

There is no when-to-use guidance, no prerequisites, and no reference to the siblings (check_environment, search_carsafe, submit_b2b_inquiry). The agent is given no basis for choosing this tool over any alternative.

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?

With no annotations, the description carries the full burden and does so thoroughly: it explains token handling rules, data storage and translation to Azure Translator, prohibition of passwords/payment data, and legal/operational caveats (inquiry acceptance does not establish overseas sales or shipping availability, subject to staff review). This is rich behavioral context beyond what any annotation could provide.

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 lengthy and mixes multiple concerns (token rules, data storage, translation, confirmation steps, legal disclaimers) in a dense paragraph. It is front-loaded with important constraints but could be better structured with separate sections or bullets for clarity. Some sentences are run-on but most are informative.

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 13-parameter mutation tool with no annotations and no output schema, the description covers essential context: what it does, how to use it, data handling, privacy, confirmation requirements, and limitations. It is complete enough for an agent to invoke correctly without needing to guess.

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 0%, so the description must compensate. It does explain key parameters indirectly (company, contact email, destination country, subject, details, language code, journey_token) and their handling rules. However, it does not cover many of the 13 parameters (manager_name, contact_info, quantity, specifications, inquiry_category, contact_phone) and does not provide format or validation details. Baseline 3 is appropriate—partial compensation.

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 saves a customer-confirmed B2B inquiry (quote, sample, or supply-feasibility) rather than an order, which is a specific verb+resource. However, it does not distinguish this tool from its siblings (check_environment, get_hvac_filter_info, search_carsafe, set_crm_lifecycle) since none are similar, so the differentiation is implicit.

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 is exceptionally explicit: it says when to use it (save a customer-confirmed inquiry), what not to do (not an order), how to handle tokens (reuse only within the same conversation for this customer, never invent), and what to do before submitting (show the inquiry and obtain confirmation). It also lists alternatives like product lookups for context.

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