Wiro MCP Server

Official

by wiroai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Get a Wiro task price

get_task_price

Read-onlyIdempotent

Retrieve a task's billed cost and compare it with the model's list price when a discount applies, for tasks whose result is unavailable or shows only list price.

Instructions

Get one task’s cost: the amount charged once Wiro has billed it, with the model's list price beside it when a discount made them differ. Successful tasks are billed; failed tasks and tasks cancelled while queued are not, and a task stopped while running can still be charged once its work ends. A finished task's result already shows its cost, so use this for a task whose result you do not have, or whose result shows only the list price. If the task is active, follow the returned wait_for_task next action.

Input Schema

Name	Required	Description	Default
`taskid`	No	The task ID (alternative to tasktoken).
`tasktoken`	No	The task token returned from run_model.

Output Schema

Name	Required	Description
`task`	Yes
`state`	Yes
`billed`	Yes
`costUsd`	Yes	The amount charged so far; null while the task is active or a successful task's charge is not recorded yet. While billed is null, a later charge is still possible.
`nextAction`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.4.1Nov 1, 2026

addedOutput schema / properties / costUsd / description

Added value: +"The amount charged so far; null while the task is active or a successful task's charge is not recorded yet. While billed is null, a later charge is still possible."

addedOutput schema / properties / task / properties / chargedUsd

Added value: +{
+  "description": "What the payer was charged, after any discount.",
+  "type": [
+    "number",
+    "null"
+  ]
+}

addedOutput schema / properties / task / properties / costUsd / description
```
Added value: +"The model's list price for this task."
```

Changed2 schema fields changedv1.2.3Aug 25, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed3 schema fields changedv1.2.1Aug 2, 2026

changedInput schema / properties / taskid / description

Previous value: -"The task ID (alternative to tasktoken)"New value: +"The task ID (alternative to tasktoken)."

changedInput schema / properties / tasktoken / description

Previous value: -"The task token returned from run_model"New value: +"The task token returned from run_model."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "billed": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "costUsd": {
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    "nextAction": {
+      "additionalProperties": false,
+      "properties": {
+        "arguments": {
+          "additionalProperties": {},
+          "type": "object"
+        },
+        "reason": {
+          "type": "string"
+        },
+        "tool": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "tool",
+        "arguments",
+        "reason"
+      ],
+      "type": "object"
+    },
+    "state": {
+      "enum": [
+        "submitted",
+        "running",
+        "completed",
+        "failed",
+        "cancelled"
+      ],
+      "type": "string"
+    },
+    "task": {
+      "additionalProperties": false,
+      "properties": {
+        "costUsd": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "durationSeconds": {
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "exitCode": {
+          "type": "string"
+        },
+        "id": {
+          "type": "string"
+        },
+        "model": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        },
+        "token": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    }
+  },
+  "required": [
+    "state",
+    "task",
+    "billed",
+    "costUsd"
+  ],
+  "type": "object"
+}

First observedv1.1.4Jun 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well beyond the readOnly/idempotent annotations by disclosing the billing rules: successful tasks are billed, failed and queued-cancelled tasks are not, and a task stopped while running can still be charged once its work ends. That is exactly the kind of outcome semantics an agent cannot infer from annotations or schema.

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 the core definition, then billing rules, then usage guidance, then the active-task hand-off. Four dense sentences with no filler, though the billing sentence is packed enough that it takes a second read.

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?

An output schema exists so return values need not be explained, and the description still flags the `wait_for_task` next action for active tasks. Between that, the billing rules and the get_task alternative, an agent has everything needed to call it correctly.

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

Parameters3/5

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

Schema coverage is 100% and both parameters (taskid, tasktoken) are already documented in the schema, including which call returns the token. The description adds no guidance on choosing between the two or on precedence when both are given, so the baseline 3 applies.

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 verb and resource (get one task's cost) and defines exactly what the value represents: the amount charged once Wiro has billed it, plus the model list price when a discount made them differ. It is clearly differentiated from the sibling get_task, whose result already shows cost.

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 says when to use it (a task whose result you do not have, or whose result shows only the list price) and when not to (a finished task's result already shows its cost). It also routes the agent onward: if the task is active, follow the returned `wait_for_task` next action.

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

Deploy Server