Onepin

Estimate run cost

estimate_run

Read-only

Price a run before starting it. Creates nothing, charges nothing, asks nothing.

Returns credits (expected/min/max), current_balance, can_run, a breakdown, alternatives and console_url. Nobody was asked which workflow this is — confirm it and the price with the user before anything spends.

Input Schema

Name	Required	Description
`script_text`	No	Replaces the workflow's stored script. estimate_run and run_workflow must get the SAME text.
`workflow_id`	Yes	The workflow_id from list_workflows. Never invent one.
`source_language`	No	Locale of script_text, e.g. `ko-kr`. Must match the one given to estimate_run.

Output Schema

Name	Required	Description	Default
`priced`	No
`can_run`	No
`breakdown`	No
`next_step`	No
`run_token`	No
`dictionary`	No
`console_url`	No
`max_credits`	No
`min_credits`	No
`alternatives`	No
`deficit_at_max`	No
`current_balance`	No
`expected_credits`	No
`will_incur_overage`	No
`estimated_overage_cents`	No
`overage_rate_cents_per_credit`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

addedOutput schema / $defs / DictionaryProspectOut

Added value: +{
+  "additionalProperties": true,
+  "description": "Whether this run would apply the workspace's pronunciation entries, and why not.",
+  "properties": {
+    "applies": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "excluded_entry_ids": {
+      "items": {
+        "type": "string"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "policy": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "reason": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / dictionary

Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/DictionaryProspectOut"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

First observedOct 14, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with the memorable 'Creates nothing, charges nothing, asks nothing'. It also discloses a non-obvious behavioral trait: the workflow identity is not inferred, so the agent must confirm with the user. It lists the key return fields even though an output schema exists, which is mildly redundant but useful for at-a-glance decision making.

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?

Four short sentences, front-loaded with the core action and the safety guarantee; every sentence carries information. The closing clause ('Nobody was asked which workflow this is...') is somewhat cryptic in phrasing, slightly reducing polish.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't enumerate returns, and it still summarizes the decision-relevant ones (credits, can_run, alternatives). Combined with annotations covering the safety profile, an agent has enough to call it correctly; only the explicit run_workflow follow-on linkage is left implicit.

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%, so workflow_id, script_text and source_language are already fully documented in the schema, including the critical 'same text for estimate_run and run_workflow' constraint. The description adds no parameter-level detail of its own, 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 - 'Price a run before starting it' - which unambiguously distinguishes it from the mutating sibling run_workflow. An agent knows immediately this is a dry-run cost estimator, not an execution tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Price a run before starting it' plus 'confirm it and the price with the user before anything spends' clearly establishes the pre-execution context and the required user-confirmation step. It stops short of explicitly naming run_workflow as the follow-on action, leaving that inference to the agent (though the schema hints at the pairing).

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

All Onepin tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?