Metis

Overview Schema Source Related Servers Discussions Admin

Metis — Record Decision

record_decision

Store a user preference or decision so Metis recalls it on future requests and personalizes responses instead of asking again. Categorize by type and scope, and attribute it to the specialist that should apply it.

Instructions

Record a user preference or decision so Metis adapts to the user over time.

Use this whenever the user states (or confirms) a standing preference or makes a
decision worth remembering — coding style, citation format, a methods default, an
article/dataset they keep returning to, a naming convention, a workflow choice.
These are recalled into context on future requests (recall_decisions), so Metis
personalizes instead of asking again.

Args:
    decision: the preference/decision in plain language (e.g. "Always use tidyverse style in R, never base apply").
    category: preference | coding | citation | methodology | writing | article-ref | dataset | routing | other.
    context: optional — when/why it applies (e.g. "for HAT spatial analyses").
    scope: 'always' (persist) or 'once'.
    agent_slug: the specialist that should APPLY this decision — e.g.
        "frontend-designer-builder" for a layout rule, "writing-partner" for
        a prose rule, "librarian" for what matters in the library. Leave
        empty for a project-wide rule that every agent should carry.

        Attribution is what makes the decision reachable. `get_agent_context`
        injects an agent's own decisions plus the project-wide ones, and a
        flat list of every preference injected into every agent is noise that
        gets ignored. Measured 2026-08-24: user_decisions held 2 rows while
        session summaries held 7,578 decision entries — so invoking a
        specialist returned a persona and nothing about how the researcher
        wants things done, which is why routing to one stopped being worth it.

Input Schema

Name	Required	Default
`scope`	No	always
`context`	No
`category`	No	preference
`decision`	Yes
`agent_slug`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.5Oct 24, 2026
- addedInput schema / properties / agent_slug
```
Added value: +{
+  "default": "",
+  "title": "Agent Slug",
+  "type": "string"
+}
```
Addedv0.1.4Jul 14, 2026

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description does disclose real behavioral context: entries persist and are re-injected into future context, and agent_slug attribution determines which specialist receives the rule via get_agent_context. However, it never covers deduplication, conflict/overwrite behavior when a preference changes, or permissions, and much of the agent_slug rationale is anecdotal justification rather than operational guidance.

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

Conciseness3/5

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

The core purpose and usage trigger are front-loaded and tight, but the agent_slug entry balloons into a multi-paragraph essay with a dated measurement ('Measured 2026-08-24: ... 7,578 decision entries') that is persuasion, not invocation guidance. Roughly a third of the text does not help an agent call the tool correctly.

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

Completeness4/5

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

For a mutation tool with no annotations, the description adequately covers what is written, that it persists, and how it resurfaces through recall_decisions and get_agent_context; an output schema exists so return values need no explanation. The remaining gap is lifecycle behavior — whether repeat recordings dedupe or supersede prior decisions — which matters for a memory-writing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, but the description documents all five parameters with meaning beyond the schema: category enumerates nine values the schema does not list, scope explains 'always' vs 'once' as persist vs one-shot, decision includes a worked example, and agent_slug explains the attribution semantics and the empty-string default.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+object (record a user preference or decision) and its purpose (Metis adapts over time), and names recall_decisions as the counterpart tool. It does not distinguish itself from near-siblings like record_routing_preference, commit_session_decisions, or add_memory_entry, so an agent must infer which write path to use.

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 a clear trigger condition ('whenever the user states or confirms a standing preference') backed by concrete examples of qualifying content, plus the recall_decisions pairing that explains downstream use. It omits when NOT to use it — no exclusion versus routing preferences, session-summary decisions, or one-off session events.

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

Deploy Server