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.

USE FOR:

  • Experiment-level metrics (spent, leads, impressions, clicks, cpl, ctr, mql)

  • Campaign comparisons (A vs B, time periods)

  • Triggered/influenced opportunities analysis

  • Pipeline opportunity analysis from campaigns

  • Campaign ingredients (audience size, channel, audience/ad/offer used)

  • ROI analysis, trend analysis, top performers

  • Creative usage by experiments

  • Filtering by experiment/campaign names

  • Filtering by launch status via launchedExperimentStatuses (FAILED / DISCONNECTED experiments are excluded by default — see that parameter)

NOT FOR:

  • Experiment pacing status ("which experiments are underpacing")

  • Ad-level triggered opportunities

  • Ingredient-level analysis (use performance_metrics)

RETURNED DATA: spent, clicks, impressions, leads, mqls, cpl, cpc, cpm, ctr | opens, sends, actionClicks, costPerOpen, costPerSend (CONVO/MESSAGE ads) | adTypes (list of ad types in this experiment) | triggeredAmount, oppsAmount, cpMql, mqlRate, conversionRate | experimentName, campaignName, audienceName, offerName, adName | audienceTypes, audienceSize, channel, goal | imageLibraryName | startDate, endDate, pacing, quarterIndex

CONVO/MESSAGE AD CAVEAT: when adTypes contains CONVO or MESSAGE, success is measured by opens, sends, and actionClicks (and costPerOpen / costPerSend), NOT clicks/ctr/cpc. An experiment with $100K+ spend and 0 clicks where adTypes includes CONVO can be a top performer — assess on the right metric. To rank conversational performance explicitly, use sort='actionClicks,desc' or sort='opens,desc' instead of the lead-gen defaults.

LINK FORMAT: /hub/advertise/experiments?name={wizExperimentName}

RULES:

  • 'cpl2Score,desc' for Lead Gen/unspecified, 'cpc2Score,desc' for Brand Awareness

  • 'triggeredAmount,desc' for ROI/pipeline, 'oppsAmount,desc' for influenced pipeline

  • size=1 for 'top' singular, size=requested for 'top X', size=50 for plural, size=15 default

  • failed/non-launched experiments are excluded by default; pass launchedExperimentStatuses=['Failed'] ONLY when the user explicitly asks about failures

  • this layer returns EVERY launched experiment with delivery in the window, including zero-lead and zero-spend ones, unless you set a min* filter yourself. An empty or short result means nothing matched the filters you sent, NOT that campaign-level reporting is broken or stale; re-run without the min* filters before telling the user anything is wrong

  • the response is ONE page: 'totalElements' is the full match count and 'totalPages' the page count at the requested 'size'. When totalElements exceeds the rows returned, fetch the next 'page' or repeat with a larger 'size' before compiling a full list; re-issuing the identical call returns the identical page

Input Schema

TableJSON 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.
sizeNoNumber 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.
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. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds substantial behavioral context: it lists returned data fields, explains the CONVO/MESSAGE metric switch, warns that zero-lead experiments are returned, clarifies that empty results mean filters matched nothing rather than broken reporting, and details pagination behavior (one page, totalElements vs totalPages). This far exceeds the annotation baseline and provides essential operational understanding.

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 very long but well-structured with clear sections (USE FOR, NOT FOR, RETURNED DATA, CONVO/MESSAGE AD CAVEAT, LINK FORMAT, RULES). It is front-loaded with purpose and each rule serves a distinct need for a 25-parameter tool. The length is justified by complexity, but it could be tightened slightly without losing value, so 4 rather than 5.

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

Completeness5/5

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

Given the tool's complexity (25 optional parameters, no output schema), the description is remarkably complete. It lists all returned metrics, explains edge cases (CONVO/MESSAGE ads, failed experiments), provides pagination guidance, and includes the link format. An agent has everything needed to call the tool correctly and interpret results, even without an output schema.

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

Parameters5/5

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

Schema coverage is 100% with each parameter having a description, but the tool description adds significant rules on top: size guidelines (1/50/15), sort selections per question type, critical warnings (e.g., minCpl excludes zero-lead experiments, minLeads=0 never paired with minCpl), and when to omit parameters (e.g., do not include timeFrame with startDate/endDate). This enriches parameter meaning far beyond the schema, making it highly actionable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns experiment-level performance statistics from Metadata.io Experiments API. It enumerates specific use cases (metrics, comparisons, pipeline analysis, creative usage) and explicitly excludes pacing status and ingredient-level analysis, naming the alternative tool (performance_metrics) for that scope. This precisely distinguishes it from the many sibling tools.

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

Usage Guidelines5/5

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

The description provides an explicit 'USE FOR' and 'NOT FOR' list, plus detailed rules for sort, size, and filter usage. It names performance_metrics as the tool for ingredient-level analysis, and the CONVO/MESSAGE caveat instructs when to use specific sorts. This gives an agent unambiguous decision criteria for when to select this tool versus alternatives.

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