Skip to main content
Glama

AdsAgent — Meta Ads MCP

products_get_funnel_candidates

Read-only

List ordered funnel-step candidates with 7-day and 30-day counts

Input Schema

NameRequiredDescriptionDefault
limitNo
cursorNo
product_refNo
product_nameNo
include_funnel_historyNo

Output Schema

NameRequiredDescriptionDefault
messageNo
retryableNo
support_refNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / connection_context
      Removed value: -{
      -  "pattern": "^mctx_v1_[0-9a-f]{64}$",
      -  "type": "string"
      -}
  2. Changed1 schema field changed
    • addedInput schema / properties / include_funnel_history
      Added value: +{
      +  "default": false,
      +  "type": "boolean"
      +}
  3. Added

TDQS

C2.7/5.0
Behavior3/5

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

Annotations already declare this is a read-only, non-destructive, closed-world operation, so the safety profile is covered. The description adds that results are ordered and include 7-day and 30-day counts, but says nothing about ordering basis, pagination behavior, or what identifies a candidate.

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?

It is a single front-loaded sentence with no filler. The issue is under-specification rather than verbosity, so it scores well on conciseness alone.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a five-parameter tool with zero schema descriptions, the description leaves too much unresolved: how to specify the product, what the history flag does, and how pagination works. The output schema may explain return values, but input-side completeness is inadequate.

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

Parameters1/5

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

Schema description coverage is 0% across five parameters, so the description must compensate and does not. It never explains product_ref vs. product_name, what include_funnel_history changes, or how limit and cursor paginate.

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?

States a specific verb ("List") and resource ("ordered funnel-step candidates") and adds the key measures (7-day and 30-day counts). It is clear what the tool returns, though it does not distinguish itself from related siblings such as products_get_funnel_values or products_funnel_prepare.

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

Usage Guidelines2/5

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

The description gives no when-to-use guidance, no prerequisites, and no alternatives. An agent cannot tell from this text whether to call it before products_funnel_prepare or how it differs from products_get_funnel_values.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources