Samuelz® Policy

Änderung prüfen

show_policy_approval

Read-only

Display the Owner card for an exact policy replacement. General goal/spending proposals use show_business_goal_approval with proposalId instead.

Pass prepare_policy_change.nextAction.arguments, or prepare_business_budget.nextAction.arguments for advertising. moduleKey/policyKey, expectedRevision and value form one change: revision identifies the state being replaced; value replaces it completely rather than patching omitted fields. Do not combine different reads/proposals. Use get_policy_write_options for current supported values/revisions and get_policy for the confirmed snapshot. get_business_budgets.advertising also reads advertising pending state.

Requires policy:read/write and current Owner/module authority. Returns ready_for_human_approval and activatesPolicy=false. Hidden UI metadata carries the exact candidate and signed ten-minute approval proof for the trusted card; only the human click returns them. Present the card and wait. Never call confirm_policy or reveal this proof. isError means no usable preview; reread stale state and obtain renewed intent. No change is applied.

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": {
      "moduleKey": "<moduleKey>",
      "policyKey": "<policyKey>",
      "expectedRevision": "<expectedRevision>",
      "value": "<value>"
    },
    "name": "show_policy_approval"
  }
}

Input Schema

Name	Required	Description
`value`	Yes	Complete explicitly requested replacement, not a patch: omitted fields are not retained. Must satisfy the selected native contract; canonical JSON is limited to 12000 UTF-16 code units. Copy supplied exact continuation arguments unchanged.
`moduleKey`	Yes	Policy module key from the same supported get_policy_write_options result as policyKey and expectedRevision; never a tenant selector.
`policyKey`	Yes	Existing editable policy identifier from that same result; arbitrary new identities and templates are unsupported.
`expectedRevision`	Yes	Opaque hash of the current complete state from that result, not a proposed-value hash or numeric history version. Stale state requires a fresh read and renewed intent.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Far exceeds the annotations, which only declare read-only/non-destructive. It discloses required scopes (policy:read/write plus Owner/module authority), the returned ready_for_human_approval and activatesPolicy=false, that a signed ten-minute proof lives in hidden UI metadata returned only on human click, and that isError means reread stale state and obtain renewed intent. Crucially it confirms no change is applied, which is consistent with readOnlyHint=true.

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 purpose and the sibling it is not, then the invocation recipe, then behavioral constraints. Most sentences carry unique information, but the paragraph is dense and the hidden-metadata sentence is compressed enough to need a re-read; a little tightening would help.

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?

For a safety-critical approval-preview tool with no output schema, the description covers everything an agent needs: where arguments come from, authority prerequisites, what is and is not returned before a human click, error handling, and the guarantee that nothing is applied. Nothing material 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, and the description earns a bump by explaining the relational semantics: moduleKey/policyKey, expectedRevision and value form one coherent change, revision identifies the state being replaced, and value replaces completely rather than patching. It largely restates the schema's 'not a patch' and 'copy supplied exact continuation arguments unchanged' wording, so the added value is real but incremental.

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 concrete verb and resource: "Display the Owner card for an exact policy replacement." It immediately distinguishes itself from show_business_goal_approval for general goal/spending proposals, so an agent can route between them without opening a schema.

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 explicit invocation guidance: pass prepare_policy_change.nextAction.arguments, or prepare_business_budget.nextAction.arguments for advertising, and use show_business_goal_approval for spending proposals instead. It also names the correct read tools (get_policy_write_options for revisions, get_policy for the snapshot) and excludes confirm_policy.

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

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