Wiro MCP Server

Official

by wiroai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Deploy a Wiro agent

deploy_agent

Destructive

Deploy a new AI agent from a template or custom skills after returning a priced quote; confirm the charge to create it and start it automatically.

Instructions

Deploy a new agent from a template or as a custom build from chosen skills. In a team workspace only a team admin can deploy; anyone else is refused before anything is created or charged. This costs money: the first 30 days are paid from the Wiro wallet of the connected project's workspace (a team project pays from the team wallet), and the plan renews from that wallet every 30 days until it is cancelled. Without confirm: true the tool only returns the exact quote. Show it to the user, get their approval, then repeat the call with confirm: true and confirm_charge_usd set to the quoted price; if the price changed in between, nothing is charged and a new quote comes back. Never repeat a confirmed deploy that timed out or whose outcome is unknown without checking list_my_agents first. A refusal that says nothing was created or charged, such as one for balance, can be confirmed again once its cause is fixed and the user says yes. The agent starts on its own after deployment. Credentials can be added later with set_agent_credentials or connect_agent_oauth, but skills that need them do not work until then. A custom build also gets the scheduled tasks its skills come with, or a starter task on Mondays at 10:00. To change a template's skills, deploy it first and then use apply_agent_skills. get_playbook describes the whole flow.

Input Schema

Name	Required	Description
`tier`	Yes	Plan tier. Pro has a larger monthly credit pool and is the only tier that can buy extra credit packs.
`cover`	No	Optional https image URL for the agent cover. A template deploy shows the template cover when it is left out.
`title`	No	Name of the new agent. Required for a custom build. A template deploy defaults to the template title.
`custom`	No	true for a custom build from `skills` instead of a template.
`skills`	No	Custom build only: skill names from list_agent_skills. Skills they depend on are added and priced automatically. An empty list deploys an agent with no extra skills at the minimum price.
`confirm`	No	false returns only the quote. true deploys the agent and charges the wallet. Set it only after the user approved the quoted price.
`template`	No	Template slug or guid from list_agent_templates. Leave it out for a custom build.
`credentials`	No	Optional credential values stored at deployment, keyed by credential key and then field key, for example {"telegram": {"bottoken": "...", "allowedusers": ["123456789"]}}. A chat channel group must contain every required field. Values are never shown back. Other credentials are better set after deployment with set_agent_credentials, which reports field errors.
`description`	No	Optional description of the agent.
`custom_skills`	No	Optional custom instructions or scheduled tasks added at deployment, or changes to the ones the template comes with. They are checked before the quote.
`confirm_charge_usd`	No	With confirm: true, the price the user approved, from the quote's nextAction (quote.priceUsd). Required to deploy. If a fresh quote no longer matches it, nothing is charged and the new quote is returned.

Output Schema

Name	Required	Description	Default
`agent`	No
`quote`	Yes
`stage`	Yes
`message`	Yes
`chargedUsd`	No
`nextAction`	No
`customSkills`	No
`priceChanged`	No
`existingAgentGuid`	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?

Annotations already flag destructiveHint and non-idempotency, and the description adds real context beyond them: money is charged from the workspace wallet, renews every 30 days, a refusal creates/charges nothing, the two-step quote/confirm protocol with a price-change guard, and the note that the agent starts on its own. That is exactly the safety context needed for a paid, destructive, non-idempotent operation.

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?

Front-loaded with purpose, then cost and confirm protocol; nearly every sentence carries operational weight. It is dense and long, but for an 11-parameter, money-charging tool that density is largely earned rather than padding.

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?

Covers the gaps that structured fields cannot: authorization constraints, billing source and renewal, the confirm protocol, idempotency guidance, credential prerequisites, and the post-deploy follow-up tools. With an output schema present, no return-value explanation is owed.

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 parameter meaning is already documented and baseline is 3. The description still adds cross-parameter flow semantics — that confirm alone returns only a quote and confirm_charge_usd must equal the quoted price — and that credential-dependent skills fail until credentials are set. It does not re-explain tier, title, cover or custom_skills beyond the schema.

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?

Opens with a specific verb and resource plus both creation modes: 'Deploy a new agent from a template or as a custom build from chosen skills.' An agent can immediately distinguish this from list_agent_templates, list_my_agents, update_agent and apply_agent_skills.

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 routes the agent: use apply_agent_skills to change a template's skills after deploying, use set_agent_credentials or connect_agent_oauth for credentials added later, and check list_my_agents before repeating an unknown-outcome deploy. It also states who may call it (team admin only) and what to do after a refusal.

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