Skip to main content
Glama
cirwel

UNITARES

by cirwel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

check_working_state

Read-onlyIdempotent

Read your current governance state and verdict without running a cycle, writing state, or minting an identity. Use it to inspect agent health and decide whether to proceed.

Instructions

Read your current governance state and verdict without running a cycle, writing, or minting an identity. Only proof sent with the call reads your state (start_session's client_session_id, an X-Session-ID header or a verified continuity_token), never an inferred binding; otherwise a self-read is unbound and next_action says how to recover. agent_id, dropped on /mcp/, names the agent to read through use_tool or REST unless you are bound as a different agent (identity_mismatch); that read is marked identity_assurance.caller_proven=false on an inferred session. verbosity='standard' adds mode and basin with their meanings under raw_governance; verbosity='full' (alias lite=false) returns the full canonical diagnostics. sync_state also logs work and returns proceed or pause. get_governance_metrics returns this read's raw payload. With behavioral-sensor inputs, EISV fields: E=Energy [0,1] (observations and prior judgments); I=Information Integrity [0,1] (calibration and consistency features); S=Entropy [0,1] (deviations and activity features); V=Valence [-1,1] (separate EMA of raw E_obs-I_obs; positive=positive smoothed gap, negative=negative smoothed gap). Read primary_eisv_source / measurement_source for the producer; other producers share these field names.

Input Schema

NameRequiredDescriptionDefault
liteNoIf true (default), returns minimal essential metrics only. Set lite=false for full diagnostic data. verbosity, when given, takes precedence.
verbosityNoTier: minimal (default); standard: bare EISV and risk, verdict/basin/mode with meanings, guidance; full: diagnostics.
include_stateNoRetained for compatibility; has no effect on any tier. Use verbosity to choose what is returned. Accepts boolean or string ('true'/'false').
continuity_tokenNoSame-process rebind proof only; never a cross-process resume.
client_session_idNoBinding id for calls in this process; not a cross-process proof.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv3.1.0
    • changedInput schema / properties / client_session_id / description
      Previous value: -"In-session binding id from start_session()/identity(); pass it on same-process calls. Not a cross-process proof."New value: +"Binding id for calls in this process; not a cross-process proof."
    • changedInput schema / properties / continuity_token / description
      Previous value: -"Ownership proof from onboard()/identity(), for same-live-process rebinds only. Not a cross-process resume credential."New value: +"Same-process rebind proof only; never a cross-process resume."
    • changedInput schema / properties / include_state / description
      Previous value: -"Include nested state dict in response (can be large). Default false to reduce context bloat. Accepts boolean or string ('true'/'false')."New value: +"Retained for compatibility; has no effect on any tier. Use verbosity to choose what is returned. Accepts boolean or string ('true'/'false')."
    • changedInput schema / properties / lite / description
      Previous value: -"If true (default), returns minimal essential metrics only. Set lite=false for full diagnostic data."New value: +"If true (default), returns minimal essential metrics only. Set lite=false for full diagnostic data. verbosity, when given, takes precedence."
    • addedInput schema / properties / verbosity
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "minimal",
+        "standard",
+        "full"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Tier: minimal (default); standard: bare EISV and risk, verdict/basin/mode with meanings, guidance; full: diagnostics."
+}
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, yet the description adds substantial behavioral context beyond them: which proofs are honored (client_session_id, X-Session-ID, verified continuity_token), the fallback to an unbound self-read with next_action recovery, identity_mismatch handling, and identity_assurance.caller_proven=false on inferred sessions. This is well beyond what the safety hints convey.

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?

Core purpose is front-loaded, but the body is a dense wall of run-on clauses mixing auth rules, routing, verbosity tiers, and EISV field definitions into long semicolon chains. It is information-rich but hard to scan, and the EISV definitions and agent_id note are not clearly separated from the call-critical instructions.

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 carries the return-value burden and mostly meets it, documenting next_action, identity_assurance, raw_governance contents, basin/mode, and EISV field meanings. Gaps remain around the overall response envelope, but it is complete enough to call the tool correctly across its verbosity tiers.

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%, establishing a 3 baseline, but the description adds real meaning: verbosity='standard' adds mode and basin with meanings under raw_governance, verbosity='full' is aliased to lite=false, and verbosity takes precedence over lite. It also explains the EISV field semantics that the schema never touches, exceeding what the schema provides.

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 — 'Read your current governance state and verdict' — and immediately bounds scope with 'without running a cycle, writing, or minting an identity.' It distinguishes itself from sync_state (which logs work) and get_governance_metrics (raw payload), so an agent can separate it from 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 Guidelines4/5

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

Names specific alternatives and their differentiators: sync_state 'also logs work and returns proceed or pause,' and get_governance_metrics 'returns this read's raw payload.' It also spells out the proof conditions that select the bound vs. unbound path. What's missing is an explicit 'when not to use this' or a direct 'use X instead if...' routing statement, so it stays at 4 rather than 5.

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

Deploy Server

Other Tools