Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@yandex-eats-mcp show my order history for yesterday"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for the Yandex Eats Vendor Management API.
Lets AI agents (Cursor, Claude Desktop, and other MCP hosts) manage partner operations: orders history/details, busy mode, place blocks, menu import, courier code validation, and feedback replies.
This wraps the push Vendor Management API (
https://dc-partner.eda.yandex.net). It is not a consumer ordering API.
{
"mcpServers": {
"yandex-eats": {
"command": "npx",
"args": ["-y", "yandex-eats-mcp"],
"env": {
"YANDEX_EATS_CLIENT_ID": "your-client-id",
"YANDEX_EATS_CLIENT_SECRET": "your-client-secret",
"YANDEX_EATS_PARTNER_NAME": "your-partner-name"
}
}
}
}Pin a version: "args": ["-y", "yandex-eats-mcp@0.1.0"].
npm install
npm run build
npm startMCP config pointing at a local build:
{
"mcpServers": {
"yandex-eats": {
"command": "node",
"args": ["/absolute/path/to/yandex-eats-mcp/dist/index.js"],
"env": {
"YANDEX_EATS_CLIENT_ID": "...",
"YANDEX_EATS_CLIENT_SECRET": "...",
"YANDEX_EATS_PARTNER_NAME": "..."
}
}
}
}Related MCP server: Yandex Delivery MCP
Variable | Required | Description |
| yes | OAuth client id |
| yes | OAuth client secret |
| for several write tools | Sent as |
| no | Default |
| no | Default |
| no | If |
Credentials are never accepted as tool arguments. Access tokens are never returned to the agent.
Tool | Description |
| Credential / token cache status (no token value) |
| Force OAuth refresh |
| Order history (max 1000; 180 days) |
| Details by |
| High-demand places |
| Current blocks |
| Block places ( |
| Unblock places ( |
| Force menu / stop-list import |
| Validate courier pickup code |
| Reply to feedback (may need subscription) |
yandex-eats://docs/overview
yandex-eats://config/status
yandex_eats_investigate_order
yandex_eats_resync_menu
# Unit + MCP integration (mocked Vendor API, in-memory transport)
npm test
# E2E: spawn dist/index.js over stdio (builds first). Live API smoke only if
# YANDEX_EATS_LIVE_E2E=1 and real CLIENT_ID/SECRET are set.
npm run test:e2e
npm run test:allSuite | Path | Network |
Unit |
| mocked |
Integration |
| mocked Vendor API + real MCP protocol (in-memory) |
E2E stdio |
| dry-run MCP child process |
E2E live |
| real Yandex (opt-in) |
npm test && npm run build
npm pack --dry-run
npm publishRequires an npm account with publish rights for yandex-eats-mcp.
docs/YANDEX_EATS_API.md — API research
docs/MCP_SERVER_PLAN.md — implementation plan
MIT
Check whether Yandex Eats Vendor Management credentials are configured and whether a cached OAuth token is valid. Never returns the access token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the behavioral disclosure burden. It states that the tool checks configuration and token validity, and explicitly warns that it never returns the access token, which is a critical security detail.
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 concise sentences with no filler. The key information is front-loaded and every word adds value.
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's simplicity (no parameters, no output schema), the description is complete. It explains the purpose, what is checked, and what is not returned, leaving no ambiguity.
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?
Since there are no parameters, the description does not need to add parameter details. The schema already covers everything (100% coverage by default).
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 specifies the exact action (check credentials and token validity) and resource (Yandex Eats Vendor Management auth). It clearly distinguishes from sibling tools like refresh_token or orders by focusing on status only.
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 is implied as a prerequisite check before API calls, but no explicit when-to-use/when-not-to-use guidance or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Block restaurant(s) in Yandex Eats (POST /block). Destructive. Requires confirm=true and Partner-Name. Tags: technical_problem | too_busy. If 'to' is omitted, block is indefinite.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Block end datetime; omit for indefinite | |
| tag | Yes | ||
| from | Yes | Block start datetime | |
| confirm | Yes | Must be true to execute this destructive action | |
| message | No | Reason shown for the block | |
| vendorInfo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'Destructive', requires confirm=true and Partner-Name header, and explains indefinite block when 'to' omitted. No annotations provided, so description carries full burden and does well.
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 pack purpose, endpoint, destructive warning, required items, tags, and indefinite behavior with no filler. Well front-loaded and every word earns its place.
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?
Covers key behavioral aspects and requirements, but lacks details on success response, scope (all delivery types), and links to related tools (e.g., block_status). Still adequate given no output schema.
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 covers parameters descriptively (67% coverage), but description adds crucial info: Partner-Name header (not in schema) and clarifies indefinite block for 'to' (partially redundant). Overall adds meaningful value 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?
Clearly states 'Block restaurant(s) in Yandex Eats (POST /block)', providing a specific verb and resource. The sibling tool 'unblock_places' indicates differentiation, though not explicitly mentioned.
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?
Provides context: destructive action, required confirm=true, Partner-Name header, allowable tags, and indefinite behavior if 'to' omitted. However, lacks explicit when-not-to-use or comparison to alternative tools like 'unblock_places'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get restaurant block status from Vendor Management (POST /v2/status). Requires Partner-Name.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No | ||
| statuses | No | ||
| vendorInfo | Yes | ||
| include_pii | No | If true, keep phone numbers and client names in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions a POST endpoint, which may suggest a write operation, yet the tool is named 'block_status' implying a read. No details on side effects, rate limits, or authorization beyond Partner-Name.
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 with two short sentences. No unnecessary information. However, it could be slightly expanded to include parameter guidance without losing conciseness.
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?
The description lacks details about the response format (no output schema), how to use the parameters effectively, and what 'block status' entails. Given the complexity of 5 parameters and no output schema, more information is needed.
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 only 20% (vendorInfo fields have descriptions). The tool description adds no explanation of parameters, such as limit, offset, statuses, or include_pii. The mention of 'Requires Partner-Name' does not correspond to any parameter in the 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?
The description clearly states the action ('Get') and the resource ('restaurant block status'), and includes the API endpoint and a requirement. However, it does not differentiate from sibling tools like yandex_eats_block_places, which could cause confusion.
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?
No guidance on when to use this tool versus alternatives such as yandex_eats_block_places or yandex_eats_unblock_places. The only prerequisite mentioned is 'Requires Partner-Name', but no context on typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List restaurants with active high-demand (busy) status (POST /partner-integration/v1/place-info/v1/busy-mode-status). High demand adds extra cooking minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size (max 500) | |
| cursor | No | Pagination cursor | |
| service | No | ||
| origin_ids | No | Partner restaurant IDs | |
| include_pii | No | If true, keep phone numbers and client names in the response | |
| delivery_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It mentions that high demand adds extra cooking minutes but does not disclose authentication needs, rate limits, potential side effects, or that the endpoint uses POST for a listing operation.
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 two sentences, front-loading the purpose and endpoint with no redundant information. Every word earns its place.
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 lack of output schema and annotations, the description is insufficient. It does not explain pagination (cursor), response format, or how the busy mode status is determined.
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 67%, so baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter usage or relationships.
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 verb 'List', the resource 'restaurants with active high-demand (busy) status', and includes the endpoint. It is specific and distinct from sibling tools.
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?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reply to customer order feedback with text and optional promo percent (POST /feedback-answer). Subscription-gated — may return 403 without subscription. Promo values: 10, 15, 20, 30, 40.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Reply text | |
| promo | No | Optional percent promo code | |
| order_nr | No | Optional Yandex order number DDDDDD-DDDDDDDD | |
| feedback_id | Yes | Feedback ID to answer |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the subscription gate and allowed promo values but does not mention rate limits, idempotency, or response behavior. The provided info is adequate but not comprehensive 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: one stating the action and parameters, another covering subscription and promo values. Every sentence adds value with no redundancy, ideal for quick parsing.
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's simplicity (4 parameters, no output schema), the description covers the core purpose, subscription gating, and allowed promo values. It lacks return value info but is otherwise complete. Minor gap prevents a 5.
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 100% and already describes all parameters. The description adds minimal value by summarizing 'with text and optional promo percent' and listing promo values, but these are also in the schema. Baseline 3 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 the action 'Reply to customer order feedback' and specifies the resource (customer order feedback) and parameters (text, optional promo percent). It uniquely distinguishes from sibling tools which cover auth, orders, busy mode, etc.
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 context about the subscription requirement ('Subscription-gated — may return 403 without subscription') and lists allowed promo values. However, it does not include when-not-to-use or alternatives, though no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch detailed information for orders by Yandex eats_id list (POST /v1/get-orders-details). Max 100 ids per request; history retained 180 days. eats_id format: DDDDDD-DDDDDDDD.
| Name | Required | Description | Default |
|---|---|---|---|
| eats_ids | Yes | Yandex order numbers, e.g. 230328-354380 | |
| include_pii | No | If true, keep phone numbers and client names in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry the burden. It discloses max batch size, retention period, ID format, and the effect of include_pii. However, it doesn't mention error handling, rate limits, or confirm read-only nature.
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, no fluff. Purpose is front-loaded, and the key constraints (max IDs, retention, format) are efficiently stated.
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; description mentions 'detailed information' but doesn't specify response fields beyond the PII control. Could elaborate on what details are returned (e.g., status, cost). Schema covers all inputs, but output is undefined.
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 100% with descriptions for both parameters. The description adds the ID format ('DDDDDD-DDDDDDDD'), which complements the schema's example. But otherwise, it largely repeats schema information, so baseline 3 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 'Fetch detailed information for orders' with a specific verb and resource, and mentions the HTTP endpoint. While it doesn't explicitly differentiate from siblings like yandex_eats_orders_history, the focus on details by ID list distinguishes it implicitly.
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?
Provides batch size limit (100 IDs) and data retention (180 days) but does not specify when to use this tool versus alternatives (e.g., yandex_eats_orders_history for listing). No explicit 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.
Fetch order history from Vendor Management (POST /v1/orders-history). Limits: max 1000 orders in the response; history retained for the last 180 days. Status filter values are NEW, CANCELLED, DELIVERED.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | End datetime RFC3339 | |
| from | Yes | Start datetime RFC3339, e.g. 2024-01-01T12:00:05.125+03:00 | |
| limit | No | Max orders (default API limit applies) | |
| offset | No | Pagination offset | |
| status | No | Optional status filter | |
| service | No | YE = Yandex Eats, MD = other service | |
| origin_ids | Yes | Restaurants to query | |
| include_pii | No | If true, keep phone numbers and client names in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important constraints (max 1000 orders, 180-day retention) and the HTTP method. Without annotations, it covers key behavioral aspects but omits authentication or rate limit details.
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 succinct sentences: purpose, limits, filter values. No unnecessary 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?
Covers key usage aspects but does not explain pagination (offset), result format, or the fact that origin_ids, from, to are required (though schema shows required).
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 100%, so baseline is 3. The description adds the 180-day retention limit but otherwise reiterates schema info on status and limit.
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?
Clearly states it fetches order history from Vendor Management, specifies the endpoint, and distinguishes from sibling tools (e.g., orders_details) by its scope.
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?
Provides limits and status filter values but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Force-refresh the OAuth2 client-credentials token from POST /oauth2/token on dc-partner.eda.yandex.net. Does not return the token.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 that the tool does not return the token, which is a key behavioral detail. However, it omits other relevant behaviors like side effects (e.g., token persistence), error conditions, or prerequisite state (e.g., needing an existing token).
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 extremely concise with two short sentences. It front-loads the action and endpoint, and every word adds value. No unnecessary information.
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 simple tool with no parameters, no annotations, and no output schema, the description covers the essential aspects: what it does, where it does it, and what it returns (nothing). It is complete enough for the agent to understand the core behavior, though adding usage context would further improve completeness.
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 tool has zero parameters, and the input schema is fully covered (100%). The description appropriately doesn't add parameter details, and with no parameters, a baseline of 4 is justified. It correctly avoids redundant documentation.
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 action (force-refresh), the resource (OAuth2 client-credentials token), and the specific endpoint (POST /oauth2/token on dc-partner.eda.yandex.net). It unambiguously identifies the tool's purpose and distinguishes it from siblings like yandex_eats_auth_status.
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 does not provide guidance on when to use this tool versus alternatives, such as indicating it should be used when the token expires or requires renewal. It lacks context for appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unblock restaurant(s) (POST /unblock). Destructive. Requires confirm=true, Partner-Name, and blockIds from a prior block/status response.
| Name | Required | Description | Default |
|---|---|---|---|
| confirm | Yes | Must be true to execute this destructive action | |
| blockIds | Yes | Block IDs to remove | |
| vendorInfo | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It labels the tool as 'Destructive' and lists required fields, including a header (Partner-Name) not in the schema. This provides essential behavioral context 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences convey the purpose, endpoint, destructiveness, and requirements with zero redundancy. Every sentence is informative 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?
For a destructive tool with no output schema, the description covers the key context: it is destructive, requires confirm and prior block IDs, and mentions a required header. It lacks details about error responses or side effects, but is adequate given the tool's simplicity.
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 67% (2 of 3 parameters described). The description adds value by mentioning 'Partner-Name' (a header not in schema) and reiterating that confirm must be true. It compensates for the coverage gap and clarifies parameter usage beyond the 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?
The description clearly states 'Unblock restaurant(s) (POST /unblock)', specifying the action and resource. It is easily distinguishable from the sibling 'yandex_eats_block_places' which performs the opposite operation.
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 indicates prerequisites: 'Requires confirm=true, Partner-Name, and blockIds from a prior block/status response.' This tells the agent when to use it (after a block action) and what inputs are necessary, though alternatives are not explicitly mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate the courier pickup code for an order (POST /platform/orders/{orderId}/codes/validate). Requires Partner-Name. Sensitive operational tool.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes | Courier pickup code to validate | |
| orderId | Yes | Order ID used in the path (partner or platform id as required by Yandex) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds endpoint and sensitivity, but fails to disclose behavioral traits like side effects, response format, or error handling for this POST validation endpoint.
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, no wasted words. Front-loaded with purpose, followed by prerequisite and sensitivity.
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. Lacks details on what the response indicates (valid/invalid), whether state changes, or rate limits. For a sensitive operational tool, more completeness is needed.
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%. Description does not add significant meaning beyond schema's parameter descriptions.
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?
Clearly states action (validate), resource (courier pickup code for an order), and includes the HTTP method and endpoint. Distinct from sibling tools.
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?
Mentions prerequisite (Requires Partner-Name) and sensitivity, but lacks explicit guidance on when to use vs alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0yandex_eats_auth_statusyandex_eats_block_placesyandex_eats_block_statusyandex_eats_busy_mode_statusyandex_eats_feedback_answeryandex_eats_menu_importyandex_eats_orders_detailsyandex_eats_orders_historyyandex_eats_refresh_tokenyandex_eats_unblock_placesyandex_eats_validate_courier_codeEvery tool has a clearly distinct purpose: auth management, order history versus details, restaurant block versus busy mode, menu import, courier validation, and feedback. No two tools overlap in functionality.
All tools follow the consistent prefix 'yandex_eats_' and use a clear verb_noun pattern (e.g., refresh_token, block_places, validate_courier_code). Naming is predictable and uniform.
With 11 tools, the server is well-scoped for managing Yandex Eats vendor operations. The count covers essential actions without being overwhelming or too sparse.
The tool set covers core vendor workflows (auth, orders, block/unblock, menu import, feedback) but lacks tools for listing all restaurants, getting restaurant details beyond block status, or managing menu items individually. Some operations require workarounds.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server enabling AI agents to manage Bitrix24 features via standardized protocol
MCP server for building and testing AI agents with multi-model experimentation and insights.
The Mercado Pago MCP Server implements the Model Context Protocol to provide AI agents and LLMs with access to Mercado Pago's APIs and tools within compatible development environments. It acts as an intermediary that translates Mercado Pago resources into executable functions (tools) that AI applications can invoke to perform actions and automate flows. The server simplifies integration, enables using documentation to implement or improve code, and optimizes operations through natural language interactions without manual implementations.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/yasmanmesa/yandex-eats-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
