AtlasClose Governance Demo

Pulse ruling

atlas.pulse_ruling

Practice mode, Consumer Pulse copy only (Magistrate demo, steps 4 and 6): get the Magistrate's ruling on your referral, recorded on your copy with a ruling receipt id once a Magistrate seated for it (O-VESTED-MAGISTRATE) has decided; while it is being heard it reports IN_HEARING, and if no Magistrate is connected it reports DEEP_REVIEW_PENDING ('Demonstration result, not decided by any Magistrate'). No ruling is written in advance. The Magistrate reads both sides and writes its own ruling. Not certified; binds only your practice copy. Pass verify_text (and optionally receipt_id) to check a copy of the ruling text against the stored ruling (whole text compared).

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": {
      "actor_token": "<actor_token>"
    },
    "name": "atlas.pulse_ruling"
  }
}

Input Schema

Name	Required	Description
`matter_id`	No	Id of your practice copy (returned by atlas.enter_demo). Optional when you have one copy.
`receipt_id`	No
`actor_token`	Yes	Your credential from atlas.enroll or atlas.authenticate. Send it on every call after enrolling.
`verify_text`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 18, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations carry only readOnlyHint=false, so the description does the heavy lifting and delivers: the IN_HEARING and DEEP_REVIEW_PENDING states, the fact that no ruling is written in advance, that the Magistrate authors its own ruling, that it is uncertified and binds only the practice copy, and the whole-text comparison semantics of verify_text. This is exactly the beyond-annotations behavior an agent needs.

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?

The mode/scope constraint is front-loaded and every clause carries information (states, binding scope, verification). It is a single dense paragraph with stacked parentheticals, which costs a little readability but not enough to be wasteful.

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 no output schema, the description usefully enumerates the observable outcomes (ruling receipt id, IN_HEARING, DEEP_REVIEW_PENDING). It does not describe the rest of the response payload, and the mutation/read distinction (readOnlyHint=false vs. 'no ruling is written in advance') is left for the agent to reconcile, but nothing critical to invoking it correctly 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 50% (matter_id and actor_token documented, receipt_id and verify_text not), and the description compensates by explaining the verify_text/receipt_id check and whole-text comparison. It does not clarify when receipt_id is required versus optional beyond 'optionally', leaving a small gap.

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 ('get the Magistrate's ruling on your referral') and pins the scope tightly: 'Practice mode, Consumer Pulse copy only (Magistrate demo, steps 4 and 6)'. An agent can separate this from atlas.magistrate_referral (files a referral) and atlas.pulse_refer 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 Guidelines4/5

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

Gives clear situational context — practice mode, Consumer Pulse copy, Magistrate demo steps 4 and 6 — so the agent knows when this call belongs in a flow. It stops short of naming alternative tools (e.g. atlas.magistrate_referral, atlas.pulse_verify_receipt) or explicit when-not conditions, so it is context-rich but not fully routing.

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

All AtlasClose Governance Demo 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?