Skip to main content
Glama
Rezlazy

yandex-metrika-mcp

by Rezlazy

mgmt_grant_create

Create a grant to give a user view or edit access to a Yandex Metrika counter by specifying login and permission level.

Instructions

https://yandex.ru/dev/metrika/ru/management/ Create grant. Body: {"grant": {"user_login": "...", "perm": "view"}}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesJSON request body. For POST/PUT use the structure from API docs (e.g. {"counter": {...}}).
prettyNoPretty-print response (1)
counterIdYesCounter ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

B3.1/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the behavioral burden. It discloses only that this creates a grant and shows a body shape; it does not mention required permissions, whether existing grants are replaced or merged, or what the response contains.

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 compact and contains no filler, combining a docs URL, the action, and a body example in two sentences. It would be slightly better front-loaded if the action appeared before the URL, but overall structure is 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?

Given the lack of annotations and output schema, the description still makes basic invocation understandable through the body example and docs link. However, it omits behavioral details such as response semantics, permission requirements, and how this endpoint relates to the public-grant and update variants.

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 all parameters, but the body parameter is generic and underspecified. The description adds real meaning by providing the exact JSON structure {"grant": {"user_login": "...", "perm": "view"}}, which is valuable for correct invocation.

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

Purpose4/5

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

The description states a clear action ('Create grant') and identifies the resource via the body example with user_login and perm. It does not explicitly distinguish this from sibling endpoints like mgmt_public_grant_create or mgmt_grant_update.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus related grant tools, nor any exclusions or alternative-endpoint hints. The word 'Create' implies basic usage, but the many sibling grant endpoints make the lack of explicit routing a real gap.

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