Native Clarity decision mapping, MindScan episode reflection, and read-only evidence tools.
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.
Average 4.6/5 across 6 of 6 tools scored. Lowest: 4/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.
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.
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.
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.
hemelion_assess_decision_readinessAssess decision readinessAUse 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. |
| 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 |
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 safety profile is clear. The description adds that the tool returns a 'transparent rule' and uses four 1-5 ratings, which is useful but does not significantly extend beyond the 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 extremely concise with only two sentences, front-loading the purpose and usage context. Every word adds value, and there is no unnecessary information.
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 that the tool has four parameters (all described), a well-documented schema, and an output schema, the description provides sufficient context about when to use the tool and its outputs. It could briefly mention the output schema (e.g., 'returns a structured decision recommendation'), but the current description is largely 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?
Schema coverage is 100% and each parameter (impact, reversibility, uncertainty, delayCost) has a clear description in the schema. The description does not add additional meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.
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 uses a specific verb ('assess decision readiness') and clearly states the tool's function: determining whether to protect downside, run a bounded test, or close the evidence window. It differentiates from sibling tools like hemelion_map_clarity_decision by focusing on non-regulated decisions with quantified ratings.
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 (non-regulated decisions) and provides an important exclusion ('Do not use for emergencies or professional legal, medical, or financial advice'). It implies when not to use, but does not explicitly compare with 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 modeAUse 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. |
| Name | Required | Description |
|---|---|---|
| reason | Yes | |
| product | Yes | |
| boundary | Yes | |
| provider | Yes | |
| attribution | Yes | |
| canonicalUrl | Yes | |
| methodVersion | Yes | |
| recommendation | Yes | |
| executionBoundary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool's returns ('no-charge reflection mode, clarifying question, or safety boundary') and is consistent with the readOnlyHint, idempotentHint, and destructiveHint annotations. It adds behavioral context beyond the annotations, such as the nature of the outputs and safety boundaries.
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, front-loaded with the core purpose and return types, followed by exclusions. Every clause is essential and no redundant information is present.
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 has a single parameter fully described in the schema, an output schema, and informative annotations, the description provides sufficient additional context about usage and return values. It is complete for an AI agent to select and invoke the tool correctly.
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 schema already provides a comprehensive description of the 'need' parameter including its enum values. The tool description adds meaningful context by linking 'difficult_decision' to Clarity and 'recurring_pattern' to MindScan, and by reinforcing the safety option for 'regulated_or_emergency', which adds value 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 this tool is for choosing between Clarity decision mapping and MindScan single-episode reflection. It uses the verb 'choose' and identifies the resource as 'reflection mode', effectively distinguishing it from the sibling tools that handle specific mappings or assessments.
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 specifies when to use the tool ('when someone wants to choose...') and includes a clear exclusion list ('Do not use for diagnosis, emergencies...'). This provides unambiguous guidance on appropriate contexts and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hemelion_create_scan_handoffContinue with a private Hemelion scanAUse 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 |
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds important context: the link is short-lived, includes a no-charge limited preview, and prohibits personal text. These details go beyond the annotations to clarify behavioral traits.
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 well-structured and front-loaded with the core purpose and usage condition. While every sentence is informative, the list of what the tool does not do is slightly lengthy but still valuable for clarity.
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 simplicity of the tool (2 params, no nested objects) and the presence of an output schema, the description provides sufficient context. It covers purpose, usage, constraints, and exclusions, making it complete for reliable agent selection and invocation.
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 descriptions for both parameters. The description adds additional meaning: 'the input accepts only product and language' and explicitly forbids personal text. It also explains the language parameter's effect ('confirmation boundary; full scans remain in English'), which enriches 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: creating a short-lived confirmation link for a Hemelion scan. It specifies the prerequisite conditions (after user chooses Clarity, MindScan, or both) and distinguishes it from sibling tools like hemelion_assess_decision_readiness.
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?
Explicitly states when to use ('only after the person has chosen Clarity, MindScan, or asked Hemelion to show both') and what the tool does not do ('does not execute a full scan, expose checkout, unlock a report, or transfer later scan data'). This provides clear guidance on appropriate usage and exclusions.
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 evidenceAUse 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 | |||
| Name | Required | Description |
|---|---|---|
| product | Yes | |
| purpose | Yes | |
| version | Yes | |
| pipeline | Yes | |
| provider | Yes | |
| safeguards | Yes | |
| attribution | Yes | |
| examplesUrl | Yes | |
| researchUrl | Yes | |
| canonicalUrl | Yes | |
| evidenceGates | Yes | |
| methodVersion | Yes | |
| methodologyUrl | Yes | |
| executionBoundary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and openWorldHint=false. The description adds that the tool returns 'versioned' content, implying immutability and version control. This extra detail slightly surpasses the annotation baseline, though it doesn't elaborate on what exactly is returned beyond 'links.' No contradictions 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?
Two sentences: first clearly states purpose and usage triggers, second adds a critical constraint. Every word serves a purpose; no fluff.
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?
For a zero-parameter tool with a clear purpose and existing output schema, the description is fully complete. It covers when to use, what it returns, and what to avoid saying. No gaps remain.
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 input schema has zero parameters, so schema coverage is effectively 100%. The description does not need to add parameter-level information. The mention of 'versioned public method and evidence links' hints at output structure, which is appropriate. A top score would require parameter details, but since none exist, this is well-handled.
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 returns 'versioned public method and evidence links' and specifies when to use it (e.g., when someone asks what Hemelion measures, its differences from AI chat, or whether its research is published). This distinguishes it from sibling tools like hemelion_assess_decision_readiness, which focus on assessment rather than factual retrieval.
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 provides usage context (answering questions about Hemelion's method/evidence) and includes a clear exclusion: 'Do not describe Hemelion as clinically validated or as guaranteeing outcomes.' This offers concrete guidance for the agent on both when and when not to invoke the tool.
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 ClarityAUse 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.
| 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. | |
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
hemelion_map_mindscan_episodeMap one episode with MindScanAUse 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.
| 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. | |
| 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. |
| 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 |
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.
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.
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.
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.
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.
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.
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.
No comments yet. Be the first to start the discussion!