Returns connection status and URLs. When all providers are connected, returns authenticated:true and empty pending[]. When credentials are missing, returns connect_url for the toolkit and per-install URLs.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description reveals concrete output behavior: authenticated flag, empty pending array, and URL generation when credentials are required. This is valuable and not duplicate of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two efficient, front-loaded sentences. The purpose is given first, and each sentence adds meaningful behavioral detail without wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless status-checking tool with no output schema, this description captures the main result states and the relevant URLs well. It is sufficient for the agent to understand the expected outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema documents that cleanly. Baseline for no-param tools is 4, and no additional parameter explanation is needed in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns connection status and URLs, providing a specific verb + resource outcome. It also differentiates connect from authenticator by framing it as a read-only status check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The conditional context ('When all providers are connected...', 'When credentials are missing...') makes it clear when this tool provides useful status information. It does not explicitly name alternatives or say when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools are near-identical variants of the same action, with only a `[Flattened action]` marker distinguishing e.g. the four `meta_ads_campaign_write_*` tools and the three `meta_ads_creative_write_*` tools. The reporting tools also overlap: `meta_ads_ads`, `meta_ads_realtime`, `meta_ads_today`, and `meta_ads_roas` all return spend/performance data, making selection genuinely ambiguous. Unrelated platform tools like `marketplace` and `toolkit_info` are mixed in, further muddying what the server is for.
Most Meta Ads tools follow a readable `meta_ads_<resource>_<action>` snake_case convention, and write actions are reasonably predictable. However, there are inconsistencies: `meta_ads_ads` vs `meta_ads_audience`, `meta_ads_business_list` vs `meta_ads_business_accounts` vs `meta_ads_list_accounts`, and `meta_ads_adset_delete` vs the `meta_ads_adset_write_*` grouping. The unbranded platform tools (`connect`, `report_bug`, `show_version`) also break the pattern.
44 tools is far above the recommended range and pushes the server into unwieldy territory. The count is inflated because flattened actions were expanded into separate tools: the campaign write tool appears four times, audience write twice, adset create/update twice, creative tools three times, media upload three times, and business/pages actions once per variant. A consolidated action-based design could reduce real surface area to roughly 15-20 tools.
The core Meta Ads lifecycle is well covered: campaigns, ad sets, creatives/ads, custom audiences, media upload, business managers, pages, and reporting all have create/read/update/delete or equivalent destinations. The main gaps are no direct `list_ad_sets` tool, no `remove_users` for audiences, and an apparent reference to a nonexistent `meta_ads_media` tool for listing uploaded media. These are noticeable but usually workaroundable.