Wiro MCP Server

Official

by wiroai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Manage a Wiro agent's plan and credits

manage_agent_billing

Destructive

Pay, renew, upgrade, or cancel a deployed agent's plan, or buy extra credits, with quotes and confirmation before charges from the workspace wallet.

Instructions

Pay for, renew, upgrade or cancel a deployed agent's plan, or buy extra credits. Charges come from the Wiro wallet of the agent's workspace (the team wallet for a team agent); the connected project must belong to that same workspace. Every call without confirm: true only returns what will happen and the amount (for a prorated upgrade, an estimate and its maximum). Show it to the user, get their approval, then repeat the call with confirm: true and confirm_charge_usd set to the quoted amount (for an upgrade, its maximum); if the price changed in between, nothing is charged and a new quote comes back. Never repeat a confirmed charge that failed or timed out without checking get_my_agent first. subscribe starts a plan for an agent without one; renew undoes a cancellation or renews an expired wallet plan; upgrade_to_pro charges the prorated difference now; buy_credits adds a credit pack (Pro only); cancel stops renewals with no refund. Plans renew every 30 days until cancelled. An agent whose plan is billed by card is upgraded and topped up in the Wiro dashboard, and a personal card plan is cancelled there; the tool returns the link and charges nothing. On a team agent only a team admin, the organization's owner or the person who deployed the agent can pay for it or change its plan; other members are refused and nothing is charged.

Input Schema

Name	Required	Description
`pack`	No	buy_credits only: the credit pack to buy. Leave it out to get the packs with their credits and prices.
`tier`	No	subscribe only: the tier to pay for (default: the agent's current tier).
`action`	Yes	subscribe, upgrade_to_pro, cancel, renew or buy_credits.
`confirm`	No	false returns only the quote. true performs the action. Set it only after the user approved it.
`agent_guid`	Yes	The deployed agent's guid, from list_my_agents or deploy_agent.
`request_id`	No	buy_credits only: the id returned by the quote. Repeating a purchase with the same id never charges twice. Every new purchase needs a new quote; an id whose purchase already completed buys nothing.
`confirm_charge_usd`	No	With confirm: true, the amount the user approved, from the quote's nextAction (quote.chargeNowUsd, or quote.maxChargeUsd for upgrade_to_pro). Required for every action that charges: subscribe, upgrade_to_pro, buy_credits and renewing an expired plan. If a fresh quote no longer matches it, nothing is charged and the new quote is returned. For upgrade_to_pro it is the most the user agreed to pay now.

Output Schema

Name	Required	Description	Default
`agent`	Yes
`quote`	No
`action`	Yes
`result`	No
`message`	Yes
`outcome`	Yes
`agentGuid`	Yes
`requestId`	No
`nextAction`	No
`dashboardUrl`	Yes
`priceChanged`	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?

Adds far more than annotations: which wallet is debited and the workspace-membership constraint, that an unconfirmed call only quotes, that a stale price aborts with no charge, that cancellations are non-refundable, 30-day renewal cadence, and team-admin/owner permission rules with 'nothing is charged' guarantees. The destructiveHint flag is backed with concrete money-safety behavior instead of being merely echoed.

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?

Purpose and the quote/confirm protocol are front-loaded and no sentence is filler. It is a single long paragraph, however, and the trailing action glossary and permission rules would scan faster as separate segments given the density of safety-critical detail.

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 everything an agent needs for a destructive, non-idempotent, open-world billing tool: approval loop, price-drift handling, retry policy after failure, per-action meaning, refund policy, recurring billing cadence, and authorization on team agents. Output schema exists, so quote return fields are correctly referenced rather than re-explained.

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 baseline is 3; the description still adds cross-parameter semantics the schema states only in prose fragments — confirm_charge_usd must equal the quoted chargeNowUsd (or maxChargeUsd for upgrade_to_pro), and a mismatched fresh quote charges nothing. This ties confirm, confirm_charge_usd, and action together operationally, though per-action parameter mappings (tier, pack, request_id) are left to 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 precise verb set and resource: paying, renewing, upgrading, cancelling a deployed agent's plan, or buying credits. It is unambiguous against siblings like get_my_agent (read) or deploy_agent (create), and the money-moving nature distinguishes it from every other tool in the list.

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?

Gives an explicit procedure (quote first, show the user, get approval, repeat with confirm: true), names the alternative destination for card-billed plans (Wiro dashboard), and tells the agent to check get_my_agent after a failed or timed-out charge rather than retrying. Each action's precondition is spelled out (subscribe only for plans-less agents, buy_credits Pro only).

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