yandex-eda-mcp

by sandexplus

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.18
Disambiguation5/5
Each tool targets a distinct resource/action: auth, addresses, restaurant search, menu, product search, cart management, and ordering. Even similar tools like add_product vs add_to_cart and remove_from_cart vs clear_cart are explicitly differentiated by domain (shop vs restaurant) and scope (single vs all). No ambiguous overlaps exist.
Naming Consistency5/5
Tool names follow a consistent verb_noun pattern in snake_case (get_menu, set_address, remove_from_cart, search_restaurants). Two bare verbs (login, navigate) are acceptable as unambiguous actions, and the overall style is uniform.
Tool Count4/5
18 tools is on the heavier side but justified by the dual restaurant/shop domains and full order lifecycle (auth, addresses, search, cart, payment, ordering). Each tool serves a clear purpose, though a few utility tools (navigate, debug_snapshot) could be seen as auxiliary.
Completeness4/5
Covers the entire ordering flow from login and address setup through search, menu browsing, cart management, and order placement with payment. Minor gaps exist: no direct quantity editing in cart (workaround via remove/add) and no order history, but these don't block the primary use case.
Average 4.5/5 across 18 of 18 tools scored. Lowest: 3.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return value shape (a label or street) and suggests a use case, which provides some transparency. However, it does not disclose edge cases such as behavior when no address is set, authentication requirements, or potential side effects. The description adds value but leaves gaps expected for a tool with no annotations.
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?
The description is exceptionally concise: two short sentences that front-load the purpose and then add a usage tip. Every phrase adds value, and there is no redundant or verbose language. This is exemplarily efficient.
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 simple parameterless getter, the description covers the return format and a typical use case. However, the absence of an output schema means the description should fully explain return values and edge cases. It does not mention what happens if no address is saved, or any prerequisites like login. Thus, while adequate for basic use, it has notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty. The rubric states a baseline of 4 for 0 parameters. The description adds no parameter-specific information because there is nothing to document. The schema coverage is 100% vacuously, so the description does not need to compensate for any undocumented params.
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 clearly states the tool returns the current delivery address, with a specific example of the output format (label like 'Home' or street). It is not a tautology and uses a specific verb ('returns') and resource ('current delivery address'). However, it does not explicitly differentiate from sibling tools like list_saved_addresses or set_address, so it lacks direct sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: asking the user 'are we looking here?' before searching. This gives context for when to use the tool. It does not explicitly mention alternatives or when not to use it, but the usage scenario is clear. This fits 'clear context, no exclusions' rather than full when/when-not/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states the action but does not disclose side effects, required authentication, state changes, or behavior on invalid paths. This is a significant gap for a tool that likely alters the app's current view.
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?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool with one well-documented parameter, the description is largely sufficient. However, the lack of behavioral details (e.g., what happens after navigating, expected output) and missing annotations prevents a perfect score.
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 coverage is 100% since the parameter 'path' has a clear description ('Путь (/orders) или полный URL'). The tool description repeats this without adding extra meaning, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (переходит) and states the resource (path or full URL within Yandex Eda), clearly distinguishing it from sibling tools like search_restaurants or add_product. This fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the tool for navigating to paths or URLs, and no sibling tool serves this purpose. However, it does not provide explicit when-not-to-use guidance or alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explicitly lists the returned data (URL, title, text) and the screenshot action. However, it does not disclose potential side effects (e.g., file creation) or confirm the tool is read-only regarding page state.
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?
The description is only two sentences: the first states the primary function, the second gives a practical use case. No redundant details or fluff; it is front-loaded and efficiently written.
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 simple tool, it covers the core functionality but leaves gaps: the screenshot parameter is unexplained, the output format is not described, and no prerequisites (e.g., being on a page) are mentioned. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one boolean parameter 'screenshot' with no description, and the tool description never explains that this parameter controls whether a screenshot is saved. The agent must infer the meaning from the parameter name, which is a significant gap given 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns URL, title, and page text, and saves a screenshot, with a specific debugging purpose ('help adjust selectors when site layout changes'). This distinguishes it from sibling tools that handle navigation, login, or other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: when site layout changes and you need to adjust selectors. It implies when to use the tool but does not explicitly mention alternatives or exclusions, so a small gap remains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool 'returns' cart contents, implying a read-only operation, but it does not disclose authentication requirements, side effects, or error behavior. For a simple view tool this is acceptable but not comprehensive.
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?
The description is a single, concise sentence that covers the essential output details without any filler. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description is complete: it lists all return components (items, subtotal, delivery, total) despite lacking an output schema. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain. The baseline for zero parameters is 4, and the description correctly adds no param info since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the contents of the cart, listing specific elements (items with quantity/options, subtotal, delivery, total). This distinguishes it from sibling tools like add_to_cart, remove_from_cart, and clear_cart.
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 does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. However, its purpose as a cart viewer is self-evident given the sibling tool names, so the context is clear but not formally guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on full responsibility. It reveals that output is compact by default to fit large menus (200+ items), that `full: true` adds descriptions, and that items with `hasOptions` require option selection—all useful behavioral nuances beyond a simple read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences deliver a lot of information, but the second is a long run-on with embedded guidance. No superfluous words; the structure is front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains return organization (grouped by categories), default compactness, and the caveat about large menus. It omits explicit field details, but mentions `hasOptions` which is a key field. Given no output schema, it's reasonably complete for a menu retrieval tool.
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 already documents all three parameters with descriptions (100% coverage). The description adds a hint about restaurant input from search_restaurants and restates the effect of `full`, but doesn't substantially enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: returning the full restaurant menu grouped by categories. It distinguishes from siblings by specifying input from search_restaurants and mentioning the `hasOptions` behavior that connects to get_item_options/add_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use search_restaurants to obtain the restaurant URL/slug, warns against premature 'not found' conclusions until all categories are reviewed, and explains the `full: true` parameter and `hasOptions` requirement for adding items. However, it doesn't explicitly list alternative tools or when not 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It reveals that the browser window is visible, the session is saved to the profile, and the server runs headless afterward, which is valuable behavioral context beyond trivial statements.
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 concise sentences, each adding distinct value: the action performed, the session persistence, and the usage frequency. There is no redundancy or verbosity, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, side effects, and usage scenarios, which is sufficient for a tool with no parameters and no output schema. It could mention how to verify successful login (e.g., via login_status), but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides complete coverage. The description appropriately describes the parameterless action and its effect, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens a visible browser window for Yandex login and persists the session, which is a specific verb+resource. It distinguishes itself from sibling tools like login_status by describing the interactive login flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool is typically called automatically on first access and only needs to be run once per computer, giving clear context on when manual invocation is appropriate. It does not explicitly mention alternatives like login_status, but the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses the search priority for saved addresses, preservation of apartment/entrance/floor details, and fallback to map search. This goes beyond a generic 'set address' and gives agents valuable foresight into the tool's runtime behavior.
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?
The description is two sentences, directly front-loaded with the action. It uses capitalization for emphasis on key behaviors and contains no filler, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with two parameters and no output schema, the description is sufficient. It covers the main workflow, including the saved-address shortcut and fallback, without unnecessary details. It doesn't address errors or authentication, but those are not critical for this type of operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by elaborating the meaning of address as a label ('дом'/'работа') and how preferSaved controls the search-first behavior, plus the detail about not needing to re-click on the map when a saved address is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Устанавливает адрес доставки') and identifies the resource (delivery address). It distinguishes itself from sibling read tools like get_address and list_saved_addresses by describing a write operation with specific behavior around saved addresses, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: to set a delivery address, and explains the default behavior of first checking saved addresses and the fallback when none match. It doesn't explicitly list alternatives or exclusions, but the distinction from read-only siblings is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that required groups are marked `required: true` and explains how the tool fits into the ordering flow. It stops short of detailing error behavior or exact response structure, but offers solid 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and each sentence earns its place. No redundant or vague wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two simple parameters, no output schema, and no annotations, the description covers the essential aspects: what it returns, when to use it, and how to apply the result with add_to_cart. It is complete enough 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters (`item` and `restaurant`), so the schema already documents them. The description adds contextual usage (e.g., `hasOptions`) but does not deepen parameter-level meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns groups of required/optional dish options with variants and prices, using a specific verb and resource. It also gives examples (taste, size, side dish, additives) and distinguishes itself from siblings like get_menu and add_to_cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this for items with `hasOptions` before `add_to_cart`, which provides both a clear when and an implicit when-not (items without hasOptions). It also explains the workflow: show options to the user and pass them to add_to_cart via `options`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return content (saved addresses with labels and details) and its relationship to set_address. It does not describe error conditions or explicit read-only behavior, but the verb 'Возвращает' and the non-mutating nature of a list operation are sufficiently clear.
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?
The description is concise, consisting of two sentences with no fluff. The main verb and resource are front-loaded, and the second sentence adds valuable cross-tool integration context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and no output schema, the description fully covers what the tool does, what data it returns, and how it fits into the broader workflow (use with set_address). It is complete within its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter detail to explain. The baseline for no parameters is 4, and the description does not need to add parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it returns saved delivery addresses from the account, including labels and details. The verb 'Возвращает' and resource 'сохранённые адреса' are specific, and the mention of set_address distinguishes it from address-related siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it explains that returned addresses can be selected via set_address without re-entering them on the map. This implies when to use the tool (to retrieve saved addresses for later selection) but does not explicitly exclude alternatives like get_address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses the internal process: 'Сам открывает магазин с поиском товара, находит карточку по названию и жмёт «+»' – revealing that the tool performs UI automation. It also warns that name accuracy matters, adding context about potential failure if the name is too vague. However, it does not mention prerequisites like authentication or error handling, which would enhance transparency further.
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?
The description is three sentences long, with each sentence serving a distinct purpose: function, usage distinction, and process/input guidance. It is front-loaded with the core action and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, no output schema, no annotations), the description is largely complete. It covers the tool's purpose, differentiates from a sibling, explains the internal workflow, and advises on input sourcing. The main gaps are missing prerequisites (e.g., login state) and explicit behavior for invalid inputs, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers shop and product with descriptions, but the tool's description adds valuable guidance for the product parameter: 'Название бери из результатов search_products (чем точнее, тем лучше)' – clarifying the source and quality of the input. Quantity has no description in schema, but its default/min/max are self-explanatory; the tool description doesn't add to it. Overall, it improves understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Добавляет ТОВАР МАГАЗИНА (retail) в корзину' (adds store product to cart), explicitly distinguishing it from the sibling add_to_cart, which is for restaurants. The verb and resource are specific, and the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: 'для магазинов используй это, а НЕ add_to_cart (та только для ресторанов)' directly instructs when to use this tool over the alternative, and it advises to source product names from search_products results for best accuracy.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full responsibility for disclosing behavior. It explicitly states the safe dry-run default, the confirm flag for real orders, and the SBP limitation requiring card for auto-ordering. This is excellent transparency for a mutation tool.
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?
The description is concise and well-structured, front-loading the core purpose and critical default behavior. Each sentence adds unique value, with emphasis on important warnings via capitalization. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no output schema or annotations, the description covers the essential aspects: purpose, default behavior, confirmation flag, payment selection, and a crucial limitation. It doesn't mention return values or preconditions like cart non-empty, but the coverage is strong for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that confirm=false is a dry-run (reaching the pay button without confirming) and explaining the payment method caveat with SBP. This goes beyond the schema's basic type descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: places an order from the cart. It uses a specific verb and resource, distinguishing it from sibling tools like add_to_cart or view_cart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage: it explains the default dry-run behavior and how to make a real order via confirm=true. It also directs to list_payment_methods for payment selection. While it doesn't explicitly name alternative tools for when not to use this tool, the sibling context makes this clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the targeted one-item removal, the variant-specific removal via `options`, and the recommended sequence for changing an item. However, it does not specify failure behavior (e.g., what happens if the item is not found) or any side effects beyond the cart itself.
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?
The description is three sentences, front-loaded with the main action, and each sentence adds important context: scope, variant handling, and the change workflow. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must carry the contextual burden. It covers the operation, the options nuance, and the recommended workflow, but lacks explicit return-value or failure semantics. Given the simplicity of the tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of `options` in context (same dish with different options) and how it relates to the removal variant. This goes beyond the schema's individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'удаляет ОДНУ позицию из корзины по названию' and explicitly contrasts with clear_cart, which removes everything. This distinguishes it from siblings and gives a specific verb+resource+scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool versus clear_cart ('в отличие от clear_cart, который сносит всё') and provides the correct workflow for changing an item ('remove_from_cart нужный вариант → add_to_cart с новыми опциями'). It also instructs when to use the `options` parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (checking authorization) and provides actionable guidance if not authorized. It does not specify the return format, but for a simple read-only status check, this is adequate.
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?
The description is two sentences, front-loaded with the purpose and immediately followed by a conditional action. No wasted words; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully self-contained for a tool of this simplicity. It covers the main function and the necessary follow-up action, making it complete even without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter semantics. The baseline of 4 applies as there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether the current browser profile is authorized in Yandex, using a specific verb and resource. It distinguishes itself from the sibling 'login' tool by focusing on status verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call the 'login' tool when the profile is not authorized, providing a clear conditional and alternative. This tells the agent exactly when to use this tool and what to do instead when the condition is met.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description compensates fully by disclosing lazy menu loading/auto-scrolling, blocking of add button without required options, and inability to edit options after adding. This goes well beyond the schema and gives important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but every sentence carries essential operational information. It is front-loaded with the core action and then covers alternatives and edge cases without redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and complex interactive behavior, the description fully covers prerequisites, sequencing, lazy loading, option constraints, and the workaround for editing options. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover item and options, and the description adds key semantics: item must match get_menu and options must exactly match get_item_options values. Quantity is not described in either schema or description beyond numeric constraints, so a small gap remains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a restaurant dish to the cart by name, explicitly contrasting with add_product for shop items. It differentiates from sibling tools and specifies the resource (restaurant dish) and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use and when-not-to-use guidance: first call get_menu, use add_product for shop goods, call get_item_options before adding if hasOptions, and remove/re-add to change options. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
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 disclosure. It explicitly states the destructive nature (clears all items and all carts) and explains that Yandex Eda does not allow editing cart options, which sets expectations for the replacement workflow. This is rich behavioral context beyond simple read/write.
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?
Two sentences, front-loaded with the primary action (clearing the cart) followed by usage alternatives. Every sentence adds crucial information without fluff or redundancy. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less, no-output-schema destructive operation, the description fully covers purpose, scope, and usage alternatives. It also explains a platform limitation (no option editing) that affects how the tool should be used, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema trivially covers all of them. Per the baseline rule, a score of 4 is appropriate for zero-parameter tools. The description adds meaningful context about the scope (all items and all carts), which is valuable even without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Полностью очищает корзину (ВСЕ позиции и все корзины)' – a specific verb and scope. It distinguishes itself from remove_from_cart by indicating it clears all items, not just one, and clarifies that this tool clears all carts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to use remove_from_cart when only one item needs changing, and provides a workflow for changing options: remove_from_cart (or clear_cart if only one item) followed by add_to_cart. This gives concrete when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It reveals the cart requirement, the checkout-screen visibility, and a critical caveat that SBP won't auto-complete. This is rich behavioral context beyond a simple 'list' tool, effectively warning agents about a potential failure mode.
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 sentences, each earning its place: purpose, prerequisite, and a crucial warning. Front-loaded with the primary action. No filler, no redundancy. The structure aids quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no params and no output schema, the description is fully sufficient. It covers what it returns, when it is usable, and why a specific payment method might fail. It also references a sibling tool (place_order) for the payment parameter, providing necessary integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is an empty object. Per guidelines, baseline is 4 for zero params. The description doesn't need to elaborate on non-existent parameters, though it adds useful output context (available methods and selected one), which is a minor bonus beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Shows available payment methods (cards, Card Pay, SBP) and the currently selected one.' The verb 'shows' and specific resource ('payment methods') distinguish it from siblings. It also notes the prerequisite of a non-empty cart, adding clarity about when the tool is relevant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when it can be used: 'A NON-EMPTY cart is required (methods are visible only on the checkout screen).' Provides an important exclusion: SBP requires manual confirmation and will not auto-process; directs users to choose card/Card Pay for auto-ordering via the 'payment' parameter in place_order. This gives clear guidance on when to use the tool and what to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It discloses return fields (price, promoPrice, weight, inStock), prerequisites (a set address, shop specified by name), and the tool's non-destructive nature implicitly. It also clarifies behavioral nuances like the category listing fallback and the need for a specific tool for cart actions.
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?
The description is dense but well-structured with bullet points for modes, making it easy to scan. Every sentence contributes unique value: mode definitions, return fields, related tool guidance, and prerequisites. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers all essential aspects: return values, prerequisites, alternative tools, and usage modes. It is sufficiently complete for an agent to select and invoke the tool correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, and the description adds meaning beyond the schema by explaining the interaction of query and category: omitting both lists categories, query searches, category browses. It also clarifies the shop parameter ('Магазин задаётся именем'). The limit parameter is not mentioned, but schema provides min/max/default, so this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching products in a store ('поиск товаров по запросу') and browsing by category, explicitly distinguishing it from restaurant menus. It names concrete use cases and differentiates from siblings like get_menu and add_product.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it explains the three modes (no query/category = category list, query = product search, category = category items), states this is the main path for 'add X from store', and directs users to add_product rather than add_to_cart. It also notes the requirement of a set address.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses default open-only behavior, that closed venues are hidden, warns not to propose or add to cart closed venues, and that set_address is required. Delivery price is noted as conditional ('if recognized').
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?
Well-structured with a clear purpose sentence followed by scannable bullets. Every bullet conveys a distinct, important guideline; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers all critical behaviors: return contents, query logic, type filtering, open/closed defaults, includeClosed option, and prerequisite address. It is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (limit lacks description), but the description adds significant meaning: query empty vs filled, type restaurant/shop defaults, and includeClosed toggle behavior. These go well beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool returns establishments delivering to the current address, with rating and delivery time. This specific verb+resource+scope distinguishes it from siblings like search_products and get_menu.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Bullet points give explicit when-to-use guidance: omit query for general catalog, use query only for specific searches, use type to separate restaurants/shops, and require set_address. It also warns against inventing keywords and against interacting with closed venues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![yandex-eda-mcp MCP server](https://glama.ai/mcp/servers/sandexplus/yandex-eda-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandexplus/yandex-eda-mcp)

Score Badge

Copy to your README.md:

[![yandex-eda-mcp MCP server](https://glama.ai/mcp/servers/sandexplus/yandex-eda-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandexplus/yandex-eda-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandexplus/yandex-eda-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server