Record a decision and the ground truths it rests on, so the rationale survives and can be traced when a truth later changes.
| Name | Required | Description | Default |
|---|---|---|---|
| because | Yes | truth refs this rests on, as 'category.key' | |
| decision | Yes | ||
| rationale | No | ||
| workspace | No | Project/workspace to scope to (defaults to this connection's workspace; isolates work streams within your account) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It adds useful context by stating that decisions persist and remain traceable when truths change, but it does not disclose side effects, whether truth refs are validated, whether records are immutable, or what happens if a referenced truth no longer exists.
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 description is a single, front-loaded sentence with no filler and a clear causal justification for why the tool exists. It is concise, though slightly terse given the number of parameters and the absence of richer behavioral detail.
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?
Given no annotations, no output schema, and 50% parameter coverage, the description is too thin for an agent to fully understand how to invoke the tool correctly. It lacks operational context about the structure of a decision, the role of rationale, and how this recording action interacts with the decision-trace and truth-management siblings.
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 coverage is only 50%, and the description does not compensate for the undocumented parameters. It conveys that 'because' holds ground-truth references, but it never explains what 'decision' itself should contain or how 'rationale' relates to 'because' and 'decision'. This leaves two of four parameters underspecified.
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 clearly states the action ('Record'), the resource ('a decision'), and the related content ('ground truths it rests on'), making its core purpose obvious. It is distinguishable from trace/invalidate siblings by emphasizing creation and persistence, though it does not explicitly name those siblings or contrast with capture/remember tools.
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?
The phrase 'so the rationale survives and can be traced when a truth later changes' implies the tool should be used when recording a decision at the time it is made. However, there is no explicit guidance about when not to use it or how it relates to alternatives like wyrm_decision_trace, wyrm_decision_invalidate, or wyrm_capture.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Multiple tools have heavily overlapping purposes: wyrm_all_quests vs wyrm_quest_list, wyrm_decision_downstream vs wyrm_decision_trace, and wyrm_recall vs wyrm_search are near-duplicates in behavior. wyrm_capture also overlaps with wyrm_remember, wyrm_truth_set, wyrm_quest_add, and wyrm_decided_because, making it hard for an agent to reliably pick the right tool.
Most names share the wyrm_ prefix and many follow a resource-action pattern like truth_set, quest_list, and failure_record. However, the pattern is broken by names like wyrm_all_quests, wyrm_decided_because, wyrm_context_build, wyrm_remember, and wyrm_capture, mixing noun-first, verb-first, and non-patterned names.
At 31 tools this is above the heavy threshold, and several tools appear redundant or mergeable, such as wyrm_all_quests/quest_list, decision_trace/downstream, capture/remember, and context_build/session_prime. The breadth is real, but the count feels inflated by overlapping entry points rather than distinct capabilities.
The tool surface covers core lifecycles well: quests have add/claim/update/complete/release, failures have record/check/list/resolve, decisions have record/trace/invalidate, and the vault has full get/put/list/delete. The main gaps are the lack of delete/update for memory artifacts and ground truths, and no explicit way to remove stale artifacts.
