Wiro MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

Connect an agent integration

connect_agent_oauth

Connect external ad, analytics, and marketing accounts to a deployed agent using a sign-in link or saved token, then check sign-in status and select which accounts the agent uses.

Instructions

Connect an outside account (Google Ads, GA4, YouTube, Google Business, Merchant Center, Meta Ads, Instagram, Facebook Pages, TikTok, LinkedIn, X, HubSpot, Mailchimp, Reddit, Shopify) to a deployed agent, with a sign-in link or a saved token, as list_agent_skills shows for each service. action connect: with Wiro's own app (mode wiro) or the user's own app (mode own) it returns a sign-in link that the user must open in their own browser and approve within 15 minutes; never open it for them. With mode api_key it checks a token saved earlier with set_agent_credentials and returns the accounts it can use, with no browser. Without mode the tool picks the one that works; when a provider needs the user's own app keys or a token first, it says which to save. action status: whether the sign-in finished (wait_seconds waits for the user). action select_accounts: saves which accounts the agent uses ({id, name} from connect), and with picker runs the extra step some providers have (Meta Ads pages, Google Business locations). Connecting again replaces an existing connection and needs confirm: true. A running agent restarts when a connection or selection is saved. Remove a connection with disconnect_agent_oauth. Connect only a credential that the agent's skills use (get_my_agent lists them). Only the person who deployed the agent can connect, so the connected project must be one that person created. The agents playbook (get_playbook) has the full setup walkthrough.

Input Schema

Name	Required	Description	Default
`mode`	No	connect: wiro (Wiro's app), own (the user's own app, keys saved first) or api_key (a saved token, no browser). Omit to let the tool choose.
`action`	No	connect (default) starts a connection, status checks it, select_accounts saves the accounts to use.	connect
`picker`	No	select_accounts: the extra step's key ("pages" for Meta Ads, "locations" for Google Business). Without selections it lists the choices.
`confirm`	No	connect: true to replace an existing connection after the user agreed.
`accounts`	No	select_accounts: the accounts to use, each {id, name}, as returned by connect.
`agent_guid`	Yes	The deployed agent's guid, from list_my_agents.
`credential`	Yes	The integration's credential key, for example "google-ads", "meta-ads", "instagram", "hubspot" or "shopify".
`selections`	No	select_accounts with picker: what to use under each account. Accounts left out get nothing.
`redirect_url`	No	connect: where the browser goes after sign-in. Defaults to the agent's page in the Wiro dashboard, which also handles the account choice. The only other accepted address is a local one on the user's own machine (http://localhost or http://127.0.0.1, any port). Keep the default unless the user asks.
`wait_seconds`	No	status: how long to wait for the sign-in to finish, 0 to 600 seconds (default 0, a single check).
`since_connected_at`	No	status: the since_connected_at value from connect's nextAction, so an older connection is not mistaken for the new one.

Output Schema

Name	Required	Description	Default
`mode`	No
`state`	Yes
`title`	Yes
`action`	Yes
`message`	Yes
`accounts`	No
`agentGuid`	Yes
`childStep`	No
`candidates`	No
`credential`	Yes
`nextAction`	No
`connectedAt`	No
`redirectUrl`	No
`authorizeUrl`	No
`tokenExpiresAt`	No
`connectionModes`	No
`expiresInSeconds`	No
`ownAppRedirectUri`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.4.1Nov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations, it discloses that the sign-in link must be opened by the user and approved within 15 minutes, that api_key mode uses a token saved earlier and has no browser step, that reconnecting replaces an existing connection and requires confirm:true, and that a running agent restarts when a connection or selection is saved. These are concrete behavioral traits not captured by readOnly/openWorld/idempotent/destructive hints.

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 long but appropriately dense for an 11-parameter, multi-action OAuth workflow, and it front-loads the core purpose before action details. The provider list and single-paragraph structure make it harder to scan, but nearly every sentence carries operational meaning.

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 complex OAuth connection tool with an output schema, the description covers authentication ownership, browser handoff, token mode, account selection, replacement confirmation, agent restart effects, and the playbook reference. No essential invocation context appears 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?

Schema coverage is 100%, so the baseline is 3; the description adds cross-parameter meaning such as wiro/own producing a sign-in link, api_key checking set_agent_credentials tokens, omitted mode auto-selecting, picker handling Meta Ads pages and Google Business locations, and accounts being {id, name} values from connect. This goes beyond what the individual schema descriptions state, though it does not explain every parameter in depth.

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?

States a specific operation: connecting an outside account to a deployed agent via a sign-in link or saved token, and enumerates its three actions (connect, status, select_accounts). It distinguishes the tool from set_agent_credentials and disconnect_agent_oauth by assigning token saving and removal to those siblings.

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?

Explicitly explains when to use each action and mode, including that mode can be omitted for auto-selection, that status waits for the sign-in, and that select_accounts saves the chosen accounts. It also gives key preconditions: only credentials used by the agent's skills, only the deployer can connect, and removal is handled by disconnect_agent_oauth.

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