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 must bear full burden. It does not disclose what 'close to the given size' means, what happens if no match, or any side effects/permissions. Minimal behavioral context.

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 (two sentences, bilingual) and front-loaded. However, the bilingual repetition is slightly redundant. Still efficient overall.

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 three parameters and no output schema, the description is incomplete. It lacks information about return values, error handling, or the meaning of 'close'. Does not provide sufficient context for an agent to use the tool properly.

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%, meaning parameters have no descriptions. The description only says 'matching a size' but does not explain the specific parameters (type, width_cm, height_cm) or their role. Fails to compensate for missing schema info.

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 it checks ready-stock standard windows/doors matching a given size. The verb 'checks' and resource 'ready-stock standard windows/doors' are specific, and the tool is distinct from siblings like 'get_price_estimate' or 'list_inventory'.

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 this is for quick/cheap standard options, but does not explicitly state when to use this tool versus alternatives like 'get_price_estimate' or 'list_inventory'. No when-not or exclusions provided.

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 burden. It mentions code expiry (30 minutes) and max 5 attempts, but does not disclose whether the operation is read-only or destructive, or what happens on failure beyond implied blocking.

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, clear paragraph that front-loads the purpose. It is concise but could be improved with bullet points for readability.

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 no output schema and no annotations, the description provides critical behavioral constraints (30-min validity, 5 attempts) and clear parameter sources. It sufficiently covers the tool's context for a confirmation step.

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 already describes both parameters (100% coverage). The description adds that 'lead_ref' comes from the 'request_quote' response and that the code is delivered via email and spoken by the customer, adding practical context.

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: redeeming a 6-digit confirmation code after a 'request_quote' call. It distinguishes itself from siblings by specifying it is a post-request_quote confirmation 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?

The description explicitly states it should be used after 'request_quote' and provides context about code validity and max attempts. It does not explicitly list alternatives but implicitly tells when to use this tool.

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 bears full burden. It discloses that the price is computed live, has no fixed SKU, and that the final price may change after an on-site survey. This sets realistic expectations. However, it does not mention rate limits, response structure, or error behavior, which would further aid an agent.

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 very concise: two short sentences per language, front-loaded with key points. Every sentence adds value (live computation, custom sizing, survey dependency). No redundant or vague language.

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 no output schema, the description could better explain the return format (e.g., currency, number, validity period). It also omits error conditions or scope (valid for certain products). However, the schema covers input constraints, and the tool is simple, so the description is minimally adequate.

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 high (83%), so the baseline is 3. The tool description adds no additional meaning beyond the schema; it rephrases concepts in bilingual text but doesn't elaborate on parameter constraints or relationships. For example, 'quantity' is undocumented in the schema and not addressed in the 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 clearly states it provides a gross price estimate for custom-sized plastic windows/doors/shutters, with bilingual Hungarian/English text. It distinguishes from sibling tools (check_stock, confirm_quote, list_inventory, request_quote) by specifying it is a live estimate and not a final quote. The verb 'get_price_estimate' combined with definitions 'computed live' and 'no fixed SKU' makes 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 implies usage context (getting an instant estimate before ordering), but lacks explicit guidance on when to use this tool versus alternatives like request_quote or confirm_quote. No 'when not to use' or direct comparisons to siblings are provided, leaving the agent to infer relative purpose.

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 full burden. It indicates a read operation listing items with prices, but lacks details about response format, sorting, or pagination. Basic transparency is provided.

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?

Two sentences (one Hungarian, one English) with zero waste. Every word is functional. Front-loaded with the action and scope.

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 no parameters and no output schema, the description adequately specifies the items listed and that they come with retail prices. It could mention that it is a full list, but the context signals (sibling tools) help differentiate.

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?

No parameters exist (0 params, 100% coverage). The description adds meaning by specifying the types of items (standard doors/windows and sills) and that prices are included. Baseline for no params is 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 clearly states it lists current ready-stock items (standard doors, windows, and sills) with retail prices. The verb 'list' and resource 'inventory' are specific, and the tool is distinct from siblings like check_stock or confirm_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 viewing all stock items, but it does not explicitly state when to use this tool versus alternatives. No exclusions or prerequisites are mentioned.

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 zero annotations provided, the description carries full behavioral-transparency burden, and it uses that responsibly: it discloses that a colleague will actually call the supplied number within 24 hours and that the case is taken from on-site survey through installation, so the tool has real external consequences. It also reveals the system-side validation behavior (invented/placeholder data is rejected). Missing details such as the response shape or error behavior are not covered, but the safety-critical behaviors are clear.

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 essential purpose and trigger appear in the first sentence, and each paragraph does carry real information (trigger, 24-hour callback, fake-data prohibition, need to ask the user). However, the same no-test/no-placeholder rule is repeated in multiple forms and in both languages, including repeated sample placeholders, making the text notably redundant for an MCP description. It is front-loaded but not economical.

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 mutation tool that triggers a real human callback, the description provides the agent with everything needed to call it correctly: the condition to call, which real data to collect, the constraint to ask the user when data is missing, and the post-call effect (24-hour callback and full case handling). Output schema is not provided, so the description does not need to document the return; the only genuine omission is the broader workflow (e.g., what comes after the returned code, interactions with confirm_quote).

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 all 6 parameters (100% coverage), including per-parameter instructions on the real name, real phone intended for the callback, email receiving the 6-digit verification code, and the allowed interest values. The description adds only a general cross-parameter warning about real data; it does not enrich how any individual parameter is to be used or formatted. With full schema coverage, the baseline of 3 is correct.

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

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

The description opens with the role ('MEGRENDELÉS-INDÍTÓ ESZKÖZ' — the request-initiating tool), states a specific action (record the user's quote request/order intent, submit a REAL callback request), and gives the trigger condition (the user is satisfied with a price or stock item). This separates it from the stock- and price-oriented siblings (check_stock, get_price_estimate, list_inventory) and from confirm_quote by focusing on a new callback, not an already confirmed 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?

Usage conditions are explicit: invoke the tool only when a real end-user has accepted a price/stock product and actually requested a callback with their own genuine contact details. It also states when-not: never use it for test/demo purposes, never input placeholder/example data, and if real contact data is missing, the agent must ask the user rather than invent it. The description stops short of a 5 because it never names alternative sibling tools (e.g., use get_price_estimate first / check_stock for availability), leaving some routing 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.