InkRoom

Approval | Spending limits

spending_policy

Destructive

Read account-wide authorization or update only with explicit user consent. 1 credit=USD 0.01. New accounts default to unlimited automatic execution; users can set task/5h/day/week limits, with suggested values 50/500/1000/5000. Existing saved policies remain unchanged. Wallet balance, token hard caps and permissions still apply. Never raise autonomously. action=get reads without other arguments; action=update requires the complete policy (including unlimited and its latest revision) and confirmed:true after explicit consent. Keep allowance and reset/recovery countdown in the same table, not separate prose. Used includes reservations; never subtract twice.

Input Schema

Name	Required	Description
`action`	Yes	get reads the policy without other parameters; update requires the complete policy with its latest revision and confirmed:true after explicit user approval. An explicit empty action retains legacy get behavior.
`policy`	No	Complete replacement policy from the latest get result; never raise limits autonomously
`confirmed`	No	true only after the user explicitly approves this policy update

Output Schema

Name	Required	Description	Default
`asOf`	No
`policy`	Yes
`windows`	No
`timezone`	Yes
`usdPerPoint`	Yes
`dayUsedMillis`	Yes
`reservedMillis`	Yes
`weekUsedMillis`	Yes
`fiveHourUsedMillis`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 22, 2026

addedInput schema / properties / action / anyOf

Added value: +[
+  {
+    "enum": [
+      "get",
+      "update"
+    ],
+    "type": "string"
+  },
+  {
+    "const": "",
+    "description": "Legacy empty action is treated as get; new clients should send get explicitly."
+  }
+]

changedInput schema / properties / action / description

Previous value: -"get reads account-wide spending authorization; update requires explicit user approval"New value: +"get reads the policy without other parameters; update requires the complete policy with its latest revision and confirmed:true after explicit user approval. An explicit empty action retains legacy get behavior."

Changed10 schema fields changedOct 21, 2026

addedInput schema / properties / action / description

Added value: +"get reads account-wide spending authorization; update requires explicit user approval"

addedInput schema / properties / confirmed / description

Added value: +"true only after the user explicitly approves this policy update"

addedInput schema / properties / policy / description

Added value: +"Complete replacement policy from the latest get result; never raise limits autonomously"

addedInput schema / properties / policy / properties / dayPoints / description
```
Added value: +"Maximum credits across the daily window when finite"
```

addedInput schema / properties / policy / properties / enabled / description

Added value: +"Whether saved automatic-spending authorization is enabled"

addedInput schema / properties / policy / properties / fiveHourPoints / description
```
Added value: +"Maximum credits across the rolling five-hour window when finite"
```

addedInput schema / properties / policy / properties / revision / description

Added value: +"Latest policy revision from get; stale updates are rejected"

addedInput schema / properties / policy / properties / taskPoints / description
```
Added value: +"Maximum credits per task when finite; 1 credit is USD 0.01"
```

addedInput schema / properties / policy / properties / unlimited / description

Added value: +"Explicit unlimited choice; wallet balance, Token hard caps and permissions still apply"

addedInput schema / properties / policy / properties / weekPoints / description
```
Added value: +"Maximum credits across the weekly window when finite"
```

First observedOct 16, 2026

TDQS

A4.1/5.0

Behavior5/5

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

The description adds substantial behavioral context beyond annotations: explicit consent requirements, default unlimited behavior for new accounts, suggested limit values, preservation of existing policies, interaction with wallet balance/token caps/permissions, revision staleness, and reservation accounting. This is rich disclosure for a destructive update-capable tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core read/update distinction, but it is a dense paragraph with multiple operational clauses. Some sentences, such as table-formatting and reservation-counting instructions, are tangential to invoking the tool and reduce conciseness.

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 destructive-update nature, rich annotations, full schema coverage, and an output schema, the description provides enough context for correct invocation. It covers consent, defaults, revision handling, and constraints that an agent needs before calling this tool.

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 description coverage is 100%, so the schema already documents action, policy, and confirmed in detail. The description reinforces key semantics such as complete policy replacement, including unlimited and latest revision, but largely duplicates schema-level guidance rather than adding new parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific read/update purpose for an account-wide spending policy, with action=get and action=update behavior made explicit. It distinguishes the two modes and names the policy object, though the opening phrase 'account-wide authorization' is slightly less direct than 'spending policy'.

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?

It gives clear usage conditions: get reads without other arguments, update requires the complete policy and confirmed:true, and updates must only occur after explicit user consent. It also explicitly forbids autonomous limit increases, which is a strong when-not-to-use rule.

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

All InkRoom 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?