Samuelz® Business OS

Abbrechen

withdraw_business_change

DestructiveIdempotent

Withdraw your own pending goal/budget approval request on explicit instruction. Read get_business_change first and select the pending request’s proposalId, not the active resource ID. Applied work belongs to its resource’s update/archive operation; an unsaved policy preview has no request to withdraw.

Bind the withdrawal

Create a separate withdrawal requestKey. Do not reuse the key that created or prepared the request: withdrawal is a different intent. Keep that new key paired with the selected proposalId for exact replay; changed intent conflicts.

Interpret the effect

Withdrawal invalidates the old human Owner card while retaining the original request and immutable receipt. It changes no active resource, money, provider work or permissions. Other actors’ requests and approved, expired or missing requests remain untouched.

withdrawn proves this withdrawal was recorded; it does not report current resource state. not_applied means this attempt recorded no withdrawal—read its reason. After replay or an uncertain reply, read get_business_change(proposalId) instead of writing again, changing the key or treating the preparation receipt as a withdrawal receipt.

The transaction rechecks operator:prepare, accounting:read, operations:read and existing module/grant authority.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "proposalId": "<proposalId>",
      "requestKey": "<requestKey>"
    },
    "name": "withdraw_business_change"
  }
}

Input Schema

Name	Required	Description	Default
`proposalId`	Yes	Exact own pending goal/budget request UUID from get_business_change; never an active resource or policy preview.
`requestKey`	Yes	Fresh caller UUID across this actor/workspace's goal/budget operations. Exact replay keeps the same key and proposalId; changed intent conflicts.

Output Schema

Name	Required	Description
`reason`	No
`status`	Yes
`replayed`	No
`receiptId`	No
`proposalId`	Yes
`requestKey`	No	Fresh caller UUID across this actor/workspace's goal/budget operations. Exact replay keeps the same key and proposalId; changed intent conflicts.
`withdrawnAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by naming what is invalidated (the old human Owner card), what is retained (original request, immutable receipt), and what is untouched (active resources, money, provider work, permissions, other actors' requests). It also discloses the required authorities (operator:prepare, accounting:read, operations:read, module/grant authority) and the idempotency contract via a fresh requestKey — details annotations cannot convey.

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 instruction and organized into three labeled sections (bind, interpret, replay) that each carry distinct information. Slightly verbose in the effect paragraph, but no sentence is pure 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?

Despite an output schema existing, the description still explains the two outcome statuses (withdrawn vs not_applied) and what each proves, plus the replay/uncertain-reply procedure. For a mutation with idempotency and permission rechecks, nothing an agent needs in order to call it safely 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 100%, so the baseline is 3, but the description adds genuine semantics: the key must be a *separate* withdrawal key that must not reuse the creation/preparation key, and the key-plus-proposalId pairing must stay fixed for exact replay. That constraint is only partially inferable from the schema's 'fresh caller UUID' wording.

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 with scope: 'Withdraw your own pending goal/budget approval request on explicit instruction.' It explicitly excludes adjacent cases ('Applied work belongs to its resource's update/archive operation; an unsaved policy preview has no request to withdraw'), so an agent can separate this from update/archive/prepare siblings without opening schemas.

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 prerequisite ('Read get_business_change first and select the pending request's proposalId, not the active resource ID') and an explicit recovery path ('After replay or an uncertain reply, read get_business_change(proposalId) instead of writing again'). It also names the alternatives for non-pending work, which is exactly the when/when-not routing an agent needs.

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

All Samuelz® Business OS 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?