Skip to main content
Glama
get-mcp-ads

Meta Ads by Get MCP Ads

meta interpret experiment results

meta_interpret_experiment_results
Read-onlyIdempotent

Read and interpret A/B test or conversion lift study results with confidence guardrails, cells, objectives, and optional cell entities to assess experiment outcomes.

Instructions

Read and interpret A/B test or conversion lift study results with confidence guardrails, cells, objectives, and optional cell entities.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of returned items or rows. The declared bounds and default apply; use pagination for additional results.
studyIdNoSpecific Ad Study ID to interpret.
adAccountIdNoAd account ID used to discover ad_studies when studyId is omitted.
cellEntityTypeNoEntity type represented by experiment cells.campaigns
includeCellEntitiesNoAlso read campaigns/adsets/adaccounts attached to each study cell.

Output Schema

NameRequiredDescriptionDefault
resultYesOriginal tool result: parsed JSON when the text is JSON, otherwise the text or multiple MCP content blocks. Provider fields depend on the selected query.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • changedOutput schema / properties / result / anyOf
      Previous value: -[
      -  {
      -    "additionalProperties": true,
      -    "properties": {},
      -    "type": "object"
      -  },
      -  {
      -    "items": {},
      -    "type": "array"
      -  },
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "boolean"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]New value: +[
      +  {
      +    "additionalProperties": {},
      +    "properties": {},
      +    "type": "object"
      +  },
      +  {
      +    "items": {},
      +    "type": "array"
      +  },
      +  {
      +    "type": "string"
      +  },
      +  {
      +    "type": "number"
      +  },
      +  {
      +    "type": "boolean"
      +  },
      +  {
      +    "type": "null"
      +  }
      +]
  2. First observedv2.0.1

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is covered. The description adds that interpretation includes confidence guardrails and cell/objective breakdowns, but it doesn't explain what 'confidence guardrails' means operationally, what happens if a study lacks significance, or how discovery via adAccountId differs from a direct studyId read.

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?

A single front-loaded sentence that packs the verb, resource, and scope without filler. It is slightly dense ('confidence guardrails, cells, objectives, and optional cell entities') but nothing is redundant.

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?

An output schema exists so return values needn't be described, and annotations cover safety. What remains missing is routing guidance against the closely related meta_get_study_results and any note on study-state prerequisites, which matters for a tool that must interpret rather than merely fetch.

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 parameter meaning is already fully documented, and no param is described in more depth here. The description's mention of 'cells' and 'optional cell entities' loosely echoes cellEntityType/includeCellEntities but adds no new semantics, so the baseline 3 applies.

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 uses a specific verb pair ('read and interpret') on a specific resource ('A/B test or conversion lift study results') and names the dimensions covered (confidence guardrails, cells, objectives, cell entities). It is clear what the tool does, though it does not explicitly distinguish itself from the very similar sibling meta_get_study_results ('interpret' vs 'get' is only implied).

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?

Usage is only implied: 'interpret' suggests this is the analytical layer over raw study results, but the description never says when to call this versus meta_get_study_results or meta_get_ad_studies, nor when to prefer one over the other. No exclusions or prerequisites (e.g., that a study must have run to completion) are stated.

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