Metadata MCP Connector

List LinkedIn Conversions

list_linkedin_conversions

Read-only

List the LinkedIn conversion actions (Insight Tag conversions) available on the connected LinkedIn ad account, with id, name, type and whether each is enabled.

            Use it to pick the ids for update_linkedin_channel_settings.conversion_action_ids
            (which conversions a campaign optimizes toward and reports on), and to answer
            "which LinkedIn conversions do we track?" or "is the /pricing page conversion set up?".

            KEYWORDS: linkedin, conversions, conversion actions, conversion tracking, insight tag,
            website visit conversion, lead gen form conversion, url conversion, page visit, pixel

            Requires a connected LinkedIn channel (check get_integrations_status). Conversion
            actions are created in LinkedIn Campaign Manager, not here: when the one the user
            needs (for example a URL rule for /pricing) is missing, say so and point them at
            Campaign Manager instead of inventing an id.

            RESPONSE: {success, count, conversions:[{id, name, type, enabled, last_received_at}]}
            `enabled: false` conversions cannot be attached to a campaign (launch validation
            rejects them). `last_received_at` is when LinkedIn last recorded a hit; null means
            the conversion has never fired.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

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?

Beyond the readOnlyHint and destructiveHint annotations, the description adds valuable behavioral details: requires a connected LinkedIn channel, notes that conversions are created in Campaign Manager (not here), explains that enabled:false conversions cannot be attached, and clarifies the meaning of last_received_at null. This goes well beyond what annotations alone convey.

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 somewhat long but every sentence adds meaningful information, including response format and edge cases. It is front-loaded with the core purpose and then provides necessary context. The inclusion of keywords is a minor addition but not overly wasteful.

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 no-parameter read-only list tool, the description is fully complete. It covers prerequisites, use cases, response structure, and critical behavioral constraints. Nothing an agent needs to invoke or interpret this tool correctly is missing.

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

Parameters4/5

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

The tool has zero parameters, so the schema already covers everything (100% coverage). Per the rubric, a baseline of 4 applies. The description adds no parameter-specific semantics because none exist, but it does explain the response structure which aids in interpreting the result.

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 lists LinkedIn conversion actions with id, name, type, and enabled status. The verb 'List' and specific resource 'LinkedIn conversion actions' leave no ambiguity, and it is distinct from other list tools by naming its specific domain.

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?

It explicitly says to use this tool to pick ids for update_linkedin_channel_settings.conversion_action_ids and to answer specific user questions. It also mentions the prerequisite of a connected channel and directs users to check get_integrations_status, providing clear when-to-use context.

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?