Skip to main content
Glama
atmosphere-ai

AdvisorPPC X Ads MCP Server

List funding instruments

x_ads_list_funding
Read-only

Check an ad account's funding status by listing funding instruments with able_to_fund flag and reasons when not fundable, ensuring payment readiness.

Instructions

How campaigns are paid. Trust able_to_fund=true and empty reasons_not_able_to_fund — NOT description, which for self-serve cards can read '(no payment method has been set up yet)' even when serving. The API exposes one representative instrument for self-serve accounts.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
countNo
cursorNo
account_idYesAds API account id from x_ads_list_accounts, e.g. 18ce55v2od2

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnly/openWorld annotations by warning that the 'description' field can be misleading, instructing the agent to trust able_to_fund and reasons_not_able_to_fund, and noting that self-serve accounts expose only one representative instrument. This is rich, non-obvious 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 compact and front-loaded with the core concept. Every sentence adds value, though the second sentence is dense and the first is a fragment rather than a complete statement.

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?

The description covers the critical interpretation caveats and the self-serve behavior, which is enough for an agent to use the results correctly. It does not describe pagination behavior or output shape, but the readOnly annotation and focused caveats make this largely sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, with count and cursor undocumented. The tool description does not explain these pagination parameters or add any parameter-level meaning, so it 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title provides the verb and resource ('List funding instruments'), and the description adds domain meaning ('How campaigns are paid'). It does not explicitly distinguish this from sibling list tools, but the resource is clearly unique and the caveats clarify what the tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is used when you need to know how campaigns are paid, but it does not state when to prefer it over alternatives or when not to use it. No exclusions or sibling routing are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.