Retrieve a bounded memory context with axes, evidence IDs, and warnings for a proposition at a given time to enable deterministic warrant evaluation without I/O or LLM inference.
Bounded packet: axes, evidence ids, warnings. Not a persona biography. OPEN and DEGRADED are explicit.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| view_id | No | ||
| evaluated_at | Yes | ||
| proposition_id | Yes |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It does add some context: the result is bounded, not a biography, and OPEN/DEGRADED states are surfaced. But it never states whether this is a read-only lookup, whether it mutates state, what permissions are needed, how the packet is returned, or what OPEN/DEGRADED actually mean for the caller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is short and front-loaded, but brevity crosses into under-specification: 'axes,' 'OPEN,' and 'DEGRADED' are unexplained jargon, and the noun-phrase fragments do not form a usable instruction. It is compact, not genuinely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no parameter descriptions, no annotations, and no output schema, this description leaves most of the call contract implicit. An agent cannot determine what inputs to provide, what output to expect, or how this fits into the ewp workflow, so it is not adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain any of the four parameters: query, view_id, evaluated_at, or proposition_id. The terms 'axes, evidence ids, warnings' appear to describe the output packet rather than input semantics, leaving an agent to guess how to populate required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a concrete resource: a bounded packet containing axes, evidence ids, and warnings, and explicitly excludes 'persona biography,' which gives an agent a distinct conceptual boundary. However, it lacks an explicit verb (e.g., retrieves, stores, computes) and never names a sibling tool it is not, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to invoke this tool versus any of the ewp_* siblings, such as ewp_evidence_view_get or ewp_warrant_now. 'OPEN and DEGRADED are explicit' hints at state semantics but does not state a trigger condition, input prerequisite, or alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.