Skip to main content
Glama

Metadata MCP Connector

Get Experiment Performance Statistics

experiment_performance_stats
Read-only

Experiment-level performance statistics from Metadata.io Experiments API. Rows carry no lead or conversion date.

Input Schema

NameRequiredDescriptionDefault
nameNoExperiment name filter, matched as ONE substring per request. Use 'name' field (NOT experimentName) for specific experiment questions. Can be a single string or an array of strings for multiple experiments; an array is queried one name per request and the results are merged. Do NOT add additional parameters when filtering by specific experiment name.
pageNoPage number for pagination (0-based). Use it with the 'size' you already sent to reach rows beyond the first page when 'totalElements' exceeds the rows returned.
sizeNoResults per page from 1 to 100; default 10. Use successive zero-based page values and response pagination metadata for more results.
sortNoSorting parameter. CRITICAL RULES: 'cpl2Score,desc' for Lead Generation or unspecified campaigns, 'cpc2Score,desc' for Brand Awareness, 'triggeredAmount,desc' for ROI/pipeline questions, 'oppsAmount,desc' for influenced pipeline, 'conversionRate,desc' for conversion rate, 'internalStatus,desc' for active experiments, use specific metric,desc when asked (e.g. 'impressions,desc', 'mqls,desc').cpl2Score,desc
goalsNoCampaign goal type. RULES: 'CPL' for Lead Generation campaigns, 'CTR' for Brand Awareness campaigns. Do NOT include for unspecified campaign types. When multiple metrics involved, use only the first metric's corresponding goal.
adNameNoFilter by specific ad name (e.g., 'Sifted_WorkShift_Ad5_Beige'). Use 'adName' field when question asks about specific ad names.
minCpcNoMinimum cost per click threshold (whole dollars). OPTIONAL filter: omit it unless the question needs one. Do NOT set it for Lead Generation or unspecified campaign types.
minCplNoMinimum cost per lead threshold (whole dollars). OPTIONAL filter: omit it unless the question needs one. It excludes every zero-lead experiment, whose CPL is undefined, so never pair it with minLeads=0 and never set it for Brand Awareness.
endDateNoEnd date in ISO 8601 format. Must end on last hour of date (e.g., '2024-11-21T23:59:59.999Z'). CRITICAL: Do NOT include if timeFrame parameter is used. For specific campaigns/experiments without timeframe, omit this parameter.
metricsNoList of metrics for secondary ordering when question involves multiple metrics (e.g., ['cpl', 'ctr', 'leads']). Only include when analyzing more than one metric simultaneously. Do NOT include for single metric questions.
channelsNoMarketing channels to include
minLeadsNoMinimum leads threshold. OPTIONAL filter: omit it unless the question needs one. Useful to keep only converting experiments in a Lead Generation ranking. Do NOT set it for Brand Awareness, nor when the user asks about zero-lead or 'no results' experiments.
minSpendNoMinimum spend threshold. OPTIONAL filter: omit it unless the question needs one. Useful when ranking Lead Generation performance and non-delivering experiments would be noise. Do NOT set it when the user asks about experiments with no spend, no leads or no results.
minClicksNoMinimum clicks threshold. OPTIONAL filter: omit it unless the question needs one. Useful in a Brand Awareness ranking. Do NOT set it for Lead Generation.
offerNameNoFilter by specific offer name (e.g., 'AMER_ZO_EN_HBR Reimagining Work'). Use this field when question mentions specific offers.
startDateNoStart date in ISO 8601 format (e.g., '2024-10-18T00:00:00.000Z'). CRITICAL: Do NOT include if timeFrame parameter is used. Use last year of data if period cannot be inferred from question. For specific campaigns/experiments without timeframe, omit this parameter.
timeFrameNoTimeframe aggregation. CRITICAL RULES: Use ONLY for WEEK or QUARTER questions. NEVER use 'YEAR' - use startDate/endDate instead. If timeFrame is included, DO NOT add startDate or endDate parameters under any circumstances.
offerTypesNoOffer types filter. RULES: ['LP'] for lead gen forms/landing pages questions, ['LP', 'LG'] as default when offer types mentioned. LP=Landing Pages, LG=Lead Gen forms. Should NOT be empty when included.
audienceNameNoFilter by target audience name (e.g., 'WTS EMEA Jan25_EMEAPitchbook')
campaignNameNoCampaign name filter. Use when question is about specific campaign(s). Can be single string or array ['campaign1', 'campaign2'] for multiple campaigns. Do NOT include additional parameters when filtering by specific campaign name.
visibilitiesNoVisibility status filter. The platform knows only VISIBLE (live) and ARCHIVED; there is no HIDDEN value and sending one is rejected with a 400.
audienceTypesNoComma-separated list of audience types (e.g., 'Spotlight Retargeting Contacts (Dynamic),Technographic (Aberdeen)')
minAudienceSizeNoMinimum audience size. OPTIONAL filter: omit it unless the question needs one.
imageLibraryNameNoFilter by creative/image name (e.g., 'JP - Square-Ad15.png'). Use 'imageLibraryName' field when question asks about specific creative names.
launchedExperimentStatusesNoFilter experiments by launch status. DEFAULT when omitted: successfully-launched experiments only (Active, WithoutSpend, Paused, Completed) — Failed and Disconnected are EXCLUDED, because a failed/non-launched experiment has 0 leads and is a non-starter, not a 'bottom performer'. Pass values explicitly to override: ['Active'] for live only, or ['Failed'] / ['Failed','Disconnected'] when the user explicitly asks which experiments failed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / size / description
      Previous value: -"Number of results per page. RULES: size=1 for 'top' singular questions, size=requested number for 'top X' questions, size=50 for plural questions (e.g. 'campaigns'), size=30+ for multiple metrics analysis, size=15 as default when not specified. Raise it freely for full-dataset analytics — there is no small ceiling."New value: +"Results per page from 1 to 100; default 10. Use successive zero-based page values and response pagination metadata for more results."
    • changedInput schema / properties / size / maximum
      Previous value: -10000New value: +100
  2. First observed

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that rows carry no lead or conversion date, but it does not describe return shape, pagination behavior, or other operational traits beyond that single limitation.

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 two short sentences and front-loads the purpose before adding the row limitation. It is efficient and has no filler, though it could do more to route among sibling statistics tools.

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 25-parameter analytics tool in a crowded set of metrics siblings, the description is under-specified on selection context. The schema is rich and annotations cover safety, but the description does not explain when this tool should be preferred over performance_metrics or other stats tools, nor does it clarify the expected result context beyond the lead/conversion-date caveat.

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 all 25 parameters already have detailed semantic documentation in the schema. The description does not add parameter-specific guidance beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 states a specific verb+resource: experiment-level performance statistics from the Metadata.io Experiments API. It is clear what the tool returns, but it does not distinguish itself from related sibling tools such as performance_metrics, deep_funnel_stats, or experiments_keywords_stats.

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 offers no explicit when-to-use guidance and names no alternatives. The caveat that rows carry no lead or conversion date implies a limitation, but it does not tell the agent which sibling tool to choose when lead or conversion dates are needed.

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