Skip to main content
Glama
koliha

Epistemic Warrant Protocol (EWP)

by koliha
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

ewp_may_act

Decides if an action may proceed by checking its risk and reversibility against the latest stored warrant view. Blocks stale, inline, or caller-built views and enforces operator risk policy.

Instructions

Separate action gate over the latest stored view at server time. Requires an action with risk (low|medium|high) and reversible (boolean). Refuses inline views, caller-built WarrantViews, and a view_id that is not the latest. risk_policy is operator-only (ingest role).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYes
view_idNooptional guard; must be the latest snapshot
risk_policyNo
evaluated_atNooptional sanity check; the decision always uses server time
proposition_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv0.2.1
    • addedInput schema / properties / action / properties
      Added value: +{
+  "action_id": {
+    "type": "string"
+  },
+  "kind": {
+    "type": "string"
+  },
+  "reversible": {
+    "type": "boolean"
+  },
+  "risk": {
+    "enum": [
+      "low",
+      "medium",
+      "high"
+    ],
+    "type": "string"
+  }
+}
    • addedInput schema / properties / action / required
      Added value: +[
+  "risk",
+  "reversible"
+]
    • addedInput schema / properties / evaluated_at / description
      Added value: +"optional sanity check; the decision always uses server time"
    • addedInput schema / properties / view_id
      Added value: +{
+  "description": "optional guard; must be the latest snapshot",
+  "type": "string"
+}
    • removedInput schema / properties / warrant
      Removed value: -{
-  "type": "object"
-}
    • changedInput schema / required
      Previous value: -[
-  "action"
-]New value: +[
+  "action",
+  "proposition_id"
+]
  2. First observedv0.2.0

TDQS

C2.8/5.0
Behavior3/5

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

Since no annotations are provided, the description carries the full behavioral burden. It discloses that the tool requires a risk/reversible action, refuses certain view inputs, and that risk_policy is operator-only, which are useful constraints. However, it does not state whether the tool is read-only or has side effects, nor what the response format is, leaving the agent uncertain about the operation's nature.

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 description is three sentences and fairly compact, leading with the core purpose and then adding constraints. It is not overly verbose, but the phrasing could be tightened (e.g., 'Separate action gate' is unclear). Overall it is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (nested objects, 5 parameters, no output schema), the description is incomplete. It does not explain what the tool returns (e.g., a decision, denial reason), how to construct the action object correctly, or the relationship between proposition_id and view_id. The agent lacks enough information to invoke this tool properly without guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (40%), and the description partially compensates by explaining that view_id must be the latest snapshot, risk_policy is operator-only, and evaluated_at is a sanity check. However, it does not elaborate on the meaning of action, proposition_id, or the internal structure (kind, action_id), so several parameters remain under-documented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the tool is a 'Separate action gate over the latest stored view at server time' and lists required inputs (risk, reversible), which gives a general sense of its function. However, the phrasing 'Separate action gate' is vague, and it does not clearly distinguish this from sibling tools like ewp_warrant_now or ewp_check_record, leaving the exact role ambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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

The description mentions what it refuses (inline views, caller-built WarrantViews, non-latest view_id) but provides no guidance on when to use this tool versus alternatives. It does not name any sibling tool or specify the conditions that would make this the preferred choice, so the agent is left without routing context.

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