Review MCP Server

Overview Schema Source Related Servers Discussions Admin

Remember a Decision

remember_decision

Saves a revision-bound review decision with its requirement-checks, evidence, and engineer verdicts. Re-saving the same subject on the same revision replaces it, so decisions can be revised as answers come in.

Instructions

Save the disposition reached about an artifact revision, with the basis it rests on: a list of requirement-checks, each saying where its requirement came from and what happened when it was checked. Re-remembering the same subject on the same artifact revision REPLACES that decision, which is how a decision is revised as the engineer answers questions or disagrees with a line. A different subject starts a separate decision, because one part can carry several at once. Record each engineer verdict when they have given one: a requirement the engineer accepted is a different thing from one that was proposed. Store each requirement as stated and each piece of evidence as it was reported. This server never opens or measures the artifact, so recall returns what was concluded, not a measurement — Geometry remains the authority for numbers.

Input Schema

Name	Required	Description	Default
`basis`	Yes	The requirement-checks the recommendation rests on.
`status`	No	Set 'confirmed' only once the engineer has accepted the disposition itself.	proposed
`subject`	Yes	What is being decided, in the engineer's words. Part of the record key: reuse the same subject to revise this decision, or a new subject starts a separate one.
`artifact`	Yes
`confidence`	Yes	How much weight the evidence carries.
`supersedes`	No	Revision whose decision for this subject this one replaces, when a part was revised.
`recommendation`	Yes	The disposition, stated as a decision rather than a summary of the conversation.

Output Schema

Name	Required	Description	Default
`decision`	Yes
`replaced`	Yes	True when this revised a decision that already existed at this subject.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 30, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond annotations: it explains the replace-on-same-key semantics (consistent with idempotentHint=false), that decisions are keyed by subject+revision, that the server never opens/measures the artifact so stored evidence is reported, not measured, and that Geometry remains the numeric authority. No contradiction with readOnlyHint=false/openWorldHint=true.

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?

Reasonably front-loaded — the save action and replace semantics come first — and most sentences carry distinct information (keying, verdicts, fidelity of storage, measurement disclaimer). It is on the long side and the fidelity/authority points could be tighter, but nothing is filler.

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

Completeness5/5

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

For a 7-param nested mutation tool with an output schema, the description covers the semantics an agent can't get from fields alone: the replace rule, key composition, verdict recording, and the fact that evidence is reported rather than measured. Field-level details (source enums, unresolved/conflicting states, revision pattern) are already in the schema.

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 86% so the baseline is 3, but the description adds real meaning: the subject is part of the record key and controls replace-vs-new, and a verdict is what turns a proposed requirement into an agreed one. It does not explain supersedes vs. the implicit replace, leaving one 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?

Opens with a specific verb+resource: 'Save the disposition reached about an artifact revision, with the basis it rests on' and then defines the basis structure. It also implicitly distinguishes itself from the read-side sibling by noting 'recall returns what was concluded, not a measurement', so an agent can tell it apart from recall/recall_decisions.

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 concrete when-to-use rules: re-remembering the same subject on the same revision replaces the decision (revision path), a different subject starts a separate decision, record engineer verdicts when given, store requirements/evidence as stated. It doesn't give an explicit 'do not use this when...' exclusion or name a write alternative, but the context is clear.

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

Deploy Server