OpenReflex

Overview Schema Source Related Servers Discussions Admin

Record outcome

record_outcome

Idempotent

Record the verified outcome of the current task to finalize it in the experience graph and update lessons. Use when tests pass, research is cross-checked, or the user confirms the result.

Instructions

Record the verified outcome of the most recent task and learn from it. Returns: the recorded status plus a plain-language Path check. A better path is only named when comparable completed tasks provide evidence; otherwise the result says that no better option is proven. Use when: the result is confirmed: tests/lint/build passed, research was cross-checked against relevant evidence, the user confirmed the answer, or the task failed/was abandoned. Not for: declaring the strategy (use choose_path). Side effects: finalizes the task in the local Experience Graph and updates its experience, lessons and path comparison; calling it again for the same task replaces the recorded outcome. Touches no project files. Errors: 'No execution to record an outcome for' before any task was planned; a 'not enabled' message until the project is approved.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "status": "<status>",
      "evidence": "<evidence>"
    },
    "name": "record_outcome"
  }
}

Input Schema

Name	Required	Description	Default
`status`	Yes	'success' when the result is confirmed (tests/builds passed, research was cross-checked, or the user confirmed it); 'failure' when the task failed or was abandoned.
`evidence`	Yes	Short proof of the result, e.g. 'pytest tests/test_auth.py passed' or 'user confirmed the fix'. Secrets are redacted.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.5.1Sep 19, 2026

changedInput schema / properties / evidence / description

Previous value: -"Short proof of the result, e.g. 'pytest tests/test_auth.py passed' or 'user confirmed the fix'. Up to 500 characters; secrets are redacted."New value: +"Short proof of the result, e.g. 'pytest tests/test_auth.py passed' or 'user confirmed the fix'. Secrets are redacted."

addedInput schema / properties / evidence / maxLength
```
Added value: +500
```
addedInput schema / properties / evidence / minLength
```
Added value: +1
```

changedInput schema / properties / status / description

Previous value: -"'success' when tests, lint or build passed or the user confirmed the result; 'failure' when the task failed or was abandoned."New value: +"'success' when the result is confirmed (tests/builds passed, research was cross-checked, or the user confirmed it); 'failure' when the task failed or was abandoned."

Changed2 schema fields changedv0.3.2Sep 16, 2026

addedInput schema / properties / evidence / description

Added value: +"Short proof of the result, e.g. 'pytest tests/test_auth.py passed' or 'user confirmed the fix'. Up to 500 characters; secrets are redacted."

addedInput schema / properties / status / description

Added value: +"'success' when tests, lint or build passed or the user confirmed the result; 'failure' when the task failed or was abandoned."

First observedv0.1.3Sep 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

The annotations already note idempotentHint=true and destructiveHint=false, and the description adds meaningful context without contradicting them: it finalizes the task in the local Experience Graph, updates experience/lessons/path comparison, replaces prior recorded outcomes on repeat calls, and touches no project files. It also discloses error conditions like 'No execution to record an outcome for' and the 'not enabled' project approval state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then organized into clear labeled sections: Returns, Use when, Not for, Side effects, and Errors. Despite being detailed, every sentence earns its place and no filler is present.

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?

With an output schema present, return details are partially covered, and the description adds the necessary decision context, side effects, error conditions, and prerequisites. It tells an agent when to call it, what will happen, what will not happen, and what errors to expect, making it fully actionable.

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 description coverage is 100%, and the schema already fully explains status and evidence, including the status enum semantics. The description reinforces the status meaning in the 'Use when' section but adds no new parameter-level syntax or format details beyond 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?

The description opens with a specific verb and object: 'Record the verified outcome of the most recent task and learn from it.' The 'Not for' line explicitly contrasts it with choose_path, making the tool's scope unambiguous and differentiating it from siblings.

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

Usage Guidelines5/5

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

It provides explicit 'Use when' conditions with concrete examples such as tests/lint/build passing, research cross-checked, user confirmation, or task failure/abandonment. It also gives an explicit exclusion, 'Not for: declaring the strategy (use choose_path),' which is clear routing guidance.

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

Deploy Server