Skip to main content
Glama
vishnu-77

OpenReflex

by vishnu-77
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusYes'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.
evidenceYesShort proof of the result, e.g. 'pytest tests/test_auth.py passed' or 'user confirmed the fix'. Secrets are redacted.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv0.5.1
    • 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."
  2. Changed2 schema fields changedv0.3.2
    • 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."
  3. First observedv0.1.3

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

Other Tools