MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
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?
Annotations already provide idempotentHint and non-destructive, but the description adds meaningful context: configuration yields a permanent non-expiring connection, while pasting a token is session-only. Depth is good though it does not explain all error/edge-case behavior.
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?
Two sentences carry a lot of useful information without significant waste. The wording 'log in in the browser' is slightly awkward and the first phrase could be cleaner, but everything included is relevant to an agent.
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 simple optional-parameter auth tool, the description covers both invocation styles and configuration options. It omits what a successful token response returns, but there is no output schema and the overall flow is reasonably complete for decisive agent use.
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 schema only names the optional token with no description, but the tool description thoroughly explains that token is a JWT pasted by the user and that omitting it obtains the login link. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: authenticating an MCP.AI server for IDE agents by either returning a login link or accepting a pasted token. It is concrete and distinguishes itself from the ADS-related siblings, despite the separate 'connect' tool.
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 description explicitly recommends the best-practice configuration method (permanent header), explains when to call with a pasted token for session-only login, and specifies calling with no args to get a link. This gives an agent actionable guidance on when and how to use the tool.
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.