Samuelz® Policy

Regelhistorie lesen

get_policy_history

Read-onlyIdempotent

Read confirmation history for one known policy/template. Use list_policies for identities, get_policy for a snapshot, get_policy_write_options for edits. Cross-resource search belongs to get_business_change(view=activity).

Evidence by kind:

policy: adjacent attested snapshots can be compared.
template: confirmation timeline; only the current confirmation is verifiable, without field comparisons.

Policy pages descend by version; templates by confirmation time/ID, with repeated revisions possible. Follow moreVersions using the returned record count. Live inserts may shift pages; deduplicate receiptId.

The structured result describes verification, time precision, comparison availability and currentVersion independently of the page. Unknown identities return no versions or selection.

Requires policy:read and current policies Owner access. Invalid input, storage failure or access loss is an error. Reading restores or activates nothing.

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": {
      "kind": "<kind>",
      "moduleKey": "<moduleKey>",
      "policyKey": "<policyKey>"
    },
    "name": "get_policy_history"
  }
}

Input Schema

Name	Required	Description
`kind`	Yes	Rule kind returned by list_policies; copy it with the same moduleKey and policyKey.
`offset`	No	Number of native records to skip, default 0; not a revision number. Pages contain at most 15. Continue with offset+versions.length while moreVersions is true.
`moduleKey`	Yes	Module key of the selected list_policies identity; never a tenant selector.
`policyKey`	Yes	Policy or template key from that same list_policies identity.

Output Schema

Name	Required	Description
`offset`	Yes
`selected`	No	Exact requested identity when recorded; omitted for an unknown identity.
`versions`	Yes
`moreVersions`	Yes
`currentVersion`	Yes	Current verified revision independently of this page, or null when none is verified. Not the newest record on this page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only, idempotent, non-destructive annotations, the description discloses kind-specific evidence behavior, pagination caveats including live inserts and receiptId deduplication, permission requirements, error conditions, and the fact that reading restores or activates nothing.

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

Conciseness5/5

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

The description is front-loaded with purpose and routing, then organized into evidence, pagination, result, and access notes. Its length is justified by the tool's behavioral complexity, and each section adds actionable context.

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 rich input schema, output schema, and annotations, the description fills the remaining gaps: sibling routing, permission requirements, pagination semantics, kind-specific limitations, and error behavior. An agent has enough information to select and invoke it correctly.

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 schema already explains kind, moduleKey, policyKey, and offset. The description still adds useful meaning by explaining that policy pages descend by version while template pages descend by confirmation time/ID, and by clarifying how to follow moreVersions using returned record counts.

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?

The description states a specific verb and resource: read confirmation history for one known policy/template. It explicitly differentiates this tool from list_policies, get_policy, get_policy_write_options, and cross-resource search via get_business_change(view=activity).

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?

It names the sibling tools and the conditions that select them: list_policies for identities, get_policy for snapshots, get_policy_write_options for edits, and get_business_change for cross-resource search. It also makes clear this tool requires a known policy/template identity.

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?