Hemelion Decision and Pattern Reflection
Server Details
Native Clarity decision mapping, MindScan episode reflection, and read-only evidence tools.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Score is being calculated. Check back soon.
Available Tools
6 toolshemelion_assess_decision_readinessAssess decision readinessARead-onlyIdempotentInspect
Use this when a person has a non-regulated decision and wants to know whether to protect the downside, run a bounded test, or close the evidence window. Uses four 1–5 ratings and returns a transparent rule. Do not use for emergencies or professional legal, medical, or financial advice.
| Name | Required | Description | Default |
|---|---|---|---|
| impact | Yes | Consequence if the choice is wrong: 1 contained, 5 major. | |
| delayCost | Yes | Cost of waiting: 1 low, 5 high. | |
| uncertainty | Yes | Important unknowns: 1 few, 5 many. | |
| reversibility | Yes | Ease of reversing course: 1 hard, 5 easy. |
Output Schema
| Name | Required | Description |
|---|---|---|
| title | Yes | |
| product | Yes | |
| nextMove | Yes | |
| provider | Yes | |
| limitation | Yes | |
| attribution | Yes | |
| explanation | Yes | |
| canonicalUrl | Yes | |
| methodVersion | Yes | |
| classification | Yes | |
| evidenceThreshold | Yes | |
| executionBoundary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds minimal extra behavioral context beyond noting it 'returns a transparent rule.' No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a disclaimer, front-loaded with usage context and no redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 required parameters, output schema exists), the description adequately covers purpose, usage, and limitations. It provides a complete picture for an agent to decide when to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for each parameter (impact, reversibility, uncertainty, delayCost with 1-5 scales). The description confirms 'four 1-5 ratings' but adds no semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: assessing decision readiness for non-regulated decisions using four 1-5 ratings to determine one of three outcomes. It is distinct from siblings like 'hemelion_choose_reflection_mode' which focus on reflection modes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool (for non-regulated decisions wanting to protect downside, run bounded test, or close evidence window) and when not to (emergencies, professional legal/medical/financial advice). However, it does not explicitly compare to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemelion_choose_reflection_modeChoose a reflection modeRead-onlyIdempotentInspect
Use this when someone wants to choose between Clarity decision mapping for a difficult decision and MindScan single-episode reflection for a response they suspect may recur. Returns a no-charge reflection mode, a clarifying question, or a safety boundary. Do not use for diagnosis, emergencies, or legal, medical, financial, hiring, or insurance decisions.
| Name | Required | Description | Default |
|---|---|---|---|
| need | Yes | The kind of help the person is seeking; choose the safety option for regulated or urgent situations. |
Output Schema
| Name | Required | Description |
|---|---|---|
| reason | Yes | |
| product | Yes | |
| boundary | Yes | |
| provider | Yes | |
| attribution | Yes | |
| canonicalUrl | Yes | |
| methodVersion | Yes | |
| recommendation | Yes | |
| executionBoundary | Yes |
hemelion_create_scan_handoffContinue with a private Hemelion scanARead-onlyIdempotentInspect
Use this only after the person has chosen Clarity, MindScan, or asked Hemelion to show both. Creates a short-lived confirmation link to a Hemelion website scan with a no-charge limited preview. Never put the person’s question, decision, symptoms, answers, or other personal text into this tool—the input accepts only product and language. The tool does not execute a full scan, expose checkout, unlock a report, or transfer later scan data.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Clarity for one decision, MindScan for one episode from a suspected recurring response, or choose to show both. | |
| language | No | Language for the confirmation boundary; the full scans currently remain in English. | en |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| product | Yes | |
| language | Yes | |
| nextStep | Yes | |
| provider | Yes | |
| expiresAt | Yes | |
| handoffUrl | Yes | |
| attribution | Yes | |
| canonicalUrl | Yes | |
| methodVersion | Yes | |
| contractVersion | Yes | |
| privacyBoundary | Yes | |
| executionBoundary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'Creates a short-lived confirmation link,' implying a state change, which contradicts the annotation readOnlyHint=true. Additionally, idempotentHint=true may conflict if each invocation generates a new link. The contradiction is direct and significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three dense sentences) with front-loaded conditional usage. Every sentence adds unique value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the contradiction, the description covers when to use, what to input, what to avoid, and what the tool does not do. With an output schema present, the description sufficiently completes the usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context: it clarifies that only product and language are accepted (no personal text) and provides extra detail on the language parameter ('confirmation boundary; full scans remain in English'). This goes beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: creating a short-lived confirmation link for a private Hemelion scan, with clear conditions ('use this only after the person has chosen...'). It distinguishes what the tool does not do (full scan, checkout, etc.), providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('only after the person has chosen Clarity, MindScan, or asked to show both') and clear prohibitions on inputting personal text. It lacks explicit mention of alternatives among sibling tools, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemelion_get_method_and_evidenceInspect Hemelion method and evidenceARead-onlyIdempotentInspect
Use this when someone asks what Hemelion measures, how it differs from a generic AI chat, what it can and cannot claim, or whether its research is published. Returns the versioned public method and evidence links. Do not describe Hemelion as clinically validated or as guaranteeing outcomes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| product | Yes | |
| purpose | Yes | |
| version | Yes | |
| pipeline | Yes | |
| provider | Yes | |
| safeguards | Yes | |
| attribution | Yes | |
| examplesUrl | Yes | |
| researchUrl | Yes | |
| canonicalUrl | Yes | |
| methodVersion | Yes | |
| methodologyUrl | Yes | |
| executionBoundary | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds behavioral context by specifying that the tool returns 'versioned public method and evidence links' and includes a caution about what not to claim. While no side effects or auth needs are mentioned, the description complements annotations well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise: two sentences that front-load the usage context, state what the tool returns, and include a critical caution. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, rich annotations, and an output schema, the description provides all necessary information. It covers when to use, what to expect, and a behavioral note. The tool is simple, and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. No parameter documentation is needed, and the description does not attempt to explain any nonexistent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns 'versioned public method and evidence links' and lists specific queries that should trigger its use (what Hemelion measures, difference from AI chat, claims, research publication). This provides a clear, specific verb-resource definition that distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description begins with 'Use this when someone asks...' which explicitly frames the context of use. It also provides a clear exclusion: 'Do not describe Hemelion as clinically validated or as guaranteeing outcomes.' This gives the agent both when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemelion_map_clarity_decisionMap a decision with ClarityARead-onlyIdempotentInspect
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 unlock the complete paid website report.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| priorities | Yes | One to three priorities confirmed by the user. | |
| 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. | |
| social_pressure | No | How strongly other people’s expectations affect the choice: 0 none, 100 high. | |
| evidence_reliability | No | How representative and comparable the current evidence is: 0 weak, 100 strong. | |
| 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
| Name | Required | Description |
|---|---|---|
| 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 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is safe and read-only. The description adds valuable behavioral context: it does not verify external facts, predict outcomes, or unlock paid reports. It also clarifies that numeric scores are only published when all native-map scores are supplied. This complements annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of 4 sentences, each conveying critical information. It is efficient with no redundant statements. However, a bulleted or more structured format could marginally improve readability for agents scanning for key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (17 parameters, 5 required) and the presence of an output schema, the description adequately covers purpose, usage, behavioral boundaries, and parameter handling expectations. It mentions what the output includes without duplicating the output schema. It does not need to explain return values because the output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema itself provides comprehensive meaning for each parameter. The description does not add further parameter-level detail beyond repeating the required-fields pattern. Baseline 3 is appropriate because the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'map a decision with Clarity', the resource (non-regulated personal/business decision), and constraints (two or three options). It distinguishes from siblings by specifying the non-regulated scope, which is not mentioned in other sibling names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use instructions: 'Use this for one non-regulated personal or business decision with two or three options.' It also advises agents to ask only for missing required fields and use confirmed values. However, it does not explicitly name sibling tools as alternatives, and the exclusion of regulated decisions is implied rather than stated as a when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemelion_map_mindscan_episodeMap one episode with MindScanRead-onlyIdempotentInspect
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 does not unlock the complete paid website report.
| Name | Required | Description | Default |
|---|---|---|---|
| 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. | |
| 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
| Name | Required | Description |
|---|---|---|
| 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 |
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!