Skip to main content
Glama
abdulhadi-98

Social MCP

by abdulhadi-98

meta_get_insights

Read-only

Retrieve performance insights for a Meta ad account, campaign, ad set, or ad with date presets, breakdowns, and daily increments to analyze advertising results.

Instructions

Performance insights for an ad account (act_...), campaign, ad set or ad.

date_preset: today, yesterday, last_7d, last_14d, last_30d, this_month, last_month, maximum (ignored if since/until given). breakdowns e.g. ["age","gender"], ["publisher_platform"], ["country"]. time_increment "1" for daily rows.

Input Schema

NameRequiredDescriptionDefault
levelNocampaign
limitNo
sinceNo
untilNo
fieldsNo
object_idYes
breakdownsNo
date_presetNolast_30d
time_incrementNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare a non-destructive read operation, so the description's main added value is the interaction note that date_preset is ignored when since/until are supplied. It does not mention pagination behavior, limit semantics, or what the output contains beyond the existence of an output schema.

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?

Front-loaded with the core purpose and then compact parameter hints; no filler sentences. It is appropriately brief for a tool definition, though the terse parameter lines could be slightly more structured.

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?

This is a 9-parameter read tool with zero schema descriptions, and the description only explains a subset of parameters. An agent can infer some usage from examples, but key parameters such as level, limit, and fields remain undocumented anywhere in the definition.

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 0%, so the description must carry parameter meaning. It partially documents date_preset values, breakdown examples, and time_increment, but leaves level's enum meaning, limit, fields, since/until formats, and object_id format largely unexplained.

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+resource: 'Performance insights' for an ad account/campaign/ad set/ad. An agent can tell this is Meta insights rather than a listing or mutation tool, though no sibling is explicitly named or contrasted.

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 implied through parameter guidance (date_preset values, breakdown examples, time_increment for daily rows), but there is no explicit when-to-use vs alternatives such as meta_list_entities or google_ads_campaign_performance, and no stated exclusions.

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