Hemelion Decision and Pattern Reflection

Map a decision with Clarity

hemelion_map_clarity_decision

Read-onlyIdempotent

Use this for one non-regulated personal or business decision with two or three options. Ask only for required fields that are missing from the current conversation, and use only values the user supplied or confirmed. Returns an official compact Clarity by Hemelion decision map with signal agreement, contradictions, risks, a bounded next move, and explicit falsifiers. Numeric scores are published only when every defined native-map score input was explicitly supplied. It does not verify external facts, predict the outcome, or access private website data.

Input Schema

TableJSON Schema

Name	Required	Description
`agency`	No	How much direct control the user has over the outcome: 0 little, 100 high.
`regret`	No	The timing mistake the user is more concerned about.
`options`	Yes	Two or three real options supplied or confirmed by the user.
`deadline`	No	When the user needs to decide.
`decision`	Yes	One concrete decision stated in the user’s own words. Do not infer private facts.
`avoidance`	No	How much the user suspects delay is replacing decision progress: 0 none, 100 high.
`exit_plan`	No	How prepared the user’s exit is if the choice turns out wrong: 0 none, 100 ready.
`priorities`	Yes	One to three priorities confirmed by the user.
`safety_net`	No	How much financial or practical buffer absorbs a bad outcome: 0 none, 100 substantial.
`constraints`	No	Material constraints the user explicitly identified.
`testability`	No	How easily the options can be compared in a bounded real-world test: 0 hard, 100 easy.
`reversibility`	Yes	How easy the first commitment is to reverse: 0 means very hard, 100 means very easy.
`risk_tolerance`	No	Current emotional tolerance for downside: 0 low, 100 high.
`scope_category`	Yes	Required safety classification. Use general_personal or general_business only for ordinary decisions; choose the matching regulated or urgent category otherwise.
`values_clarity`	No	How clear the user is about what they actually want: 0 unclear, 100 clear.
`emotional_state`	No	How settled the user feels right now: 0 highly stressed, 100 calm. Needed for the rule that flags a strong leaning formed under stress.
`social_pressure`	No	How strongly other people’s expectations affect the choice: 0 none, 100 high.
`immediate_leaning`	No	The user’s immediate, unconsidered leaning toward their preferred option: 0 none, 100 strong. Ask for a first reaction, not a reasoned one.
`identity_alignment`	No	How well the preferred option fits who the user wants to become: 0 poorly, 100 closely.
`decision_confidence`	No	How confident the user feels making this decision now: 0 not at all, 100 fully.
`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.
`evidence_reliability`	No	How representative and comparable the current evidence is: 0 weak, 100 strong.
`past_similar_outcome`	No	Whether the user has faced a similar decision before and how it turned out.
`evidence_leader_index`	No	Which option currently has the strongest comparable real-world evidence, if any. Use a zero-based index that is less than options.length: only 0 or 1 with two options, and 0, 1, or 2 with three. Use null or omit when no option leads.
`priority_leader_index`	No	Which option best fits the user’s stated priorities, if any. Use a zero-based index that is less than options.length: only 0 or 1 with two options, and 0, 1, or 2 with three. Use null or omit when no option leads.
`current_preference_index`	No	Which option the user currently prefers, if any. Use a zero-based index that is less than options.length: only 0 or 1 with two options, and 0, 1, or 2 with three. Use null or omit when no option leads.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`scores`	Yes
`status`	Yes
`product`	Yes
`provider`	Yes
`topRisks`	Yes
`nextSteps`	Yes
`attribution`	Yes
`dataQuality`	Yes
`signalAudit`	Yes
`canonicalUrl`	Yes
`costBoundary`	Yes
`methodVersion`	Yes
`scopeBoundary`	Yes
`contradictions`	Yes
`evidenceBoundary`	Yes
`workingDirection`	Yes
`executionBoundary`	Yes
`whatWouldChangeThis`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds significant context: 'Returns an official compact Clarity by Hemelion decision map with signal agreement, contradictions, risks, a bounded next move, and explicit falsifiers' and 'Numeric scores are published only when every defined native-map score input was explicitly supplied.' It also states it does not verify external facts, predict outcomes, or access private data. This goes well beyond annotations and clarifies behavior.

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 three sentences, front-loaded with the core purpose and constraints. Each sentence serves a distinct function: usage scope, invocation guidance, and return value/limitations. There is no redundancy or filler. Very efficient.

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 the tool's complexity (26 parameters, 6 required, enumerations) and the presence of a full schema and annotations, the description adequately covers what the tool does, how to use it, what it returns, and its limitations. It does not need to repeat schema details because the output is explained and behavioral boundaries are set.

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%, so the schema already explains all 26 parameters. The description adds minimal value: it mentions the constraint of 'two or three options' (matching the array min/max items) and the usage pattern to ask only required fields. This is adequate but does not compensate for already well-documented schema.

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 starts with 'Use this for one non-regulated personal or business decision with two or three options,' clearly stating the verb (map), resource (decision with Clarity), and scope. It distinguishes from sibling tools by specifying 'non-regulated' and the bounded option count, which other sibling tools like hemelion_assess_decision_readiness do not cover.

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 explicit context: 'use for one non-regulated personal or business decision with two or three options,' and gives invocation guidance with 'Ask only for required fields that are missing from the current conversation, and use only values the user supplied or confirmed.' It also lists what the tool does not do. However, it does not compare against alternatives (e.g., hemelion_assess_decision_readiness) to tell when not to use this tool, missing explicit exclusions.

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?