Hemelion Decision and Pattern Reflection

Map one episode with MindScan

hemelion_map_mindscan_episode

Read-onlyIdempotent

Use this for non-clinical reflection on one concrete, low-risk episode. Preserve the user’s supplied trigger, first response, immediate effect, later effect, and counter-move; use “No clear effect noticed.” rather than inventing a missing effect. For the current 4.1.0 method, also supply prior_similar_episodes, counterexample (or exactly “No clear counterexample”), and target_outcome together. Omitting all three returns an explicitly versioned legacy 4.0.0 map. Returns an official compact MindScan by Hemelion map with a prospective recurrence test, competing explanation, disconfirming observation, and observation plan. Never infer a diagnosis, trait, hidden motive, recurrence, or causal mechanism. It cannot access private website data.

Input Schema

TableJSON Schema

Name	Required	Description
`trigger`	Yes	One concrete situation supplied by the user, without an inferred diagnosis or hidden motive.
`counter_move`	Yes	One safe, reversible alternative response designed by the user.
`later_effect`	Yes	What the user noticed later. Use “No clear effect noticed.” when unknown.
`counterexample`	No	Optional current-method boundary evidence. Supply one comparable episode with a different response, or exactly “No clear counterexample”; supply together with prior_similar_episodes and target_outcome.
`first_response`	Yes	The first observable response the user reports.
`target_outcome`	No	Optional current-method comparison target for the counter-move. Supply together with prior_similar_episodes and counterexample.
`immediate_effect`	Yes	What the user noticed immediately afterward. Use “No clear effect noticed.” when unknown.
`subject_attestation`	Yes	Assert only if the person has confirmed they are 18 or older, this is their own non-emergency situation, and the result will not be used for diagnosis, regulated advice, or a high-impact decision about another person. Ask them if you have not. Do not assert this on assumption.
`prior_similar_episodes`	No	Optional current-method recurrence history. Supply this together with counterexample and target_outcome. It is self-report, not proof of recurrence.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`status`	Yes
`product`	Yes
`provider`	Yes
`attribution`	Yes
`patternLoop`	Yes
`canonicalUrl`	Yes
`costBoundary`	Yes
`methodVersion`	Yes
`scopeBoundary`	Yes
`observationPlan`	Yes
`recurrenceAudit`	Yes
`evidenceBoundary`	Yes
`executionBoundary`	Yes
`highLeverageShift`	Yes
`workingHypothesis`	Yes
`alternativeExplanation`	Yes
`disconfirmingObservation`	Yes

TDQS

A4.6/5.0

Behavior5/5

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

The description adds significant behavioral context beyond annotations: it prohibits inferring diagnoses or hidden motives, states it cannot access private data, and gives specific instructions for handling missing effects. Annotations (readOnlyHint, idempotentHint, destructiveHint) are consistent with the description. There is no contradiction.

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?

The description is front-loaded with the core purpose and usage scope. Subsequent sentences add necessary behavioral and versioning details without redundancy. It could be slightly more concise, but every sentence earns its place.

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?

Given 9 parameters (6 required), 100% schema coverage, and an output schema present, the description fully covers parameter grouping, versioning behavior, and safety constraints (no inference, no private data access). It provides sufficient context for correct tool invocation.

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 100%, so baseline is 3. The description adds value by explaining the grouping of optional parameters (prior_similar_episodes, counterexample, target_outcome) and their effect on versioning. It also instructs to use 'No clear effect noticed.' for missing effects, which supplements schema descriptions.

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 explicitly states 'Use this for non-clinical reflection on one concrete, low-risk episode' and specifies the tool's function: 'Map one episode with MindScan'. It clearly distinguishes from sibling tools by focusing on episode mapping, while siblings address decision readiness, reflection mode, etc.

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?

The description provides clear context for when to use the tool (non-clinical reflection on a concrete episode) and includes detailed instructions on preserving user input and handling missing effects. It also explains versioned behavior based on optional parameter presence. However, it does not explicitly state when not to use this tool.

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

All Hemelion Decision and Pattern Reflection tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0

Disambiguation5/5

Each tool targets a distinct action: assessing readiness, choosing reflection mode, creating a handoff, getting method info, mapping a clarity decision, or mapping a mindscan episode. No two tools have overlapping purposes.

Naming Consistency5/5

All tools follow the 'hemelion_verb_noun' pattern with consistent imperative verbs. The two mapping tools differ clearly by object (clarity_decision vs mindscan_episode). No naming convention violations.

Tool Count5/5

With 6 tools, the server is well-scoped. Each tool contributes a unique function in the decision and reflection workflow, and there are no redundant or unnecessary tools.

Completeness4/5

The tool set covers the core workflow (readiness, mode choice, map generation, and method info). However, there are minor gaps: no tool to retrieve past maps or scan results, and no update/delete functionality. The scan handoff is intentionally limited.

Resources

Need Help?