Yandex Direct MCP Server

by OlegRadinuk

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation5/5
Each tool targets a distinct resource or action (campaigns, ad groups, ads, keywords, negative keywords, reports, balance). No two tools overlap in purpose; for example, 'add_campaigns' and 'add_ad_groups' clearly operate on different objects.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_campaigns, list_ads, set_keyword_bids). The verbs are descriptive and uniform across similar operations like add, list, update, delete.
Tool Count4/5
21 tools cover the main advertising lifecycle (campaigns, ad groups, ads, keywords, negative keywords, reports, balance). While slightly above the typical 3-15 range, the count is justified by the domain complexity and the inclusion of dedicated tools for negative keywords and bid setting.
Completeness4/5
The tool set covers CRUD for campaigns, ad groups, ads, and keywords, plus moderation, reporting, and balance. Obvious gaps like standalone ad extension management (sitelinks, vcards) are partially handled inside add_ads, but separate tools are missing. Overall, it covers core workflows well.
Average 4.3/5 across 21 of 21 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
No annotations provided. Description implies a read operation but doesn't disclose side effects, authentication needs, or rate limits. Basic transparency with no contradictions.
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?
Single sentence, no wasted words. Efficiently communicates purpose.
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?
Simple tool with no parameters and no output schema. Description is adequate but vague on 'key financial info'. Could be more complete for an 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?
Tool has no parameters, and schema coverage is 100%. Description adds no parameter meaning, but baseline for zero parameters is 4.
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?
Description clearly states the tool returns current account balance and key financial info. It's specific but lacks detail on what 'key financial info' includes. No direct sibling conflict, but 'get_report' might overlap.
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?
No guidance on when to use this tool versus alternatives like 'get_report'. Missing context on prerequisites or scenarios.
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?
With no annotations, the description must disclose behavioral traits. It correctly implies a read-only operation ('list'), but lacks detail on permissions, rate limits, or side effects. While the behavior is straightforward, additional transparency (e.g., 'This is a read-only operation') would improve the score.
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 concise sentences, front-loaded with purpose. No extraneous information. Every word earns its place.
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 listing tool without an output schema, the description is mostly adequate. However, it lacks information about what is returned (e.g., ad group details) and assumes the agent knows the response format. More context on the output would make it complete.
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 description coverage is 0%, so the description must explain parameters fully. It does so: 'campaign_ids: One or more campaign IDs' and 'limit: Max results (1–10000).' This adds meaning beyond the schema's type-only definitions, including the valid range for limit.
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: 'List ad groups for the given campaign IDs.' This specific verb+resource combination (list + ad groups) effectively distinguishes it from sibling tools like add_ad_groups, delete_ads, etc.
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?
No usage guidelines are provided. The description does not indicate when to use this tool over alternatives, nor does it mention any prerequisites, exclusions, or context for choosing list_ad_groups over other list or mutation tools.
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 must fully disclose behavior. It reveals the mutation action and dry-run capability, but fails to mention side effects, reversibility, required permissions, or any other behavioral details. This is insufficient for a mutating 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 extremely concise, using two short sentences and a bullet-style args list. Every word serves a purpose with no redundancy or filler.
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 simplicity, the description covers the main aspects: what it does, how to use it, and the confirm param's behavior. It is complete enough for a straightforward suspension action, though it could mention return value or constraints.
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 description coverage is 0%, but the description compensates by clearly explaining each parameter: campaign_ids is a list of IDs, and confirm controls dry-run vs actual suspension. This adds significant meaning beyond the schema's type and default.
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 verb 'Pause (suspend)' and the resource 'one or more campaigns.' It distinguishes from sibling tools like archive_campaigns and resume_campaigns by using 'suspend' and mentioning a dry-run mode.
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 provides useful guidance on the confirm parameter (dry-run vs actual action). However, it does not explicitly state when to use this tool versus alternatives like archive_campaigns or resume_campaigns, nor does it mention prerequisites or constraints.
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 full burden. It discloses the MICROS unit for bids and the dry-run mechanism via 'confirm'. However, it does not mention destructive nature, permissions, rate limits, or side effects beyond the update action.
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 reasonably concise and structured with bullet points for clarity. However, it includes redundant formatting like 'Args:' and could be more streamlined.
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 no output schema or annotations, the description covers the core mutation behavior and parameter details. However, it omits return value information (e.g., success status or updated objects) and does not address potential side effects or error conditions.
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?
With 0% schema description coverage, the description adds substantial meaning: it lists the expected fields (Id, Keyword, Bid, ContextBid, UserParam1, UserParam2) and their types/roles. It misses clarifying that additional properties are allowed (schema 'additionalProperties: true'), but otherwise compensates well.
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 'Update keyword text or bids,' specifying the verb and resource. It distinguishes from sibling tools like 'add_keywords', 'delete_keywords', and 'set_keyword_bids' by focusing on updating existing keywords. The scope is explicit.
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 explains how to use the tool, including the 'confirm' parameter for dry-run planning. However, it does not provide guidance on when to use this tool versus alternatives like 'set_keyword_bids' or specify prerequisites or exclusions.
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?
The description discloses that bids are in MICROS, a useful behavioral detail. With no annotations, more disclosure about side effects, permissions, or read-only nature would be beneficial.
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, structured with Args section and a note. Every sentence adds value with no unnecessary text.
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 adequately covers input parameters and a critical behavioral note. While it lacks output details, the tool has no output schema, making this acceptable for basic completeness.
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?
Despite 0% schema description coverage, the description explains each parameter's purpose and the requirement of at least one filter, adding significant value 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 lists keywords with current bids, using a specific verb and resource. It distinguishes from sibling tools like add_keywords, delete_keywords, and set_keyword_bids.
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 indicates that at least one filter is required, providing a condition for use. However, it does not explicitly state when to use this tool versus alternatives or exclude other contexts.
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?
With no annotations, the description carries full behavioral burden. It discloses it is a read operation and lists return fields, but omits potential error cases, rate limits, or required permissions. Adequate but not rich.
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 very concise: purpose sentence, an Args section with clear explanations, and a Returns line. Nothing superfluous, and 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?
Given the simple listing nature with no output schema, the description is mostly complete, covering parameters and return fields. It lacks error handling details but is sufficient for agent use.
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 has 0% description coverage, so the description fully compensates. It explains limit range (1-10000), filter values for states and types with examples, adding substantial meaning beyond the schema definition.
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 'List advertising campaigns on the connected account,' using a specific verb and resource. It distinguishes itself from sibling tools like add_campaigns or archive_campaigns, which perform different actions.
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 implies usage through parameter explanations but does not explicitly state when to use this tool versus alternatives like list_ad_groups. No 'when not to use' or references to other tools for similar tasks.
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?
Despite no annotations, the description discloses critical behaviors: the confirm parameter for dry-run vs. actual creation, the money note about micros, and the detailed bidding strategy options. However, it does not mention error handling, permissions, or whether creation is asynchronous, which are minor gaps.
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 front-loaded with a clear one-sentence purpose, then structured into args with examples and a money note. While somewhat lengthy due to the bidding strategy details, each part is necessary for correct usage; however, minor redundancy (e.g., repeating 'required' multiple times) could be trimmed.
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 complexity (2 parameters, no output schema, no annotations), the description covers campaign structure, confirm behavior, and micros. It lacks an explanation of the return value or error scenarios, but the dry-run mention partially addresses output. Overall, it is comprehensive enough 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?
With 0% schema coverage, the description fully compensates by detailing every field of the `campaigns` array parameter: required fields (Name, StartDate), optional fields (EndDate, DailyBudget, NegativeKeywords), and the complex TextCampaign structure with multiple bidding strategy examples. This adds immense value beyond the bare 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 starts with 'Create one or more TEXT_CAMPAIGN campaigns,' which clearly specifies the action (create), the resource (campaigns), and the specific type (TEXT_CAMPAIGN). This distinguishes it from siblings like add_ad_groups or add_ads, making the tool's purpose immediately clear.
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 implicitly indicates usage for creation, but lacks explicit guidance on when to prefer this tool over alternatives like update_campaigns or when not to use it (e.g., for non-TEXT_CAMPAIGN types). No exclusions or context are provided for deciding between siblings.
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 discloses the filtering behavior and parameter requirements but does not mention pagination, ordering, return format, or behavior when both filters are used (likely OR). Basic transparency is adequate but lacks depth.
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, using a clear bullet-like format for parameters. Each sentence is informative 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?
Considering the lack of an output schema, the description covers the essential usage: parameters, required filters, and possible state values. However, it omits details like pagination, default limit (though schema has it), and error cases. Fairly complete for a list tool.
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?
With 0% schema description coverage, the description compensates well. It explains each parameter with additional context: 'preferred for precision' for ad_group_ids, and lists enum values for states. This adds meaning beyond the schema's type and title fields.
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 verb 'List' and the resource 'ads' with filtering by ad groups or campaigns. It distinguishes from sibling tools like 'add_ads', 'delete_ads', and 'update_ads' by focusing on listing.
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 explicit guidance: it notes that ad_group_ids are preferred for precision and states the requirement that at least one of ad_group_ids or campaign_ids must be provided. However, it does not explicitly contrast with other list tools or specify 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 provided, the description carries full burden. It discloses that ads enter DRAFT status after creation and require moderation. The confirm parameter's behavior (dry-run vs execution) is explained. Max character limits for fields are stated. No contradictions with annotations (none present).
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 well-structured with a clear purpose, bullet-pointed args, and tips. It is somewhat long but each sentence adds value. Could be slightly more concise, but given the complexity of nested ad objects, the length is justified.
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?
The description covers parameter details and usage workflow well, but misses the return value (e.g., what is returned on success? List of ad IDs?). No output schema exists, so the description should mention this. Error handling or prerequisites (like existence of ad groups) are not covered. Otherwise, it's fairly complete.
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 0%, so the description must explain both parameters. The ads parameter is detailed with required fields (AdGroupId, TextAd dict) and optional fields with constraints (max lengths, defaults). The confirm parameter is described as controlling execution vs dry-run. This adds significant meaning beyond the input 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 starts with 'Create text ads in ad groups', which clearly states the verb (create) and resource (text ads in ad groups). This distinguishes it from sibling tools like add_ad_groups (which creates groups) and update_ads (which modifies existing ads).
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 about post-creation workflow (ads go to DRAFT status and need moderation via moderate_ads). It also suggests creating 2-3 ads per group for A/B testing. However, it does not explicitly state when not to use this tool or compare it with alternatives like add_keywords.
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 provided, so the description carries full burden. It discloses that bids are in micros, explains keyword syntax, and mentions the dry-run mode. It does not cover rate limits, auth, or error handling, but the core behavioral traits are well documented.
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 well-structured with a clear purpose, argument breakdown, and money note. While comprehensive, it is not overly verbose; every sentence serves a purpose. Slightly long due to necessary detail, but not wasteful.
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 no output schema, the description lacks information on return values, success indicators, or error handling. While parameter details are thorough, the omission of output behavior makes it incomplete for a full understanding.
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 0%, so the description must compensate. It thoroughly explains each field within the keyword objects, including required fields, syntax rules, and the critical unit micros for bids, adding immense value 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 'Add keywords to ad groups' using a specific verb and resource. It distinguishes itself from siblings like 'add_negative_keywords' and 'update_keywords'.
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 the dry-run behavior via the confirm parameter and details keyword syntax options. However, it does not explicitly state when to use this tool versus alternatives like add_negative_keywords or update_keywords, leaving some ambiguity.
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 is the sole source of behavioral info. It discloses the dry-run capability via confirm=False, which is good, but does not mention permissions, reversibility, side effects of omitting fields, or rate limits. The description does not contradict annotations (none present).
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 paragraphs: a one-line overview followed by a structured args list. It uses clear formatting, a money note for micros, and no filler sentences. Every sentence adds value.
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 thoroughly covers input parameters, but does not describe return values or output format since no output schema is provided. For a complex update tool, the omission of output details is a minor gap. Otherwise, context is complete.
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?
The input schema only defines campaigns as an array of objects and confirm as boolean with no nested details. The description provides full semantics for the nested fields: Id (required), Name, EndDate, DailyBudget, NegativeKeywords, and TextCampaign, including formats and examples. This compensates for the 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 starts with 'Update campaign settings' which clearly states the verb and resource. It lists specific fields (name, dates, budget, negative keywords, strategy), distinguishing it from sibling tools like add_campaigns, archive_campaigns, resume_campaigns, and suspend_campaigns.
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 indicates when to use the confirm parameter (True to execute, False for dry-run). However, it does not explicitly state when to use this tool vs alternatives (e.g., add_campaigns) or when not to use it. The absence of exclusions prevents a score of 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?
Discloses key behaviors: status requirement, dry-run mode via confirm parameter, and outcome (ON status after approval). No annotations exist, so description carries full burden and covers it well.
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?
Concise with clear sections, but 'Args' block slightly redundant with schema. Still efficient and front-loaded with key info.
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 no output schema and no annotations, description covers prerequisites, parameter details, and outcome. Missing potential error handling but sufficient for tool complexity.
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?
Adds essential meaning beyond schema: explains ad_ids as 'List of ad IDs' and confirm as toggle between dry-run and actual submission. Schema has 0% coverage, so description compensates fully.
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 'Submit ads for moderation review by Yandex' with a specific verb and resource, distinguishing from sibling tools like add_ads, delete_ads.
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?
Explicitly mentions required ad status (DRAFT or REJECTED) and expected timing, providing context for when to use this tool, but does not directly compare to alternatives.
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 burden. It clearly explains the dry-run capability and constraints on required fields. It does not mention permissions, rate limits, or side effects, but it is transparent about the create operation and parameter roles.
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 well-structured with a clear title and a bullet-like Args section. Each sentence provides essential information without redundancy. It is concise yet thorough.
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 the complex nested object array for ad_groups, required fields, and optional fields with region ID examples. It lacks details on error handling or existence checks but is complete for a creation tool given no output schema.
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 0% with no descriptions in the schema. The description adds comprehensive parameter details: Name, CampaignId, RegionIds (with examples), Type, NegativeKeywords, TrackingParams, and confirm. This far exceeds the bare 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 'Create ad groups inside existing campaigns', using a specific verb and resource. It distinguishes from sibling tools like 'add_campaigns' and 'list_ad_groups', which have different purposes.
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 implies campaigns must exist and explains the confirm parameter for dry-run vs execution. However, it does not explicitly compare with alternatives like 'add_ads' or provide when-not-to-use scenarios.
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?
Discloses irreversibility, stats loss, and dry-run behavior via confirm parameter. No annotations provided, so description bears full burden. Could mention effect on ad groups.
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?
Dense, well-structured with warning, alternative, and Args block. No redundant sentences, front-loaded purpose.
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?
Covers all essential aspects for a simple delete tool with two parameters and no output schema: purpose, side effects, alternative, parameter semantics.
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?
With 0% schema coverage, description explains both parameters: ad_ids as list of IDs, confirm as toggle for dry-run. Adds value beyond type info but omits confirm default (false).
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?
Clearly states 'Permanently delete ads' with a specific verb and resource. Distinguished from sibling tools like 'archive_campaigns' and 'delete_keywords'.
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?
Explicitly suggests archiving as alternative when history needs to be preserved. Does not cover other exclusions or when-not-to-use cases.
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?
The description discloses the destructive nature ('permanently delete') and the dry-run capability. No annotations are provided, so the description carries the full burden, which it meets adequately.
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 extremely concise, with only three lines including the args breakdown. No redundant information, and the action 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?
Given no annotations or output schema, the description covers purpose, parameters, and behavior (dry-run). It lacks details on return value or prerequisites, but for a simple tool with 2 parameters, it is sufficient.
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?
The description adds significant meaning beyond the schema: keyword_ids are explained as 'List of keyword IDs to delete' and confirm as 'True to delete; False returns dry-run plan'. Since schema coverage is 0%, this is essential and complete.
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 'Permanently delete keywords from ad groups', specifying the verb and resource. It distinguishes from sibling tools like 'archive_campaigns' which target campaigns.
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 how to use the tool (supply keyword_ids and set confirm=True for deletion, False for dry-run). It provides clear guidance but does not explicitly mention when not to use it or alternatives.
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 discloses bulk adjustment, dry-run capability, and the micros unit via a prominent money note. However, it does not detail error handling, idempotency, or prerequisites like authentication.
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 front-loaded with purpose and usage guidance. The args list and money note are clear, though slightly verbose; overall concise with no wasted words.
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?
While parameter semantics are covered, the output is not described (e.g., success/failure indicators). Lacks mention of rate limits or prerequisites, leaving some gaps for a bulk operation tool.
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?
Despite 0% schema coverage, the description fully specifies each bid object field (KeywordId required, SearchBid and NetworkBid in micros) and the confirm parameter, adding critical meaning absent from 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 'Set search and/or network bids for keywords (bulk bid adjustment).' It uses a specific verb and resource, and distinguishes from sibling tool 'update_keywords' by noting it is more efficient for bid changes.
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 advises 'Prefer this over update_keywords when you only need to change bids — it uses the dedicated bids service and is more efficient.' It also explains the confirm parameter's role in executing vs. dry-run planning.
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?
Given no annotations, the description discloses the dry-run preview by default and mutability of resuming campaigns. It could mention constraints (e.g., only for suspended campaigns) but overall is transparent.
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 extremely concise with three lines, no wasted words. The purpose and parameter usage are 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 two-parameter tool with no output schema, the description covers the essential behavior and parameter nuances completely.
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 description coverage is 0%, but the description fully explains both parameters: campaign_ids as a list to specify which to resume, and confirm with its default false behavior showing a dry-run plan. This adds meaning 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 'Resume previously suspended campaigns,' which is a specific verb+resource. It distinguishes from siblings like suspend_campaigns and archive_campaigns.
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 the dry-run vs execute behavior of the confirm parameter, providing clear usage context. However, it does not explicitly state when not to use this tool or mention alternatives.
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 fully discloses key behaviors: resetting approved ads to DRAFT, the need for re-moderation, and the dry-run mode when confirm=False. This provides essential transparency for safety and decision-making.
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 well-organized with a note and a clear argument breakdown. It is slightly lengthy due to the inlined parameter docs, but every sentence adds necessary information given the sparse schema.
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 no annotations and no output schema, the description covers the purpose, side effects, and parameter details adequately. It does not describe return values or error states, but the core functional context is complete.
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?
The input schema has 0% description coverage, but the tool description exhaustively details each parameter, including nested fields with character limits and the confirm parameter's purpose. This adds substantial value beyond the minimal 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 'Update text ads (title, text, URL, etc.)', specifying the exact resource and action. It distinguishes from siblings like delete_ads, add_ads, and moderate_ads by focusing on updating existing ads.
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 includes a critical note about updating an approved ad resetting it to DRAFT and requiring re-moderation, which guides when to use the tool. However, it does not explicitly compare to alternatives or state 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses that cost is in RUB (not micros), the API is async with up to 5 minutes polling, and provides popular field_names. This is excellent transparency.
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 well-structured with Args and Notes sections, and purpose is front-loaded. It is concise but could be slightly tighter, e.g., by integrating the note about money format into the relevant parameter description.
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 6 parameters (4 required) and no output schema, the description covers all necessary information: parameter semantics, return format, async behavior, and cost unit. 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?
Despite 0% schema description coverage (no property descriptions in input schema), the tool description compensates thoroughly: it explains each parameter, gives examples, and lists valid report types and date formats.
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 runs a Reports-service query and returns rows as a list of dicts. It specifies the report types and parameters, distinguishing it from sibling tools that perform CRUD operations on campaigns, ad groups, etc.
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 lists required and optional parameters and provides notes on behavior, but lacks explicit guidance on when to choose this tool over siblings. However, given the sibling names, the usage context is clear.
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?
Discloses that the tool replaces the complete list of negative keywords, not appends, and explains the syntax convention (no minus sign). No annotations provided, so description carries full burden.
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 bullet points and examples; every sentence adds value without being verbose.
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?
Comprehensive description covering behavior, prerequisites, dry-run, and syntax, despite no output schema. Addresses how to use with sibling tools.
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?
Adds significant meaning beyond the schema by providing detailed structure examples for campaign_updates and ad_group_updates, including required fields like Id and NegativeKeywords.Items.
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?
Clearly states it adds negative keywords to campaigns or ad groups, and differentiates from sibling tools like add_keywords by specifying 'negative'.
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 instructions, including prerequisite calls to list_ad_groups or list_campaigns, and explains the confirm parameter for dry-run testing.
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 fully discloses behavior: read-only after archiving, stats preserved, irreversibility via API, and the dry-run vs actual archive behavior of the confirm parameter.
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?
Highly concise: three sentences covering purpose, prerequisite, and caveat, followed by clear parameter descriptions. No unnecessary 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?
The description covers all necessary aspects: purpose, prerequisites, consequences, and parameter details. No gaps given the tool's simplicity.
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 0%, so description compensates fully by explaining the role of campaign_ids and confirm (dry-run vs actual action).
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 (archive campaigns), the result (become read-only, stats preserved), and distinguishes from siblings like suspend_campaigns by noting it requires prior suspension.
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 provides prerequisite ('Campaign must be suspended first') and an important caveat ('cannot be unarchived via API'), guiding when to use and when not to.
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-direct-mcp MCP server](https://glama.ai/mcp/servers/OlegRadinuk/yandex-direct-mcp/badges/card.svg)](https://glama.ai/mcp/servers/OlegRadinuk/yandex-direct-mcp)

Score Badge

Copy to your README.md:

[![yandex-direct-mcp MCP server](https://glama.ai/mcp/servers/OlegRadinuk/yandex-direct-mcp/badges/score.svg)](https://glama.ai/mcp/servers/OlegRadinuk/yandex-direct-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/OlegRadinuk/yandex-direct-mcp'

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