Skip to main content
Glama

menu__get_combos_info

Read-only

Retrieve all combos for an organization, including categories and specifications. Use organizationId from organizations__get_organizations to fetch combo details for menu management.

Instructions

Все комбо организации (категории и спецификации). Где взять ID: organizationId → organizations__get_organizations. Троттлинг MCP-сервера (не лимит iikoCloud): не чаще 10 запрос(ов) за 60 с — кэшируйте результат в диалоге.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
requestYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds genuinely useful behavioral context beyond them: the MCP-server rate limit of 10 requests per 60 seconds and a recommendation to cache results. This is precisely the rate-limit disclosure the rubric credits; no contradiction with annotations exists.

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

Conciseness5/5

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

Three short sentences, each earning its place: purpose, ID sourcing, and throttling/caching advice. The most important information is front-loaded and there is no filler.

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

Completeness3/5

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

For a single-required-parameter read tool with annotations covering safety and no output schema, the description covers the essentials: what is returned, where to get the ID, and rate limits. The notable gap is extraData, which is undocumented in both the schema and the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 of explaining parameters. It adds real value for organizationId by pointing to organizations__get_organizations as the source, but it completely ignores extraData, whose boolean/null semantics are left entirely to the bare schema with no explanation. Compensation is partial at best.

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

Purpose4/5

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

The description states a specific verb+resource+scope: 'Все комбо организации (категории и спецификации)' — all of an organization's combos with their categories and specifications. This distinguishes it from menu siblings like menu__get_nomenclature, menu__get_external_menu_by_id, and menu__calculate_combo_price by resource type, though it never names those alternatives explicitly.

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

Usage Guidelines3/5

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

The description gives operational guidance: where to source organizationId ('organizationId → organizations__get_organizations') and a throttling/caching policy (10 requests per 60s, cache in dialog). However, it provides no when-to-use/when-not-to-use guidance relative to any of the ~130 sibling tools, so tool selection is left to inference.

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

Deploy Server

Other Tools