Ablakunio Nyílászáró MCP

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

No annotations are provided, so the description carries full burden. It only describes the checking action without disclosing side effects (none expected), return value format, or edge cases like no match.

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 short (two sentences) but includes redundant bilingual content. It is adequately sized but not optimally structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description does not explain what the tool returns (e.g., boolean, list, errors). It lacks completeness for a check operation without return specifications.

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?

With 0% schema description coverage, the description adds no meaning to parameters. It mentions 'size' generically but does not explain width_cm, height_cm units/constraints, or the optional type enum.

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 checks for ready-stock standard windows/doors matching a size, and explicitly calls out it's a faster, cheaper option, distinguishing it from siblings like get_price_estimate or request_quote.

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 for standard size, ready-stock products (gyorsabb, olcsóbb opció) but does not explicitly state when to use versus alternatives, nor provide exclusions or prerequisites.

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?

Discloses that price is computed live, no fixed SKU, and final price requires on-site survey. No annotations provided, but description covers key behavioral aspects. Could mention idempotence or authentication needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three concise sentences, bilingual coverage, front-loads key info: estimate, live computation, survey caveat. No wasted words.

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 6 parameters and no output schema, description explains purpose, live estimation, and final price dependency. Could mention return format or constraints, but sufficient for a price estimate tool.

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 high (83%), so baseline is 3. Description does not elaborate on parameters beyond the schema, but includes bilingual hints about width/height and type. Adds no extra semantics beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it provides a gross price estimate for custom-size plastic doors/windows/shutters, explicitly naming the resource (öffnyílászárók) and differentiating from siblings like check_stock by focusing on price estimation.

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?

Description indicates this is a live estimate, not a final price (after on-site survey). It implies usage for initial pricing. Could be more explicit about when to use vs request_quote, but context signals help.

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 burden of behavioral disclosure. It states the tool lists items with prices, but omits details like whether quantities are included, if the list is exhaustive, or any side effects (e.g., read-only nature). With zero annotations, this is insufficient for an agent to understand the tool's full 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 description is concise, consisting of two short sentences. However, it repeats the same information in Hungarian and English, which is slightly redundant for an English-oriented agent. Still, it is efficient and 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?

Given the tool has no parameters and no output schema, the description provides the core purpose but lacks details on the output format (e.g., whether it returns a list of objects or just names). It is adequate for a simple list tool but could be enhanced to specify what fields each item includes (e.g., type, price).

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 has 0 parameters, and schema coverage is 100% (since there are none). The description adds no parameter information, which is acceptable because no parameters exist. Baseline 4 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 that the tool lists current ready-stock items (standard windows and doors) with retail prices, using a specific verb 'list' and resource 'inventory'. It differentiates from sibling tools like check_stock (which likely checks specific item stock) and get_price_estimate (which estimates prices).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like check_stock or get_price_estimate. It does not mention exclusions or prerequisites. The agent must infer usage from the tool name and context.

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 provided, the description carries full behavioral disclosure. It explicitly states that placeholder data will be rejected, that it triggers a real callback by a colleague, and that it is not a test tool. This gives the agent a clear understanding of the tool's behavior beyond its purpose.

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 key warning and purpose. While somewhat repetitive (dual language and repeated emphasis on real data), every sentence serves to prevent misuse. It could be slightly more concise, but the structure effectively communicates critical constraints.

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 no output schema and no annotations, the description adequately covers its intent, constraints, and expected input requirements. It lacks details on result handling (e.g., confirmation), but for a submission tool, the provided context is sufficient for an agent to avoid misuse and decide when to call.

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 baseline is 3. The description adds value by reinforcing the critical constraint that name and phone must be real and not placeholder, which goes beyond the schema's basic descriptions. It does not add new parameter semantics for optional fields but emphasizes the real-data requirement for required ones.

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 submits a real quote/callback request on behalf of a real client. It uses specific verbs (beküldése, submits) and distinguishes itself by emphasizing it is not a test/demo tool, targeting the real-world use case.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use criteria (only when a real end-user requests a callback with real name and phone) and when-not-to-use (never with placeholder/example data, not for testing). It instructs to ask the user for real contact if not available. However, it lacks mention of alternative siblings like check_stock or get_price_estimate, so agents must infer when to choose this tool over others.

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