agent1st-ads-mcp

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap. Tools are separated by platform (Meta vs. TikTok) and action type (create, delete, enable, list, pause, update, get stats, check setup, get account info), making it easy for an agent to select the correct one. For example, create_meta_campaign and create_tiktok_campaign are distinct by platform, and pause vs. enable are clearly different actions.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern with platform prefixes where needed. All names use snake_case consistently, and verbs like create, delete, enable, get, list, pause, and update are applied uniformly across platforms (e.g., create_meta_campaign, create_tiktok_campaign). The only exception is check_setup, which still fits the verb_noun style.
Tool Count5/5
With 15 tools, the count is well-scoped for managing ad campaigns across two platforms (Meta and TikTok). Each tool serves a specific, necessary function such as creation, listing, pausing, enabling, updating budgets, getting stats, and checking setup, without redundancy. This aligns with the server's purpose of comprehensive ad campaign management.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for Meta and TikTok ad campaigns, including check_setup for initialization, create, list, get stats, pause/enable for state management, update budget for modifications, and delete for removal. There are no obvious gaps; agents can perform all essential operations from setup to monitoring and adjustment without dead ends.
Average 4.2/5 across 15 of 15 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
With no annotations provided, the description carries the full burden. It discloses the plan requirement ('Starter plan or higher'), which is useful behavioral context. However, it lacks details on rate limits, pagination behavior (despite a 'limit' parameter), error conditions, or what happens if no campaigns exist—leaving gaps for a read operation.
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 appropriately sized with two sentences: one stating the purpose and returned fields, and another providing usage context and prerequisites. It's front-loaded with core functionality, though the second sentence could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no annotations and no output schema, the description covers the basics (purpose, usage, plan requirement) but lacks details on output format (e.g., structure of returned campaigns), pagination beyond the 'limit' parameter, or error handling. Given the complexity and sibling tools, it's adequate but has clear gaps.
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 description coverage is 100%, so the schema already documents both parameters ('limit' and 'status') fully. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining how filtering interacts with the listing or default behaviors beyond 'limit'.
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 verb ('List') and resource ('all campaigns in the Meta ad account') with specific attributes returned (ID, name, status, objective, daily budget). It distinguishes from siblings like 'get_meta_campaign_stats' by focusing on listing rather than detailed statistics, though it doesn't explicitly name alternatives.
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?
It provides clear context for when to use this tool ('Use campaign IDs to get stats, adjust budgets, or pause/enable') and mentions prerequisites ('Requires Starter plan or higher'). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings like 'list_tiktok_campaigns' for TikTok campaigns.
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 provided, the description carries the full burden. It discloses the action ('Activate'), outcome ('starts spending'), and a requirement ('Requires Starter plan or higher'), which are useful behavioral traits. However, it lacks details on permissions, rate limits, error handling, or what happens if the campaign is already active, leaving gaps 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first sentence states the purpose and outcome, and the second provides usage notes and requirements. It is front-loaded with the core action and appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations and no output schema), the description is adequate but incomplete. It covers the purpose, usage, and requirements, but lacks details on behavioral aspects like error cases or return values, which are important for an activation tool. It meets minimum viability but has clear gaps.
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 description coverage is 100%, so the schema already documents the 'campaign_id' parameter fully. The description adds marginal value by mentioning sources for the ID ('from create_meta_campaign or list_meta_campaigns'), but does not provide additional syntax or format details beyond what the schema states. Baseline 3 is appropriate when schema does the heavy lifting.
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 specific action ('Activate a paused Meta campaign'), the resource ('Meta campaign'), and the outcome ('so it starts spending'). It distinguishes from siblings like 'pause_meta_campaign' by specifying activation rather than pausing, and from 'create_meta_campaign' by targeting existing campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use it ('Activate a paused Meta campaign') and prerequisites ('Requires Starter plan or higher'), and hints at alternatives by mentioning 'campaign_id from create_meta_campaign or list_meta_campaigns'. However, it does not explicitly state when NOT to use it or compare directly with all siblings like 'enable_tiktok_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?
No annotations are provided, so the description carries the full burden. It discloses the requirement of a 'Starter plan or higher,' which is useful behavioral context for permissions or access needs. However, it does not cover other traits like rate limits, error handling, or response format, leaving gaps in behavioral understanding.
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 front-loaded with the core purpose in the first sentence, followed by usage context and prerequisites. Every sentence adds value without redundancy, making it efficient and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides basic purpose and usage but lacks details on return values, error cases, or performance implications. It is adequate for a simple read operation but incomplete for full contextual understanding, especially without behavioral or output information.
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 description coverage is 100%, so the schema already documents both parameters (campaign_id and date_preset) with their types and descriptions. The description does not add any parameter-specific information beyond what the schema provides, such as format details or examples, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get performance metrics') and resource ('for a Meta campaign'), listing exact metrics like impressions, clicks, spend, CTR, CPM, and conversions. It distinguishes from siblings by focusing on Meta campaign statistics rather than TikTok campaigns or other operations like creation, deletion, or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool ('Use to evaluate performance before budget decisions'), but it does not explicitly state when not to use it or name specific alternatives. It implies usage for Meta campaigns only, which helps differentiate from TikTok-related siblings, but lacks explicit exclusions or comparisons.
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 describes the tool's behavior (verifying license and platform connections, showing plan-based availability) but lacks details on error handling, response format, or any side effects. The description doesn't contradict annotations (none exist), but it's moderately informative without rich 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the key directive ('ALWAYS call this first'). All sentences are relevant, with no wasted words. It could be slightly more structured (e.g., separating purpose from instructions), but it's efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple verification with no parameters) and lack of annotations/output schema, the description is reasonably complete. It explains what the tool does and when to use it, though it could benefit from mentioning what the output might look like (e.g., a status report). For a zero-param tool, this is adequate.
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 tool has 0 parameters, and schema description coverage is 100%. The description doesn't need to explain parameters, so it appropriately focuses on usage and purpose. Baseline for 0 parameters is 4, as it avoids unnecessary parameter discussion.
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's purpose: verifying license tier and connected ad platforms, and showing available features based on plan. It uses specific verbs ('verifies', 'shows') and identifies the resource (license and platform status). However, it doesn't explicitly distinguish this from sibling tools like 'get_ad_account_info', which might provide related but different information.
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 usage guidance: 'ALWAYS call this first' and 'Use this before any other tool.' It establishes a clear prerequisite context for all other operations, though it doesn't name specific alternatives or exclusions beyond the general directive.
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 provided, the description carries the full burden. It discloses the plan requirement, which is useful behavioral context. However, it doesn't mention other traits like whether this is a mutating operation (implied by 'Activate'), error conditions, or rate limits, leaving gaps for a tool that likely modifies campaign state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. The first sentence states the purpose and outcome, and the second adds critical context (plan requirement), making it front-loaded and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (enabling a campaign), no annotations, and no output schema, the description is fairly complete. It covers the purpose, outcome, and a key prerequisite, but lacks details on return values, error handling, or side effects, which would be helpful for full contextual understanding.
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 description coverage is 100%, so the schema already documents the single parameter 'campaign_id'. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or validation rules, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Activate') on a specific resource ('a disabled TikTok campaign') with the outcome ('so it starts running'). It distinguishes from sibling tools like 'pause_tiktok_campaign' by focusing on enabling rather than pausing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context for when to use ('Requires Pro plan or higher ($69/mo)'), which helps the agent understand prerequisites. However, it doesn't mention alternatives like 'create_tiktok_campaign' for new campaigns or specify when NOT to use it (e.g., if already enabled).
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 a behavioral trait (requires Pro plan or higher) and implies read-only behavior, but lacks details on rate limits, pagination, or error handling. It adequately covers basic usage but misses deeper operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste, front-loaded with the core purpose and followed by essential prerequisite information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and no annotations or output schema, the description is reasonably complete. It covers purpose, attributes returned, and a key requirement, though it could benefit from mentioning return format or limitations.
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 description coverage is 100%, so the schema already documents the 'limit' parameter. The description does not add any parameter-specific information beyond what the schema provides, but it doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all campaigns in the TikTok ad account') with specific attributes returned (campaign ID, name, status, objective, and budget). It distinguishes from sibling tools like 'list_meta_campaigns' by specifying TikTok campaigns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to list TikTok campaigns with specific attributes) and mentions a prerequisite (Pro plan or higher). However, it does not explicitly state when not to use it or name alternatives among 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?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: campaigns are created in DISABLE state, requires Pro plan or higher ($69/mo), and mentions TikTok minimum budget constraint. It doesn't cover error handling or response format, but provides substantial operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core functionality in the first clause, followed by important operational details. Every sentence adds critical information with zero waste - state, activation method, budget constraint, and plan requirement.
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 creation tool with no annotations and no output schema, the description provides excellent context about the creation state, activation requirements, budget constraints, and plan prerequisites. It could mention what happens on success/failure or return format, but covers most critical operational aspects well.
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 description coverage is 100%, so the schema already documents all 7 parameters thoroughly. The description adds minimal parameter-specific information beyond reinforcing the TikTok minimum budget constraint. Baseline 3 is appropriate when schema does the heavy lifting.
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 complete TikTok ad campaign with campaign, ad group with targeting, and ad in one call. It specifies the resource (TikTok ad campaign) and distinguishes from siblings like create_meta_campaign by explicitly mentioning TikTok.
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 this tool (creating TikTok campaigns) and mentions the need to call enable_tiktok_campaign to activate. It doesn't explicitly state when not to use it or compare with alternatives like create_meta_campaign, but the TikTok-specific focus provides good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and adds valuable behavioral context beyond the schema. It discloses the Pro plan requirement (authentication/access level constraint) and lists the specific metrics returned, which helps understand what data will be available.
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 with zero waste. First sentence states purpose and metrics, second sentence provides crucial usage requirement. Every word earns its place.
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 read operation with 100% schema coverage but no annotations or output schema, the description does well by listing metrics and access requirements. However, it doesn't mention data freshness, rate limits, or error conditions that would be helpful for a stats retrieval 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 description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get performance metrics') and the resource ('TikTok campaign'), listing specific metrics (impressions, clicks, spend, CTR, CPC, conversions). It distinguishes from siblings like 'get_meta_campaign_stats' by specifying TikTok platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context by stating 'Requires Pro plan or higher ($69/mo)', which helps determine when this tool can be used. However, it doesn't explicitly mention when to use alternatives like 'get_meta_campaign_stats' or other TikTok campaign tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: immediate effect ('Takes effect immediately'), minimum constraint ('Minimum $1/day'), and permission requirements ('Requires Starter plan or higher'). It doesn't cover rate limits or error conditions, but provides solid operational 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences with zero waste—each adds distinct value: action, timing, usage scenarios, constraints, and requirements. The description is front-loaded with the core purpose and efficiently structured.
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 mutation tool with no annotations and no output schema, the description provides good coverage of what the tool does, when to use it, and key constraints. It could be more complete by mentioning what happens to existing budget settings or potential side effects, but it's substantially adequate given the context.
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 description coverage is 100%, so the schema already fully documents both parameters. The description adds minimal value beyond the schema—it reinforces the minimum budget constraint but doesn't provide additional semantic context about parameter usage or implications.
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 specific action ('Change the daily budget'), resource ('Meta campaign'), and scope ('daily budget'), distinguishing it from siblings like create_meta_campaign or pause_meta_campaign. It goes beyond just restating the name by specifying what aspect of the campaign is being updated.
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 on when to use it ('Increase to scale a winning campaign, decrease to throttle spend') and mentions a prerequisite ('Requires Starter plan or higher'). However, it doesn't explicitly state when NOT to use it or name alternatives like update_tiktok_campaign_budget for comparison.
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 effectively adds context beyond the input schema by specifying the minimum budget constraint ('TikTok minimum is $20/day') and the subscription requirement ('Requires Pro plan or higher ($69/mo)'), which are crucial for correct usage. It doesn't cover all potential behavioral aspects (e.g., rate limits, error responses), but provides substantial value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two sentences that each earn their place: the first states the core purpose, and the second adds critical constraints. There is zero wasted verbiage, making it highly efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation operation with no annotations and no output schema), the description does a good job of covering key aspects: purpose, constraints, and prerequisites. However, it lacks details on the mutation's effects (e.g., whether changes are immediate, reversible, or have side effects) and expected return values, which would be needed for full completeness.
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?
The input schema has 100% description coverage, so the schema already documents both parameters adequately. The description adds minimal parameter semantics by reinforcing the minimum budget constraint for 'budget_usd', but doesn't provide additional meaning beyond what the schema specifies. This meets the baseline expectation when schema coverage is high.
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 specific action ('Change the daily budget') and target resource ('a TikTok campaign'), distinguishing it from sibling tools like 'update_meta_campaign_budget' by specifying the TikTok platform. It goes beyond just restating the name/title by adding meaningful context about the budget change.
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 this tool (to change TikTok campaign budgets) and explicitly mentions prerequisites ('Requires Pro plan or higher ($69/mo)'). However, it doesn't explicitly state when not to use it or name alternatives (e.g., when to use 'update_meta_campaign_budget' instead), which prevents a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses key behavioral traits: the campaign is created in PAUSED state (requiring separate activation), has a minimum budget constraint, and requires a specific subscription plan. It doesn't mention rate limits, error handling, or response format, leaving some gaps.
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?
Front-loaded with core purpose, followed by essential behavioral details in a single, efficient sentence. Every clause adds value with no wasted words, making it easy to scan.
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 complex creation tool with no annotations or output schema, the description covers purpose, usage context, and key constraints well. It could improve by hinting at return values or error cases, but it's largely complete given the structured input schema.
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 description coverage is 100%, so the schema fully documents all 9 parameters. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('complete Meta ad campaign') with specific scope ('campaign + ad set with targeting + creative + ad'), distinguishing it from siblings like 'create_tiktok_campaign' (different platform) and 'enable_meta_campaign' (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Create a complete Meta ad campaign in one call') and when not to use ('Created in PAUSED state. Call enable_meta_campaign to activate'), with clear prerequisites ('Requires Starter plan or higher') and constraints ('Minimum budget $1/day').
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 so effectively: it discloses the irreversible nature ('Cannot be undone'), the destructive scope (deletes campaign, ad sets, and ads), and authorization requirements (Starter plan or higher). It lacks details on rate limits or error handling, but covers key behavioral traits.
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 with zero waste: the first states the action and scope, the second warns about irreversibility and provides an alternative, and the third specifies prerequisites. Each sentence adds critical information, making it front-loaded and efficient.
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 destructive tool with no annotations and no output schema, the description is largely complete: it covers purpose, usage, behavioral risks, and prerequisites. It could mention response format or error cases, but given the simplicity (one parameter, no output schema), it provides sufficient context for safe use.
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 description coverage is 100%, so the schema already documents the single parameter (campaign_id). The description adds no additional parameter details beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('permanently delete') and resource ('Meta campaign and all its ad sets and ads'), distinguishing it from siblings like pause_meta_campaign. It goes beyond the tool name by specifying the scope of deletion.
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?
It explicitly provides when to use this tool (for permanent deletion) versus an alternative (pause_meta_campaign for temporary stopping), and includes prerequisites (requires Starter plan or higher), offering comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: the immediate spending stop, preservation of campaign and settings, and the plan requirement. However, it doesn't mention error conditions, rate limits, or authentication needs, leaving some gaps.
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 concise sentences with zero waste: first states purpose and immediate effect, second clarifies preservation and alternative tool, third specifies plan requirement. Every sentence adds essential 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?
For a single-parameter mutation tool with no annotations and no output schema, the description provides good coverage: purpose, immediate effect, state preservation, alternative tool, and plan requirement. It doesn't describe return values or error cases, but given the simplicity, it's mostly complete.
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 description coverage is 100%, so the schema already documents the single parameter. The description doesn't add any parameter-specific information beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('pause'), target resource ('live Meta campaign'), and immediate effect ('stop all spending immediately'). It distinguishes from sibling tools like enable_meta_campaign and pause_tiktok_campaign by specifying the platform and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool ('pause a live Meta campaign') and when to use an alternative ('use enable_meta_campaign to resume'). Also specifies prerequisites ('Requires Starter plan or higher'), providing clear guidance on usage context.
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. It discloses key behavioral traits: the action is a mutation (pause), it preserves settings, it stops spending, and it has a plan requirement. However, it doesn't mention potential side effects like timing delays or error 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by additional context in a structured way. Every sentence adds value: the first states the action and outcome, the second provides behavioral context and alternative, and the third specifies requirements.
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 mutation tool with no annotations and no output schema, the description does well by covering purpose, usage, and key behaviors. However, it lacks details on return values or error handling, which would be helpful given the complexity of pausing a campaign.
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 description coverage is 100%, so the schema already documents the single parameter 'campaign_id'. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('pause') on a specific resource ('running TikTok campaign') with the explicit outcome ('stop all spending'). It distinguishes from the sibling tool 'enable_tiktok_campaign' by mentioning it as the alternative for resuming.
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?
It provides explicit guidance on when to use this tool (to pause a running campaign and stop spending) and when to use an alternative (use enable_tiktok_campaign to resume). It also specifies prerequisites (requires Pro plan or higher).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and discloses key behavioral traits: it's a read operation (implied by 'Get'), requires license authentication, and serves a verification purpose. It doesn't mention rate limits or error handling, but covers essential 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose and scope, second provides usage context and prerequisite. Front-loaded with core functionality, appropriately sized for a simple tool.
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 zero-parameter tool with no output schema, the description provides complete operational context: what it returns, when to use it, and authentication requirements. It doesn't specify output format details, but given the tool's simplicity, this is adequate.
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 tool has 0 parameters with 100% schema coverage, so no parameter documentation is needed. The description appropriately focuses on what the tool returns rather than inputs, establishing a baseline of 4 for zero-parameter tools.
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 specific action ('Get') and resources ('current balance, total spend, currency, and account status for all connected ad accounts'), specifying platforms ('Meta and/or TikTok'). It distinguishes from siblings by focusing on account-level information rather than campaign operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('Call before creating campaigns to confirm account is active and has sufficient funds') and provides a prerequisite ('Requires valid license'), giving clear operational context without alternatives needed since it's the only account info tool.
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:

[![agent1st-ads-mcp MCP server](https://glama.ai/mcp/servers/Nolas-Shadow/agent1st-ads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Nolas-Shadow/agent1st-ads-mcp)

Score Badge

Copy to your README.md:

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

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