Metadata MCP Connector

Create Marketing-Automation Contacts Audience

create_marketing_automation_contacts_audience

Create a Marketing-Automation-contacts custom audience (platform customAudienceType MA_CONTACTS_STATIC or MA_CONTACTS_DYNAMIC) from a provider library list.

            This is one of the audience types eligible for Microsoft Ads (Customer Match). Use it when a user wants a Marketing-Automation-sourced contacts audience, including for a Microsoft Ads campaign.

            PREREQUISITE:
              • The provider (HUBSPOT or MARKETO) MUST be connected — the platform validates this and returns a clear error if not.
              • A library_list_id from list_marketing_automation_lists — do NOT invent one. For HubSpot the list must be DONE; for Marketo READY.

            VARIANT (mirrors the UI's static/dynamic choice):
              • STATIC  → MA_CONTACTS_STATIC — snapshot at creation, does not refresh.
              • DYNAMIC → MA_CONTACTS_DYNAMIC — refreshes as the provider data changes.
              • If the user did not say which, ASK — do NOT default and do NOT infer it from the source list's type. A HubSpot STATIC_LIST is not the same choice as a STATIC (snapshot) audience; the audience variant is the user's call, independent of the list's type.

            ASYNC: the platform creates the audience in the background and returns a flow id, NOT a ready audience id. The audience appears under the account's Marketing-Automation audiences once the flow completes, and its contact count fills in then. Do not expect to associate it to a campaign in the same turn.

            PARAMETERS:
              • custom_audience_name (required): the audience display name — must NOT contain '/'.
              • library_list_id (required): id from list_marketing_automation_lists.
              • provider (required): HUBSPOT or MARKETO.
              • variant (required): STATIC or DYNAMIC.
              • list_name (optional): the source list's own name (from the lookup), forwarded to the flow.

            RETURNS: { id, name, status, createdDate, audience_type, async: true } — `audience_type` is the MA_CONTACTS_* you created and `id` is a creation/flow id, not associable yet.

Input Schema

TableJSON Schema

Name	Required	Description
`variant`	Yes	STATIC = snapshot (MA_CONTACTS_STATIC); DYNAMIC = refreshing (MA_CONTACTS_DYNAMIC). Ask the user if unspecified.
`provider`	Yes	The Marketing-Automation provider that owns the list.
`list_name`	No	Optional: the source list's own name, from list_marketing_automation_lists.
`library_list_id`	Yes	The library list id from list_marketing_automation_lists.
`custom_audience_name`	Yes	Audience display name. Must not contain '/'.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description clearly discloses async creation: the platform returns a flow id, not a ready audience id, and the audience is not associable to a campaign in the same turn. It also details state semantics (STATIC snapshot vs DYNAMIC refresh), post-completion contact-count fill, and provider validation with clear errors -- substantial context far beyond the minimal annotations.

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?

Though long, the description is structured into PREREQUISITE, VARIANT, ASYNC, PARAMETERS, and RETURNS sections, with the most decision-critical rule (variant must be asked, not inferred) prominently placed. Every section conveys behavior needed for correct use rather than repeating schema filler.

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?

For a mutating async tool with 5 parameters and no output schema, the description is unusually complete: it covers prerequisites, provider states, source-of-truth for library_list_id, variant policy, async return shape, and post-completion behavior. An agent has what it needs to invoke the tool and set user expectations correctly.

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?

Even though the input schema covers 100% of parameters, the description adds real semantics: library_list_id must come from list_marketing_automation_lists and must not be invented, variant must be ASKED if unspecified and never inferred from the list type, and HubSpot/Marketo lists must be in DONE/READY status. This materially improves correct invocation.

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 opens with a specific verb and resource: 'Create a Marketing-Automation-contacts custom audience ... from a provider library list,' and names the exact platform customAudienceType variants. It also situates the audience as eligible for Microsoft Ads Customer Match, which differentiates it from sibling audience-creation tools even without naming them.

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?

It gives an explicit trigger: 'Use it when a user wants a Marketing-Automation-sourced contacts audience, including for a Microsoft Ads campaign.' It also provides clear prerequisites and a decision rule (ASK if variant unspecified), but it does not explicitly name excluded alternatives or say when a different audience tool should be used.

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

All Metadata MCP Connector tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?