A
licenseA
qualityC
maintenanceAssess your business's AI automation readiness across 20 industries. Get a personalized score, specific recommendations, and time/revenue impact estimates
2
6 npm
1
MIT
Anchored Hope Index™ | Mental Resilience Counseling
Server Details
A professional resilience and future-orientation assessment for leaders, executives, and high-perfor
If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 21 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2024-11-05
- URL
TDQS
A3.9/5.0
Scored across 2 tools
Disambiguation5/5
The two tools have clearly distinct purposes: one provides framework metadata and the other executes the reflection. There is no overlap or ambiguity in what each tool does.
Naming Consistency5/5
Both tool names follow a clean verb_noun pattern: get_framework_metadata and run_anchored_hope_index. The naming is consistent and clearly indicates the action and object.
Tool Count3/5
With only two tools, the server feels minimal, though the scope is tightly defined. This sits at the borderline low end and may not be enough for a broader 'mental resilience counseling' domain.
Completeness5/5
For the stated educational, non-clinical purpose, the two tools cover the full journey: understanding the framework and running the index. No CRUD operations are needed given the stateless, no-PII design.
Available Tools
2 toolsget_framework_metadataGet Anchored Hope Index™ Framework MetadataAInspect
Returns the scoring framework metadata: seven resilience domains, five result bands with score ranges, and the Likert scale definition. No arguments required. Read-only, no PII.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| domains | Yes | |
| disclaimer | Yes | |
| likertScale | Yes | |
| resultBands | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It clearly discloses that the call is read-only and involves no PII, which covers the main behavioral concerns for a simple metadata endpoint. It does not mention rate limits or auth, but for this low-complexity tool the disclosure is adequate.
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 two sentences with no filler. It front-loads the exact metadata contents and then adds the no-argument and safety constraints. 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 the low complexity, empty input schema, and available output schema, the description is complete. It tells the agent what is returned, that no arguments are needed, and that the operation is read-only and PII-free, which is sufficient for correct 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?
There are zero parameters and the schema is an empty object, so parameter semantics are intentionally trivial. The description explicitly states 'No arguments required', making the no-input expectation unambiguous and adding value beyond the empty 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 names a specific verb ('Returns'), resource ('scoring framework metadata'), and enumerates concrete contents: seven resilience domains, five result bands, and the Likert scale definition. It is clearly differentiated from the sibling run_anchored_hope_index, which is the calculation tool rather than the metadata getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage ('Returns the scoring framework metadata') and gives useful constraints ('No arguments required', 'Read-only, no PII'), but it does not explicitly state when to use this tool versus run_anchored_hope_index. An agent must infer that this is for definitions rather than score computation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_anchored_hope_indexRun Anchored Hope Index™BInspect
Educational, non-clinical structured reflection on hope and resilience. This tool provides educational information only and is not a clinical assessment or medical advice.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| agency | Yes | Agency & Pathway Belief (1-5) | |
| meaning | Yes | Meaning & Purpose (1-5) | |
| futureDirection | Yes | Future Orientation (1-5) | |
| stressStability | Yes | Stress Stability (1=high drift, 5=very stable) | |
| supportConnection | Yes | Support & Relational Anchor (1-5) | |
| emotionalEndurance | Yes | Emotional Endurance (1-5) | |
| motivationStability | Yes | Motivation Stability (1-5) |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| score | Yes | |
| safety | Yes | |
| category | Yes | |
| nextSteps | Yes | |
| disclaimer | Yes | |
| resultBand | Yes | |
| totalScore | Yes | |
| domainScores | Yes | |
| resultBandLabel | Yes | |
| priorityReflectionAreas | Yes | |
| educationalInterpretation | Yes |
TDQS
B3.4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does add an important safety behavior: it is educational only and not a clinical/medical assessment. However, it does not clarify what the tool does with the submitted scores, whether a score is produced, or what the user outcome is, leaving behavioral transparency only partial.
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 short, front-loaded, and easy to scan. There is some redundancy between 'educational, non-clinical' and 'educational information only', but both sentences still serve an important safety purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for an educational tool of this shape, especially because an output schema exists and parameters are fully documented. It still leaves the caller without a clear indication of what happens after submission or how to reason about the tool's relationship to the sibling, which matters given seven required inputs and no annotations.
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?
The input schema covers all seven parameters with clear 1–5 descriptions, so the schema already carries the parameter semantics. The tool description does not add anything beyond the schema, such as how the parameters interact or what the scores represent.
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?
The description clearly identifies the tool as an educational, non-clinical structured reflection on hope and resilience, and its title and input schema make the action concrete. It separates the tool from the sibling by emphasizing it is not a clinical assessment. It stops short of a 5 because it never explicitly states that it computes/generates a result from the seven inputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use in educational, non-clinical conversations about hope and resilience, and explicitly warns it is not a clinical assessment or medical advice. There is no guidance about when to prefer this tool over get_framework_metadata, but the disclaimer provides a meaningful exclusion boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
run_anchored_hope_index1 field changed- added
Input schema / requiredAdded value: +[ + "meaning", + "futureDirection", + "agency", + "emotionalEndurance", + "motivationStability", + "supportConnection", + "stressStability" +]
2 tool updates
- First observed
get_framework_metadata - First observed
run_anchored_hope_index
Related MCP Connectors
ResilienceOracle - 10 operational resilience tools: BIA, RTO/RPO, scenario testing.
8-dimension business diagnosis with Revenue Leak Score and triple-option recommendations
Transformation readiness gaps and initiative risk signals for AI agents and enterprise change leads.
Leadership-ratio benchmark, partnership ROI builder, community-launch readiness test. ELC data.
Related MCP Servers
- FlicenseAqualityDmaintenanceFour specialized AI agent skills: Integral Hermeneutics (8-lens text interpretation through any text type), Rune Wisdom (Elder Futhark divination), What-If Scenario Builder (15 foresight frameworksg), and Strategical Alignment (6-phase protocol for detecting where short-term optimization builds long-term fragility, with 9-dimension gap assessment)4-
- FlicenseAqualityCmaintenanceEnables AI assistants to conduct a 30-question information security and GDPR/NIS2 compliance screening for Polish SMEs, with fully local scoring, area-based results, gap identification, and prioritized remediation steps.5-
- AlicenseNot gradedqualityCmaintenanceAI safety evaluation toolkit that scores text for care-centered alignment, detects threats like jailbreaks, and certifies AI responses against a 16-probe framework. It enables users to analyze relationship health, predict burnout risk, and ensure ethical AI interactions.5 npmMIT
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd
Glama MCP Gateway
Add one secure layer between your agents and this server.