Skip to main content
Glama
get-mcp-ads

Meta Ads by Get MCP Ads

meta get node fields

meta_get_node_fields
Read-onlyIdempotent

Read arbitrary flat fields from any Meta Graph node to access newly released campaign, ad, or creative data without waiting for schema updates.

Instructions

Read arbitrary flat fields from one Meta Graph node. This GET-only escape hatch covers newly released campaign, ad set, ad, creative, audience, catalog, Page, Instagram, pixel, and other accessible node fields without waiting for a fixed MCP schema update.

Input Schema

NameRequiredDescriptionDefault
fieldsYesFlat Graph field names; nested field expansion is intentionally disabled
nodeIdYesGraph node ID, for example a campaign, ad set, ad, creative, Page, IG account, pixel, audience, or catalog ID
includeMetadataNoAsk Graph for field metadata when supported

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

A3.8/5.0
Behavior3/5

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

With readOnlyHint, idempotentHint, and destructiveHint already declared, the safety profile is covered by annotations. The description's 'GET-only' largely restates readOnlyHint and 'nested field expansion is intentionally disabled' is already in the schema, so it adds limited behavioral context. No mention of token/permission requirements per node type or Graph rate-limit implications for an openWorld endpoint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action and resource. The list of node types is long but earns its place by telling the agent the reach of the tool across campaign, ad set, creative, audience, catalog, Page, Instagram, and pixel nodes.

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?

An output schema exists, so return-value explanation is unnecessary, and annotations carry the safety profile. What remains is scope: which node types are reachable and the flat-only constraint, both stated. Auth/permission coverage for arbitrary node types is the one gap worth noting.

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%: nodeId, fields, and includeMetadata all carry their own descriptions and validation patterns. The description adds nothing beyond that, so the baseline 3 for schema-covered params 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?

States a specific verb and resource: 'Read arbitrary flat fields from one Meta Graph node.' The 'escape hatch ... without waiting for a fixed MCP schema update' framing implicitly separates it from the fixed-schema siblings (meta_get_campaigns, meta_get_ads, etc.), but no sibling is named explicitly, so an agent must infer the boundary rather than read it.

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

Usage Guidelines4/5

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

'Escape hatch' plus 'newly released ... fields without waiting for a fixed MCP schema update' gives a clear condition for reaching for this tool: when the field you want isn't in a fixed-schema tool. It stops short of an explicit preference order (e.g. 'prefer meta_get_campaigns for standard campaign fields') and names no when-not cases.

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