Marvento Ads MCP

Official

Overview Schema Source Related Servers Discussions Admin

Assets Create Conversion Action

assets_create_conversion_action

Create Google Ads conversion actions for leads or purchases, enabling campaigns to bid on specific website events and optimize for them.

Instructions

Creates a website conversion action (the thing bidding optimises for).

After creating it, fetch the tag with search on conversion_action selecting conversion_action.tag_snippets and install the event snippet on the site, or fire it through Google Tag Manager.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	Yes	e.g. "Contact form submit".
`category`	No	What the action represents. Leads: SUBMIT_LEAD_FORM, REQUEST_QUOTE, BOOK_APPOINTMENT, PHONE_CALL_LEAD, CONTACT. Sales: PURCHASE.	SUBMIT_LEAD_FORM
`customer_id`	Yes	Google Ads customer id.
`counting_type`	No	ONE_PER_CLICK for leads, MANY_PER_CLICK for purchases.	ONE_PER_CLICK
`default_value`	No	Value per conversion in account currency (helps value-based bidding).
`validate_only`	No	Dry-run only.
`primary_for_goal`	No	Whether campaigns bid on this action by default.
`login_customer_id`	No	Manager account id if applicable.
`always_use_default_value`	No	True to ignore values sent by the tag.
`click_through_lookback_window_days`	No	1-90.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.0.4Sep 27, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only and destructive safety, and the description adds meaningful lifecycle context: creating the action alone is insufficient; the tag must be fetched and installed. This goes beyond the schema and helps the agent anticipate follow-up behavior without contradicting the 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?

Two short sentences front-load the core purpose and then provide the essential next step. Every sentence earns its place and no filler is present.

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?

With a 10-parameter schema fully described and an output schema present, the description does not need to restate return values. It completes the operational picture by telling the agent the required follow-up (tag install via GTM or site snippet).

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 the schema carries parameter meaning. The description adds no extra parameter-level detail, which aligns with the baseline 3 for fully covered schemas.

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 states a specific verb, resource, and scope: 'Creates a website conversion action,' with a parenthetical clarifying its role ('the thing bidding optimises for'). This is immediately distinguishable from sibling asset tools like assets_add_callouts or assets_add_sitelinks.

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 clearly frames creation as the first step of a two-step workflow by instructing the agent to fetch the tag via search and install or fire it through GTM afterward. It does not explicitly enumerate when to avoid this tool or name alternatives, so it lacks a full when/when-not specification.

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