microsoft-ads-mcp
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation4/5
Tools are mostly distinct with clear resource/action pairing (list_campaigns vs list_ad_groups vs set_campaign_status). A few analytics tools (account_overview, performance_report, compare_periods) have overlapping report-like purposes but their descriptions clarify different use cases.
Naming Consistency3/5The majority use verb_noun (list_*, set_*, add_*, create_*), but several key tools break the pattern with noun-first names (performance_report, account_overview, optimization_audit, search_term_harvest). This mixed convention is readable but not fully predictable.
Tool Count4/526 tools exceeds the typical 3-15 sweet spot, but the breadth of Microsoft Ads management (accounts, campaigns, ad groups, keywords, ads, negatives, shared lists, reporting, optimization) justifies the count. Each tool serves a distinct purpose; none are redundant.
Completeness4/5Core lifecycle coverage is solid: create/list/set-update for campaigns, ad groups, keywords, and ads, plus negative keyword management and rich reporting. Minor gaps include no way to delete keywords/ads, no ad group bid update after creation, and shared list management limited to adding negatives (no remove/create/delete list tools).
Average 4/5 across 26 of 26 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must independently disclose behavior. It reveals the tool processes search queries and generates suggestions tied to ad groups, adding useful context. Yet, it does not clarify whether this is read-only, what data sources are used, or how 'exact keyword' is determined, leaving notable transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only two sentences to convey the core purpose. The 'growth mirror' phrase is efficient but slightly cryptic; overall, it earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has four parameters and no schema-level descriptions, the description is insufficient for understanding parameter semantics or proper usage. The presence of an output schema helps with return values, but the lack of parameter guidance and usage boundaries makes the overall description incomplete for effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the tool description provides no explanation of parameters such as limit, lookback, or min_conversions. This is a critical deficiency for an agent to correctly invoke the tool with appropriate values, especially since the schema only offers names and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's function: converting non-exact search queries into keyword suggestions with ad group context. The phrase 'growth mirror of find_wasted_spend' differentiates it from the sibling tool, establishing a clear purpose. However, the verb 'converting' could be more specific about the exact output (e.g., 'generates suggestions'), leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by positioning the tool as the 'growth mirror' of find_wasted_spend, suggesting it is for expansion rather than waste reduction. However, it lacks explicit guidance on when to use this versus alternatives like add_keywords or list_keywords, leaving the agent to infer the appropriate context.
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 provided, so description carries full burden. The description states the action and fields but does not explicitly disclose read-only behavior, pagination, or other side effects. The word 'List' implies a safe read operation, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema (though not shown), so return values are covered. The description adds field specificity but misses explaining account_id and does not offer usage differentiation from siblings. It is adequate for a low-complexity list tool but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It implicitly explains ad_group_id via 'in an ad group' but completely omits account_id, which is required. The schema titles help but are not sufficient compensation for the missing parameter guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('keywords in an ad group'), and enumerates the fields returned. It clearly distinguishes from sibling tools like list_negative_keywords and list_ad_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied ('in an ad group') but no explicit alternatives or when-not-to-use guidance is provided. With siblings like list_negative_keywords, mentioning when to choose this tool over alternatives would improve clarity.
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 burden. 'Snapshot' suggests a read-only operation, but it does not explicitly confirm no side effects or disclose behavioral constraints like rate limits or data freshness. The flag examples provide some behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the core value proposition, and includes specific output details in a compact list. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the tool is relatively simple, the description provides clear overall purpose and usage context. It omits parameter explanation and caveats, but this is somewhat mitigated by the schema's default for predefined_time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters. 'predefined_time' is completely unexplained, leaving the agent to guess its meaning and allowed values. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'One-call health snapshot' with account KPIs, per-campaign breakdown, and flags. It distinguishes itself from sibling tools like performance_report or find_wasted_spend by framing it as the 'best starting point' for account health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Best starting point for "how are my ads doing?"', which gives clear guidance on when to use it. It implies an initial assessment scenario but does not explicitly list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses critical behavior: the campaign defaults to PAUSED and never spends until explicitly enabled, and it returns the new campaign_id. This is valuable context beyond a simple create operation, though it does not cover permissions or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and contains no filler or redundant information. Every clause adds value: the campaign type, the default status, and the return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 4 parameters and an available output schema. The description covers the essential behavioral context (default PAUSED, returns campaign_id) and the schema documents the parameter requirements. It could mention required fields or account_id context, but overall it is sufficiently complete for this low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%: the description does not mention any of the four parameters (account_id, name, daily_budget, status). It provides no additional meaning beyond the schema, which already has types and a default for status. The description fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the resource ('Search campaign'), and a key differentiator ('Manual CPC'). It distinguishes this from siblings like create_ad_group and build_search_campaign by specifying the exact campaign type and bidding strategy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new Search campaign but does not explicitly mention alternatives or when not to use this tool. It gives context about the default PAUSED state, which helps the agent understand the workflow, but it lacks explicit exclusions or references to sibling tools like build_search_campaign.
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 the full burden for behavioral disclosure. The verb 'list' implies a read-only operation, but the description does not explicitly state safety, side effects, or data scope nuances (e.g., only campaign-level, not shared lists). It adds minimal context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the verb, resource, and return fields. There is no filler or unnecessary detail, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with straightforward parameters and an output schema, the description is largely complete: it states the scope (campaign-level), the fields returned, and the action. However, it lacks explicit usage guidance and does not mention prerequisites like needing valid account/campaign IDs, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain the required parameters account_id and campaign_id. While the parameter names are self-explanatory, the description adds no guidance on their meaning, source, or relationship to the tool's function, failing to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List campaign-level negative keywords' with the specific resource and scope. It also enumerates the return fields (id, text, match type), which distinguishes it from sibling tools like list_keywords or list_shared_negative_lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming the resource, but it does not explicitly state when to choose this tool over alternatives like list_keywords or list_shared_negative_lists. No exclusions or alternative guidance are provided, so usage context is only implied.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Remove', which is the expected operation, but it does not mention permanence, permissions, side effects, or whether removal is destructive in a way that affects campaigns. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero filler. It efficiently communicates the action, target, and data source without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values need no explanation. The description covers the action, scope, and id source, but due to missing annotations, it lacks details on consequences or prerequisites beyond listing. It is adequate but not comprehensive for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. The phrase 'by id (from list_negative_keywords)' adds crucial meaning: the negative_keyword_ids array should contain ids previously returned by list_negative_keywords. However, it does not elaborate on account_id or campaign_id beyond what their names imply, providing only partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove'), the resource ('campaign-level negative keywords'), and the method ('by id'). It also references the source tool 'list_negative_keywords', which distinguishes it from sibling tools like 'add_negative_keywords' and clarifies the exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(from list_negative_keywords)' implies the prerequisite workflow: list negative keywords first to obtain ids, then use this tool to remove them. It also specifies 'campaign-level', implicitly excluding shared-list negatives. However, it does not explicitly discuss when not to use or mention alternatives.
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 the transparency burden. It does disclose meaningful behavior: valid status values ('Active'/'Paused'), bid currency, and the partial-update semantics implied by 'and/or'. However, it does not mention permissions, reversibility, or side effects (e.g., overwriting existing values), which is a gap for a mutation tool without annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and every word adds value. The constraint is stated succinctly in a separate sentence. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and a moderate number of parameters. The description covers the core update semantics and the required at-least-one rule, making it invocable. It lacks explicit alternatives or error conditions, but those are not essential for correct invocation given the clear schema and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It adds important semantics beyond the schema: the valid status values, that bid is in account currency, and the rule that at least one of status/bid is required. The required IDs (account_id, ad_group_id, keyword_id) are not explained, but their purpose is inferable from their names and the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a keyword's status and/or bid, which is specific and distinct from sibling tools that modify campaigns or ad groups. However, it does not explicitly name alternative tools for other resource types, so it lacks the explicit sibling differentiation seen in higher-scoring examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implicit usage context: update a keyword's fields. It also gives a key constraint ('Provide at least one of status or bid'), which is operational guidance. However, it does not explicitly state when to use this tool versus alternatives like set_campaign_status or set_ad_group_status, and offers no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It indicates a read-only operation via 'List' but does not mention any additional behavioral traits such as pagination, status filters, inclusion of deleted/archived ads, or authorization requirements. The field list adds minimal context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and scope. It includes the key returned fields without unnecessary elaboration, making it efficient and easily parsed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no enums, no nested objects) and the presence of an output schema, the description adequately covers the essential purpose and scope. However, it omits any caveats such as whether all ads are returned or if any filtering applies, which could be relevant. The existence of the output schema reduces the need to explain return values, so this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter details. It clarifies that ad_group_id is the scope ('in an ad group'), but does not explain account_id's role or any parameter constraints. This partial clarification adds some meaning beyond the bare parameter titles, but not enough to fully compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'ads', and the scope 'in an ad group', making it distinct from sibling tools like list_ad_groups or list_keywords. It also enumerates the returned fields, removing ambiguity about what data is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in an ad group' provides clear context that this tool is for listing ads within a specific ad group, implying the need for an ad_group_id. While it doesn't explicitly name alternatives or exclusions, the context is sufficient for an agent to choose this tool when ads are needed.
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 indicates a read-only operation via 'List' and discloses the returned fields. It does not mention any other behavioral aspects such as pagination, filtering, or account scoping details beyond 'in an account'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear structure, front-loading the verb and resource. It contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and the description covers purpose and returned fields. The presence of an output schema reduces the need to explain return values, but the description omits any mention of pagination or edge cases. It is adequate for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, account_id, is contextualized by the phrase 'in an account', but the description does not explicitly explain the parameter or its format, leaving the schema's title to carry meaning. The description adds only minimal semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific action 'List' on a specific resource 'campaigns' within an account. The field list ('id, name, status, type, daily budget') clarifies the output scope and differentiates from sibling list tools like list_accounts or list_ad_groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when campaign data is needed but does not provide explicit guidance on when to choose this over sibling list tools, nor does it mention any exclusions or prerequisites. It lacks alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action and allowed statuses but does not disclose prerequisites, side effects, reversibility, or response details. The behavior is simple but only partially 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences with no filler. It front-loads the core action and includes only necessary parameter information, making it concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status setter, the description covers the essential behavior and status values. It lacks usage guidance and parameter details for IDs, but the output schema exists and the tool complexity is low, so it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage). The description adds meaning for the 'status' parameter by listing allowed values ('Active' or 'Paused'), but it does not explain the ID parameters (account_id, campaign_id, ad_group_id), though their names are self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Pause or enable' and the resource 'an ad group', which precisely defines the tool's function. It also distinguishes from sibling tools like set_campaign_status by targeting ad groups specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for changing ad group status but provides no explicit comparison or exclusion versus sibling tools like set_campaign_status. It lacks clear 'when to use' or 'when not to use' guidance, though the purpose is evident.
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 that this is an add operation and returns new negative keyword IDs, but it doesn't discuss behavior on duplicates, permission requirements, or whether the change is reversible. This is partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences that front-load the purpose, then add key parameter guidance and return value. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 4 params and an output schema. The description covers the main purpose, match_type semantics, and return value. It doesn't mention error cases or prerequisites, but for this low-complexity tool, it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It specifies allowed match_type values ('Exact' or 'Phrase') and clarifies the campaign-level scope, but doesn't add meaning to account_id or the texts array beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('campaign-level negative keywords'), with a clear goal ('stop ads showing for those terms'). It distinguishes from siblings like add_keywords and add_negatives_to_shared_list by specifying campaign-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool is for adding negative keywords at the campaign level, which is a clear use case. However, it doesn't explicitly mention alternatives like shared negative lists or when not to use it, so it has clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains the two modes (dry_run returns a plan; dry_run=False applies changes) and instructs to confirm with the user, indicating a mutating operation. It does not disclose potential side effects like impact on existing negatives or scope across campaigns, but the key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and efficiently adds the critical dry_run workflow. Every sentence earns its place with no redundancy or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no annotations, but an output schema exists. The description covers the main workflow and the most important parameter (dry_run), but leaves out semantics for the other five parameters. While the output schema may document return values, the missing parameter guidance makes the tool less complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. Only dry_run is explained (plan vs apply). Other parameters like limit, lookback, min_spend, account_id, and match_type are not described at all. This leaves a significant gap in understanding the tool's configuration, especially since the schema provides only names/types/defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Find wasted search terms (spend with no conversions) and add them as campaign negative keywords.' This specific verb+resource combination distinguishes it from siblings like find_wasted_spend (which likely only identifies waste) and add_negative_keywords (which requires manual input). The dual-mode behavior (plan vs apply) is also explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: 'dry_run=True (default) returns the plan only; set dry_run=False to actually apply. Confirm with the user before applying.' This gives explicit guidance on safe usage and the dry_run workflow. However, it does not mention alternatives or when-not-to-use, though the purpose is self-evident from the description and sibling names.
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 discloses meaningful behavior: the ad group defaults to PAUSED and the tool returns the new ad_group_id. But it doesn't mention side effects like potential duplicates, permission requirements, or failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the action and context, the second covers defaults and return value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a create tool with an output schema, the description is fairly complete: it states the action, defaults, and return value. It lacks explicit alternative guidance, but overall provides sufficient context for an agent to select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the status default (PAUSED) and cpc_bid default, but does not elaborate on account_id, campaign_id, or name beyond what their names imply.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource ('Create an ad group in a campaign') and adds scope ('given default CPC bid'). It clearly distinguishes from sibling tools like create_campaign and add_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use (creating ad groups) and implies a workflow via the default PAUSED state, suggesting activation is handled separately. However, it doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explicitly discloses the filtering behavior (spend >= min_spend, conversions <= max_conversions) and sort order, which are non-obvious behavioral traits. It doesn't cover permissions or data scope beyond search terms, but enough is disclosed for a read-only analysis 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no filler. Every clause adds value: resource, filter criteria, sort order, and actionable use case.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values don't need description. However, the description ignores the time-range parameter and row-limit control, which are important for correct invocation. It is adequate for a simple report but has clear gaps in parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions cover 0% of parameters, so the description must compensate. It explains min_spend and max_conversions and implies a spend sort, but omits account_id, max_rows, and predefined_time, leaving important controls undocumented. Partial coverage only; not sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('find') and clearly identifies the resource: search terms meeting spend/conversion criteria, sorted by spend descending. This distinguishes it from sibling list tools and related actions like apply_negatives_from_waste by focusing on the analysis/candidate-identification step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool's context: it surfaces waste candidates suitable for negative keywords. This clearly implies when to use it (before adding negatives), but it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Read-only — suggests, doesn't change anything,' which fully discloses the non-destructive nature of the tool. This is especially valuable because no annotations are provided, making the description carry the full burden of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly efficient: it front-loads the purpose and packs a long list of output details, which is justified by the tool's wide scope. The final 'Read-only' sentence adds key behavioral info. It is slightly dense but each item serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main output categories and the read-only nature, which is sufficient given that an output schema exists (so return values need not be detailed). It does not explain all parameters, but the schema already provides names and defaults, so the description is adequately complete for a tool with an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter meaning. It explicitly mentions 'target_cpa' and implies 'min_wasted_spend' via 'wasted' terminology, but it does not explain 'lookback' or 'min_wasted_spend' by name. Partial compensation but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Audit') and resource ('account'), and enumerates distinct output categories (wasted search terms, low-quality-score keywords, etc.), which clearly distinguishes it from sibling tools like find_wasted_spend or performance_report. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (auditing the account for optimization opportunities) and provides a conditional ('if target_cpa given'), but it never explicitly states when to prefer this tool over alternatives or when not to use it. No named alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It discloses the return value ('Returns new keyword ids'), the item structure including match_type, and defaults for bid and status. This adds meaningful behavioral context beyond a bare mutation description, though it does not detail edge cases like duplicate handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose and then the concise item structure. No fluff, every word adds value. The structure is exemplary for a tool with a nested array parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the essential parameters and return behavior, and an output schema exists for return values. The main gap is the absence of guidance on when to use this instead of sibling tools, but for a focused add-keywords tool with clear parameters, the context is sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does by fully describing the 'keywords' array item format (text, match_type with allowed values, optional bid, status with default), which is the most complex parameter. The numeric ids (account_id, ad_group_id) are left to schema but their purpose is evident from the tool name and siblings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'keywords to an ad group', making the action specific and unambiguous. It distinguishes itself from sibling tools like add_negative_keywords by specifying 'keywords' (positive) and 'ad group', so an agent can easily select it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding keywords to an ad group but does not explicitly contrast with alternatives such as 'set_keyword' or 'add_negative_keywords'. There is no when-to-use or when-not-to-use guidance beyond the obvious purpose, so the agent must infer the context from siblings.
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?
Although no annotations are provided, the description discloses a critical side effect: adding to a shared list affects every campaign the list is attached to. It also clarifies that match_type is limited to 'Exact' or 'Phrase'. It does not cover other behavioral aspects like duplicate handling or permissions, but given the tool's simplicity, the key behavior is conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. Each sentence serves a distinct purpose: stating the action, giving usage preference, and defining a parameter constraint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no annotations, and no schema descriptions, the description does a good job with purpose and usage but omits parameter semantics for most inputs. The output schema may cover return values, but the description still leaves room for ambiguity about what list_id and texts refer to in practice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for any parameters (0% coverage). The description only clarifies match_type values, leaving account_id, list_id, and texts without additional meaning. Most parameter names are somewhat self-explanatory, but the lack of explicit semantics for three of four parameters means the description fails to compensate for the absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add'), the object ('negative keywords'), and the target ('shared list'), and explicitly notes the effect on every attached campaign. This distinguishes it from sibling add_negative_keywords which operates per-campaign.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Prefer this over per-campaign negatives when an account uses a shared negatives list,' which provides a clear decision rule and names the alternative. This is exactly the kind of guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does a solid job: it discloses that everything is created PAUSED, explains the flexible keywords format (plain strings or objects with text/match_type/bid), and specifies ad length requirements (3-15 headlines, 2-4 descriptions). It does not mention transactionality or failure behavior, but the disclosed constraints are genuinely useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences, front-loaded with the core purpose, and every clause earns its place. It covers scope, paused state, keyword flexibility, and ad constraints without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a composite tool with 10 parameters and multiple entities, the description provides a clear overall scope and the most critical constraints. The presence of an output schema means return values do not need explanation. It misses minor clarifications such as how the top-level match_type interacts with object-level match_type values, but overall it gives the agent enough operational context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds essential semantics for the most ambiguous parameter, keywords ('may be plain strings or {text, match_type, bid} objects'), and clarifies headlines/descriptions length constraints. However, it does not explain other parameters like match_type vs keyword-level match_type, cpc_bid, ad_group_name, or daily_budget behavior, leaving several gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a full Search campaign in one call' and enumerates the exact components (campaign + ad group + keywords + Responsive Search Ad), making it distinct from sibling tools like create_campaign or add_keywords. The verb 'Create' plus resource 'full Search campaign' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' implies this is a bundling convenience versus calling the individual sibling tools separately, and 'Everything is created PAUSED' gives an important conditional. However, it does not explicitly state when to prefer this over create_campaign/add_keywords combinations or mention exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It clearly discloses the computation logic (last N days vs preceding N days), what it returns (current, prior, delta, % change), and the report_type scoping. It does not mention potential side effects, but as a read-only comparison tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The second sentence adds essential output details and parameter scope. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides enough context for an agent to understand the tool's behavior and outputs. The output schema likely defines the return structure, so the description doesn't need to elaborate further. However, it lacks any exclusions or edge-case warnings, which are minor for a read-only comparison tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the semantics of 'days' (lookback window) and 'report_type' (scope of totals), while 'account_id' is self-explanatory. This is adequate for the three parameters, though account_id is not explicitly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: compares the last N days against the preceding N days, with a clear verb ('Compare') and resource ('periods'). It also distinguishes itself from sibling tools like performance_report by specifying the period-over-period comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: an agent would use this when needing a period-over-period comparison, but there is no explicit 'when-to-use' or 'when-not-to-use' guidance, nor any mention of alternatives such as performance_report for single-period 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?
With no annotations provided, the description carries the burden. It discloses the exact output fields and scope, making the behavior transparent for a read-only list operation. It doesn't mention pagination or rate limits, but these are less critical for a simple list 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a clear structure: action + resource + scope, followed by a colon and a list of returned fields. Every word carries meaning and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, only two parameters, and the presence of an output schema, the description is largely sufficient. It explicitly names the return fields, making the tool's purpose and result clear. Minor details like ordering or pagination are not mentioned, but these are not critical for a basic list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the campaign context for campaign_id but does not clarify account_id beyond the parameter name itself. While the parameter names are self-explanatory, the description adds minimal semantic value beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (List) with a clear resource (ad groups) and a scope (in a campaign), and explicitly lists the return fields (id, name, status, cpc bid). This distinguishes it from sibling tools like list_keywords and list_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in a campaign' clearly implies the tool is used to retrieve ad groups for a specific campaign, which provides clear context. However, it does not mention any exclusions or explicitly name alternative tools, so it does not earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. It does this well by warning that raising the budget raises potential spend, and instructs to confirm with the user. This highlights the key side effect of the operation. It does not detail permissions or reversibility, but for a simple setter, the primary risk is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with each earning its place. The first states the purpose and the budget unit; the second is a critical warning and user-confirmation instruction. No redundant or vague wording. Excellent economy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 self-explanatory parameters, no nested objects) and the presence of an output schema (reducing the need to describe return values), the description is complete enough. It covers purpose, key risk, and a user interaction requirement. Minor omissions like min/max budget constraints or exact behavior on existing budget are not critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description should add meaning. It does clarify that the daily budget is in account currency, which adds semantics to the daily_budget parameter. However, account_id and campaign_id are left self-explanatory from their names, with no additional guidance on format or validation. The description partially compensates but is not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Set a campaign's daily budget') with the resource (campaign) and the key parameter (daily budget in account currency). This distinguishes it from sibling tools like set_campaign_status, as the verb+resource+object is explicit and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for using the tool: setting a daily budget. It also includes an explicit instruction to confirm increases with the user, which serves as a usage guideline. However, it does not explicitly contrast with alternative tools or state when not to use it, though relative to siblings the purpose is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It warns that 'Active' lets the campaign spend and instructs user confirmation, covering the key side effect. It doesn't mention response behavior or prerequisites, but the main risk is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and followed by a clearly formatted warning. Every sentence adds value without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter tool with an output schema, the description covers purpose, status values, and the primary side effect. It could mention edge cases like setting the same status or validation errors, but these are not essential for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description meaningfully explains the 'status' parameter and its possible values. However, account_id and campaign_id are left to be inferred from their names, and schema coverage is 0%, so the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Pause or enable a campaign,' with the exact allowed status values ('Active' or 'Paused'). This distinguishes it from sibling tools like set_campaign_budget or set_ad_group_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool and includes an important usage caution: confirm with the user before setting 'Active' because it allows spend. It doesn't explicitly name 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.
- 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 that only accounts the signed-in user can access are returned, which is useful. However, it does not describe pagination, ordering, authentication requirements, or whether the operation is read-only, though that is implied by 'List'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The primary purpose and key output fields are stated up front, and the entry-point guidance is concise and memorable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description is complete. It explains what the tool returns, who it applies to, and its role in the workflow, which covers the essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema covers everything. The description adds value by explicitly stating the output fields and highlighting that the returned account_id is needed for other tools ('Start here to get an account_id'). This goes beyond the baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'Microsoft Advertising accounts' and scope ('the signed-in user can access'). It also lists the returned fields (id, name, number, customer id), which differentiates it from list tools for other entities like campaigns or ad groups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Start here to get an account_id' clearly indicates this is the initial step and provides context for when to use the tool. It does not explicitly mention alternatives or when not to use it, but the entry-point guidance is strong enough for a list 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 adequately discloses the behavior of the tool by listing the output fields (id, name, campaign attachment count, and item count). This goes beyond the basic 'List' verb and gives the agent a clear expectation of what will be returned, fulfilling the transparency burden for a simple read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the purpose and includes useful return-field information without any fluff. Every part of the sentence contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter and an existing output schema, this description is fully sufficient. It states what is listed and the key output attributes, and the presence of an output schema means detailed return value documentation is not required. The description covers the essential context needed by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter, account_id, with no description (0% coverage). The description refers to 'account-level' lists, which indirectly clarifies that account_id identifies the account, but it does not explicitly explain the parameter's format or role. It adds some semantic value but could be more direct in linking account_id to the operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool lists account-level negative-keyword lists shared across campaigns. It uses a specific verb ('List') and resource ('negative-keyword lists'), and distinguishes itself from sibling tools like list_negative_keywords by noting it operates at the account level and is shared across 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for account-level shared negative lists, implying when it should be used. It does not explicitly name alternatives or exclusions, but the context is clear enough to differentiate from the sibling list_negative_keywords, which likely handles individual negative 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the input constraints, optionality of path1/path2, and the return value (new ad id). It does not mention permissions or error behavior, but for a creation tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loaded with the main purpose. Each sentence adds essential information: constraints, optional fields, and return value. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 7 parameters, the description covers the key non-obvious aspects: constraints, optional fields, and return value. Required parameters like account_id and ad_group_id are self-explanatory from their names. The output schema exists but the description's explicit note about returning the ad id is helpful. It's complete 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining validation rules for headlines (3-15, <=30 chars) and descriptions (2-4, <=90 chars), and clarifies that path1/path2 are optional display-url paths. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Add a Responsive Search Ad.' It clearly distinguishes from sibling tools like list_ads or add_keywords. The subsequent constraints and return value also reinforce the tool's singular purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when creating a Responsive Search Ad. It provides necessary requirements (3-15 headlines, 2-4 descriptions) but doesn't explicitly mention alternatives or when not to use it, which is a minor gap. Overall, context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden of disclosing behavior. It reveals that numbers come back as typed (floats/ints, percentages as plain numbers), that TimePeriod is auto-dropped for Summary aggregation, and that predefined_time is ignored when start_date/end_date are given. It does not mention whether the operation is read-only or side-effect-free, but the word 'pull' strongly implies no mutation, and the disclosed quirks are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening and a bulleted list of arguments. Each line is purposeful and compact, avoiding redundancy. It front-loads the main purpose and the most important behavioral note about typed numbers. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and no annotational safety signals, the description covers a wide range of context: parameter meanings, value restrictions, behavioral quirks, and output formatting. Although an output schema exists, the description still clarifies how values are returned, which is helpful. The only minor omission is max_rows, but the rest is sufficiently complete for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains each parameter: account_id, report_type with an enumerated list and per-item meaning, predefined_time with a complete list, start_date/end_date format and requirement, aggregation with enumeration and a behavioral note, campaign_ids, and columns. It misses max_rows, but that parameter is self-explanatory in the schema with a default. The description provides far more than the schema does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Pull a performance report,' a clear verb+resource statement. It further distinguishes report types (search_term, keyword, ad_group, ad, geographic) and explains their specific purposes, which helps differentiate from sibling tools like list_keywords or list_ads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context for choosing report_type (e.g., 'search_term = actual user search queries (best for finding waste + new keywords)') but does not explicitly state when to use this tool over simpler list tools like list_keywords or compare_periods. Usage guidance is implied rather than explicit about alternatives or exclusions.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/james-julius/microsoft-ads-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server