Wiro MCP Server

Official

by wiroai

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

Get a Wiro agent's usage or activity log

get_agent_activity

Read-onlyIdempotent

Read a deployed agent's credit usage and activity logs, including daily events and dates with logs, to monitor spending and diagnose behavior.

Instructions

Read what a deployed agent has done and spent. kind usage returns the credit balance, usage per model for the current period and the credit ledger (charges, renewals, packs and token usage per turn; 100 credits = 1 USD). kind logs returns the activity log for one day, newest first (tool calls, turns, scheduled runs, errors). kind log_dates lists the days that have a log. Logs can be read while the agent is running or in error; for a stopped agent the call says so (start it only if the user agrees). Names and emails of the people who acted are never returned. On a team agent, logs and usage need a team admin or the person who deployed it, and the organization's owner can also read usage; other team members are refused.

Input Schema

Name	Required	Description	Default
`date`	No	logs only: the UTC day as YYYY-MM-DD (default today).
`kind`	No	usage for credits and spending, logs for one day of activity, log_dates for the days that have a log.	usage
`limit`	No	usage only: ledger rows to return (default 50, max 200).
`lines`	No	logs only: how many of the newest events to return (default 100, max 300).
`start`	No	usage only: offset into the ledger, newest first (default 0).
`agent_guid`	Yes	The deployed agent's guid, from list_my_agents or deploy_agent.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`logs`	No
`usage`	No
`logDates`	No
`agentGuid`	Yes
`nextAction`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.4.1Nov 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond annotations, the description discloses important behavior: names and emails are never returned, stopped-agent calls require user agreement before starting, and access is restricted for team agents. It also explains ordering and credit conversion, which are meaningful operational details.

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?

The description is front-loaded with the core purpose, then immediately breaks down the three modes. Every sentence contributes operational or permission context, with no filler.

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?

Given the output schema and annotations, the description supplies everything else an agent needs: mode semantics, permission constraints, stopped-agent behavior, privacy behavior, and ordering. Nothing critical for correct invocation 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?

Schema coverage is already 100%, so the schema carries the parameter documentation burden. The description still adds useful cross-parameter meaning by explaining what each kind returns and where agent_guid comes from, though some kind descriptions overlap with 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?

The description states a specific verb and resource: it reads what a deployed agent has done and spent. It immediately distinguishes the three modes (usage, logs, log_dates) and their outputs, so an agent can tell this apart from sibling tools such as get_my_agent or manage_agent_billing.

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 defines when each kind should be used and what each returns. It also covers edge cases and permissions: logs can be read while running or in error, stopped agents return a notice, and team access depends on admin/deployer/owner roles.

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