adops-mcp

Server Quality Checklist

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

Latest release: v1.3.1
Disambiguation4/5
Most tools have clearly distinct purposes. Potential confusion between 'ads_report' and 'campaign_list' (both list campaigns), but descriptions differentiate: ads_report focuses on aggregated performance metrics while campaign_list is for listing and filtering campaigns. Also 'budget_analyze' and 'budget_reallocate' are closely related but represent distinct actions (analysis vs execution).
Naming Consistency3/5
Mixed naming conventions: some tools use snake_case (ad_csv_import, ab_test_analyze, campaign_list) while others use underscore with verbs (ads_report, anomaly_detect, budget_analyze). The prefix 'ad' vs 'ads' varies (ad_demo_seed vs ads_report). Some tool names are clear (campaign_create, campaign_update), but 'creative_specs' lacks a verb. Overall inconsistent pattern.
Tool Count4/5
17 tools is reasonable for an ad operations server covering campaign management, reporting, budget analysis, and creative specs. It feels slightly on the higher side but each tool serves a distinct purpose. Could perhaps consolidate 'campaign_pause_resume' into 'campaign_update' but the batch capability justifies its existence.
Completeness4/5
Covers campaign lifecycle (create, list, update, pause/resume), budget management (analyze, reallocate), reporting (ads_report, audience_insights), anomaly detection, A/B testing, competitor benchmarking, forecasting, and import/seed data. Missing direct campaign deletion but can be paused. Also missing note: 'ad_csv_import' is essential but its connection to other tools could be clearer. Overall well-rounded.
Average 4.5/5 across 17 of 17 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on April 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, which cover the safety profile. The description adds that the tool returns exact specifications, which aligns with the read-only nature. No additional behavioral traits (e.g., rate limits) are disclosed, but the description does not contradict annotations.
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 concise with three focusing sentences: first on output, second on input, third on usage. There is no redundancy. It is well-structured and front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description provides a detailed list of return fields (image dimensions, aspect ratios, etc.). It also explains input parameters and gives a usage tip. The only gap is the inconsistency between description examples and schema enums, but overall the description covers essential context for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (format parameter lacks description). The description does add meaning by providing example values for format (e.g., 'responsive_display', 'single_image') and clarifying platform as 'google_ads'|'meta_ads', but these examples differ from the schema's enum values (platform: 'google'/'meta'; format: 'image'/'video'/'carousel'/'stories'). This inconsistency reduces reliability. Overall, the description partially compensates for the schema gap but introduces confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns platform-specific creative requirements and lists specific output fields. It is distinct from sibling tools. However, there is a minor inconsistency: the description mentions platform values 'google_ads' and 'meta_ads' while the schema uses 'google' and 'meta', 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises using this tool 'before building creatives to avoid rejection at upload time', setting clear context. No direct alternatives are mentioned, but sibling tools do not overlap significantly, making the guidance effective.
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?
Annotations already declare read-only, non-destructive, idempotent behavior. The description adds value by detailing the return structure and pagination mechanics. There is no contradiction with annotations.
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 and front-loaded, covering purpose, filters, pagination, return format, and usage with siblings. It is concise but could be slightly trimmed without losing information.
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?
With no output schema, the description adequately explains the return object. Parameters are partially detailed, but the enum mismatches create gaps. Given the complexity (5 params, cross-platform), more precision is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 60%, but the description provides additional enum values for platform and status that contradict the schema: description says 'google_ads'|'meta_ads' while schema uses 'google'|'meta'; status lists different set. This mismatch reduces reliability and usefulness.
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 campaigns across Google Ads and Meta Ads in a unified view. It uses a specific verb (list) and resource (campaigns), and distinguishes from siblings by emphasizing the cross-platform aggregation.
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 when to use (unified listing across platforms) and provides context on optional filters. It also suggests follow-up tools using the returned id. However, it does not explicitly exclude scenarios or compare with other listing/reporting siblings.
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?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description adds that the campaign is stored as 'draft', returns a summary and next_steps, and auto-associates the first active connection. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is four sentences, front-loaded with the main action, and no superfluous information. 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?
Given the complexity (9 parameters, nested targeting, no output schema), the description covers purpose, parameters, behavior (draft, return, connection requirement). Could benefit from mentioning return format explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 89%, so the schema already provides most parameter descriptions. The description lists parameters but adds minimal new meaning beyond grouping them as 'unified'.
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 a new ad campaign in the AdOps workspace', specifying the verb (create), resource (ad campaign), and context (AdOps). It lists the unified parameters and distinguishes from sibling tools like campaign_update and campaign_list.
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 mentions the prerequisite of an active platform connection and references platform_connect, but does not explicitly state when to use this tool vs. alternatives like campaign_update 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses idempotency (returns existing connection) and the return format (connection object with UUID and status active). Annotations already provide idempotentHint=true; the description adds specific return details. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose. Each sentence adds value: purpose, inputs, return, idempotency. No fluff.
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?
Covers purpose, inputs, return, idempotency, and prerequisite relationship for subsequent tools. Lacks error handling or permission requirements, but mild gap for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so descriptions repeat some info. However, the description says platform accepts 'google_ads'|'meta_ads', while schema enum is 'google'|'meta', causing inconsistency. This reduces clarity despite other parameter details.
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 registers a Google Ads or Meta Ads account in the AdOps workspace to enable subsequent tools like campaign_list, campaign_create, and ads_report. It distinguishes the tool's role as a prerequisite from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool should be used to set up an ad account before using other campaign and reporting tools. It also notes idempotency, indicating it is safe to call multiple times. However, it 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?
Annotations already indicate readOnly, non-destructive, idempotent behavior. The description adds value by detailing the return structure (period, totals, campaigns, top_performers, etc.) without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured paragraph with purpose first, then input, then output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-param tool with no output schema, the description covers inputs, outputs, and usage context. However, 'top_performers' and 'underperformers' are not explained, leaving minor ambiguity.
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 description explains the date_range format with defaults, lists sort_by options, and mentions limit. This adds context beyond the schema's 60% coverage, especially for the return shape that connects to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Aggregate performance metrics across Google Ads and Meta Ads into a single unified view.' This is a specific verb-resource combination, and the tool stands out from siblings like campaign_list or budget_analyze.
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 notes 'This is the entry point for most analysis workflows,' which implies broad usage but does not explicitly list when not to use it or provide 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?
Annotations already provide readOnlyHint, destructiveHint, idempotentHint. Description adds the return structure and input optionality, which complements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, inputs, outputs, and usage. No wasted words, front-loaded with core function.
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?
With no output schema, description lists all return fields. Inputs are fully described. Lacks potential details like time range or data freshness, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description clarifies that omitting platform returns all platforms, and campaign_id scopes to a single campaign, adding meaning beyond the schema's enum and format constraints.
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 states 'Demographic and behavioural breakdown of the audiences served by your ads' with specific verb and resource. It lists inputs and returns, clearly distinguishing from sibling tools like ads_report or campaign_create.
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?
Description explicitly says 'Use when refining targeting or reporting audience coverage', providing clear context. However, it does not mention when not to use it or suggest alternatives like campaign_list for campaign-level data.
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: re-importing with the same connection_name appends data, and returns a summary with campaigns_imported, metrics_imported, warnings, and connection id. Annotations provide no hints, so the description carries the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections for purpose, export instructions, and input details. The HOW TO EXPORT section is detailed but practical; overall length is justified given the complexity of supported platforms and input options.
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 aspects: purpose, required inputs, behavior on re-import, return values, and platform-specific export steps. No output schema exists, so the description adequately explains the return summary.
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 100% with descriptions for all 5 parameters. The description adds significant value by explaining the preference for csv_path for large exports, the default for connection_name, and the purpose of account_id, going beyond schema details.
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 imports real campaign data from Google Ads or Meta Ads CSV exports. It distinguishes from siblings like ad_demo_seed (demo data) and platform_connect (API) by emphasizing no API keys needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (CSV exports, no API) and includes step-by-step export instructions for both platforms. However, it does not explicitly compare with alternative import methods like platform_connect or ad_demo_seed.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, so safe. Description adds valuable behavioral context: rolling baseline, flags specific metrics, and returns structured alerts. 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?
Four sentences, front-loaded with purpose, then lists anomaly types, parameter details, output structure, and usage recommendation. Every sentence adds value; no fluff.
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 no output schema and three params, description fully covers tool behavior, inputs, and output structure. It even suggests daily use. Sibling tools are distinct, and context is sufficient for agent decision.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning for two parameters: sensitivity (z-score threshold) and platform (filter). However, it states lookback_days default as 14, contradicting schema default of 7. Schema coverage is 67% so description partially compensates, but the mismatch reduces reliability.
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 scans campaigns for statistical anomalies against a rolling baseline, listing specific anomaly types (CPC spikes, CTR drops, etc.). This differentiates it from sibling tools like ab_test_analyze or audience_insights.
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 recommends daily execution ('Run daily to catch issues before they burn budget'), providing a clear when-to-use hint. However, lacks explicit when-not-to-use or comparison with 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?
Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds detail on the output structure (goal, allocation, recommendations, projected_lift), but does not mention any potential side effects or constraints beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: purpose, input, output. All information is front-loaded and each sentence contributes directly to understanding the tool. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description fully explains input options, output structure, and the recommended follow-up tool. Annotations cover behavioral aspects. No gaps remain.
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?
Only one of two parameters has a description in the schema (platform), but the description provides the enum values for optimization_goal and explains its default. This compensates for the 50% schema coverage and 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?
Description clearly states the tool analyzes ad budget distribution and produces reallocations recommendations. This is specific and distinguishes from sibling 'budget_reallocate' which executes recommendations.
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?
Description specifies required input (optimization_goal) and optional platform filter, and explicitly recommends pairing with budget_reallocate for execution. It lacks explicit 'when not to use' but context is clear enough.
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 a key behavioral trait: benchmarks are 'curated static tables — not live market data'. This goes beyond the annotations, which already indicate readOnlyHint=true and idempotentHint=true. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2-3 sentences) and front-loaded: it starts with the purpose, then inputs, then outputs, with no extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description fully documents the return structure (industry, your_metrics, benchmarks, comparison, recommendations). It also clarifies the static nature of benchmarks. Annotations cover safety, and parameters are well-explained. The description is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (industry has description, platform does not). The description adds meaning by listing example industries and stating the platform filter is optional, which supplements the schema. It also describes the return structure, providing context for how parameters affect output.
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 that the tool compares ad performance against industry averages. It provides a specific verb ('Compare') and resource ('ad performance against industry averages'), and it distinguishes from sibling tools like 'audience_insights' or 'budget_analyze' which focus on different aspects.
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 when to use the tool (to compare performance against industry averages) and what inputs are needed. However, it does not explicitly state when not to use it or mention alternative tools for similar tasks. This is a minor gap.
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?
Goes beyond annotations by detailing the statistical method (two-proportion z-test or means comparison), outputs (p-value, CI, winner, etc.), and decision criteria. No contradiction with annotations (readOnlyHint=true, idempotentHint=true are consistent with analysis).
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?
Concise and well-structured: purpose first, then inputs, method, output, and guidelines. Every sentence adds value with no 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?
Fully describes inputs, method, and output fields despite lacking output schema. However, lacks prerequisites (e.g., minimum sample size, campaign validity) that could help an agent avoid errors.
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 meaning beyond schema: lists five possible primary_metric values (including 'cpc' not in schema), explains input format, and describes output fields. This compensates for schema parameters with limited description.
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 specifies the tool compares two campaigns via A/B test analysis, determining statistical significance. It distinguishes from sibling tools like campaign_create or campaign_list, which are unrelated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a decision rule ('lift ≥5% and p<0.05') but does not explicitly contrast with alternative tools or state when not to use. The context is clear enough for an agent to infer appropriate usage.
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?
Since annotations carry minimal behavioral info (readOnlyHint, destructiveHint false), the description fully describes the tool's action (mutation), rejection rules (same ID, negative balance), and return value (updated budgets). This adds critical context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: purpose, example, then input/behavior details. Every sentence is informative with no redundancy. It is front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 required parameters, no output schema, and minimal annotations, the description covers all necessary aspects: what it does, constraints, acceptance criteria, and return value. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description goes beyond by explaining that IDs must differ, amount is in campaign currency, and rejection rules. This adds meaningful context beyond the schema's simple descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Transfer') and resource ('campaign's daily budget'). It clearly distinguishes from sibling tools like budget_analyze by focusing on reallocation across campaigns and platforms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (shifting budget between campaigns) with a concrete cross-platform example. It mentions rejection conditions but does not explicitly state when not to use or suggest alternative tools.
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?
The description adds significant behavioral context beyond the annotations (readOnlyHint, idempotentHint). It discloses the methodology (moving-average extrapolation), output fields (projected metrics, confidence_level, warnings), and limitations (confidence drops with volatile data or paused campaigns). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three sentences) and well-structured. It front-loads the purpose and input, then explains the methodology and output structure. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides a comprehensive summary of the return value structure (period_days, platform, projected metrics, confidence_level, warnings). It also covers confidence degradation conditions, making it complete for an agent to understand the tool's behavior.
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 description elaborates on the parameters by restating the period_days options and noting platform is optional. While the schema covers 50% of parameter descriptions, the description adds clarity by explicitly listing the platform filter. It does not fully compensate for undocumented parameters but adds meaningful context.
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: projecting future ad spend and performance based on historical trends. It uses a specific verb ('Project') and resource ('ad spend and performance'), and distinguishes itself from siblings like budget_analyze by focusing on forecasting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool, including input parameters (period_days and platform). It implies usage for forecasting but does not explicitly state when not to use it or mention alternatives, though the context is adequate given sibling tools serve different purposes.
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?
The description explains batch behavior (missing IDs reported in errors without failing the batch), return structure, and the fact that action values map to specific statuses. This goes beyond annotations which only indicate idempotence and non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose. Every sentence adds value without redundancy. Highly concise.
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 no output schema, the description includes the return structure and explains edge cases (missing IDs). The use case is specified. It is fully complete for the tool's 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?
While the schema already describes both parameters, the description adds meaning: it explains what each action value does (maps to status) and how missing IDs are handled, which is not in 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 'Batch-change the status of up to 50 campaigns' and explains each action ('pause' sets status to 'paused', 'resume' sets to 'active'). This distinguishes it from sibling tools like campaign_create or campaign_update.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Use this for emergency pause during an incident or weekend shutoff.' It could be improved by explicitly stating when not to use or mentioning alternatives, but the 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 return format ({message, updated_fields[], campaign}) and error if campaign_id not found. IdempotentHint in annotations is consistent; description adds partial update behavior and return details.
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 plus a one-phrase tip. No wasted words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers patch semantics, error handling, return format, and alternative tool usage. Lacks mention of total_budget parameter, but otherwise sufficient for agent decision-making.
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?
Description enumerates key updatable fields (name, status, daily_budget, bidding_strategy, end_date) beyond the schema's 14% coverage. However, the parameter total_budget is omitted from the description, slightly reducing completeness.
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 'Patch-update an existing campaign' with specific verb and resource. Distinguishes from sibling tool campaign_pause_resume by advising its use for batch status 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?
Provides explicit guidance: include campaign_id from campaign_list or campaign_create, pass any subset of fields, omitted fields unchanged. Explicitly prefers campaign_pause_resume for batch status changes.
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?
Description discloses that the tool creates data (consistent with readOnlyHint=false) and appends new portfolios each call (consistent with idempotentHint=false). It adds context beyond annotations by explaining the demo nature and safety of multiple calls.
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?
Extremely concise at two sentences. First sentence provides purpose and content; second sentence adds usage guidance and safety. No wasted words, information is 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?
Given zero parameters, no output schema, and the tool's role as a demo data generator, the description fully covers what the tool does, what data it creates, and when to use it. AI agents have sufficient information to decide invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so description adds no parameter semantics beyond what's already known from the input schema. Baseline of 4 is appropriate since there is no need for parameter description.
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 creates a realistic cross-platform ad portfolio for trying AdOps without real data. It specifies exactly what is seeded (2 connections, 8 campaigns, 30 days metrics, anomaly alerts) and distinguishes it from sibling tool ad_csv_import for real data.
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 guidance: 'Use this to explore what AdOps can do, then switch to ad_csv_import with your real Google/Meta exports for production use.' Also notes it's safe to call multiple times (appends), giving clear usage boundaries.
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?
Annotations declare readOnlyHint=true and idempotentHint=true. The description reinforces that the tool does not call Google/Meta write APIs and explains that output can be inline or to a file. 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?
The description is a single paragraph of 6-7 sentences, front-loaded with the core purpose, followed by specific details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains output formats and usage. It references sibling tools (budget_analyze) and covers all parameters. An agent gets complete guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds extra meaning by explaining the workflow for each format (e.g., 'import into Google Ads Editor') and providing an example for min_delta_pct, exceeding baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports budget_analyze recommendations in multiple formats (Google Ads CSV, Meta Ads CSV, JSON, Markdown) for bulk editing. It distinguishes from sibling tools like budget_analyze and budget_reallocate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance (bulk editing, 'pause anything with CPA over 50' workflow) and when-not-to-use (no direct API calls). It specifies which format works with which platform and explains alternatives for automation or human review.
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:

[![adops-mcp MCP server](https://glama.ai/mcp/servers/automatiabcn/adops-mcp/badges/card.svg)](https://glama.ai/mcp/servers/automatiabcn/adops-mcp)

Score Badge

Copy to your README.md:

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

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