Cognitive Exoskeleton MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Each tool has a distinct primary purpose, but discover_connections and spark_serendipity both involve cross-domain connections, and detect_blindspots and analyze_cognitive_topology both analyze the graph. Descriptions help differentiate them, but there's slight potential for misselection.
Naming Consistency5/5
All eight tools follow a consistent verb_noun pattern with snake_case (e.g., ingest_note, trace_concept_evolution). No mixed conventions or vague verbs.
Tool Count5/5
Eight tools is well-scoped for a personal knowledge graph assistant, covering a range of cognitive operations without excess. Each tool serves a clear function.
Completeness4/5
The set covers ingestion, querying, recall, and analysis well, but lacks explicit edit/delete or raw listing of knowledge entities. This is a minor gap since the focus is on cognitive workflows rather than full CRUD.
Average 4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 9 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly describes the nature of the tool (analysis, generating a portrait) and its outputs, but it does not explicitly state whether this operation is non-mutating or mention any side effects, performance implications, or data access constraints. The verb 'Analyze' and 'Generates' imply safety, but the description could be more explicit.
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 compact (two sentences) and front-loaded with the primary action. It efficiently communicates the core purpose and the key output elements without any fluff. Every clause adds informational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description reasonably details the returned 'cognitive portrait' and its components. It also implies an optional parameter through the schema. It does not mention example use cases or potential caveats, but for a read-only analysis tool, this is largely sufficient.
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 schema covers 100% of the parameter ('domain') with its own description, so the baseline is 3. The tool description does not add any additional semantic meaning about how 'domain' affects the analysis, but the schema already provides sufficient context.
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 uses a specific verb ('Analyze') and a clear resource ('knowledge graph'), and it enumerates concrete outputs ('knowledge islands, bridge concepts, dense/sparse regions') that differentiate it from sibling tools like discover_connections or detect_blindspots. The purpose is unmistakable and distinct.
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 for obtaining a high-level structural overview and connectivity recommendations, but it does not explicitly state when to use this tool over siblings or provide exclusions. The context is clear from the output described, but there is no direct guidance on choosing alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the write operation ('store') and input constraints, but omits side-effect details such as whether existing entities are overwritten, idempotency, or permissions. It also doesn't mention what happens if both content and file_path are provided.
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?
Two sentences with no redundancy: the first states the core purpose, the second clarifies input flexibility. Density is high and front-loaded.
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?
For a tool with no annotations and no output schema, the description should mention the return value or success indication. It explains the main purpose and input well, but leaves out expected output and error/edge-case behavior, leaving some gaps for an agent.
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% for both parameters, and the descriptions in the schema already convey the OR relationship. The tool description adds no new meaning beyond a brief restatement of the input options, so baseline 3 applies.
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 the action ('Extract knowledge entities and relationships') and the resource ('personal knowledge graph'), distinguishing it clearly from sibling tools that query or analyze. The verb+resource structure is precise and unambiguous.
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 implies usage for ingesting notes into the knowledge graph and clearly notes the two accepted input modes. It doesn't explicitly contrast with sibling tools or state when not to use this tool, but the context is strong enough for a competent agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the mechanism ('colliding concepts') and outcome ('unexpected connections'), but does not disclose side effects, prerequisites, randomness, or return format. This is adequate for a creative two-parameter tool but leaves many behavioral details implicit.
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?
Two sentences, front-loaded with the primary verb and resource, followed by a clarifying metaphor. Every word contributes to conveying purpose and method; no filler or redundancy.
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?
With only two simple string parameters and no output schema/annotations, the description covers the high-level purpose and outcome ('find unexpected connections'). It lacks specifics about the output structure and differentiation from related tools, but is not grossly incomplete for a lightweight creative tool.
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% with basic descriptions, but the tool description adds semantics: the domains must be 'different' and concepts are 'collided' to produce novel connections. This extra guidance is not present in the schema, raising the value above baseline.
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 states a specific action ('deliberately spark creative inspiration') with a clear method ('colliding concepts from two different knowledge domains') and expected result ('find unexpected connections'). This distinguishes it from sibling tools like discover_connections by emphasizing cross-domain collision for creative novelty.
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 phrase 'Deliberately spark creative inspiration' implies a use case—use when you want cross-domain creative connections. However, it never explicitly contrasts with alternatives such as discover_connections or detect_blindspots, leaving the agent to infer when this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read-only analysis by using verbs like 'Analyze' and 'identify,' but it does not explicitly state that no data is modified, nor does it mention any prerequisites, permissions, or return format. This leaves some ambiguity about side effects.
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, front-loaded with the main action, and contains zero filler. Every clause adds meaningful information about the tool's purpose and benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description conveys the core purpose and expected outcome. It could be more explicit about the form of the output (e.g., a report or list) and any limitations, but it is sufficient for an agent to understand when to invoke it.
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 coverage is 100% with the parameter 'topic' described as 'The topic to analyze for blindspots.' The description merely reinforces this without adding new meaning or usage details. Baseline of 3 is appropriate because the schema already documents the parameter.
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 clearly states a specific action ('Analyze') on a specific resource ('coverage in your knowledge graph') and distinct outcomes ('blindspots, contradictions, and missing perspectives'). This differentiates it from sibling tools like query_mind or discover_connections, which focus on retrieval or connection-finding.
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 phrase 'Helps you understand what you don't know about a subject' provides clear context for when to use this tool. However, it does not explicitly mention alternatives or conditions that would make another tool more appropriate, so it stops short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the two modes but does not discuss output format, potential side effects, or resource implications of scanning the whole graph. There is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the core purpose, and every sentence contributes useful information. It avoids fluff and is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main input behavior and scope, which is sufficient for a simple tool. However, it lacks any detail about the output format or limitations (e.g., what happens if no connections are found). Given no output schema exists, this is a minor gap.
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 schema already provides a full description of the 'topic' parameter (coverage 100%), so the baseline is 3. The tool description repeats similar information and adds slight nuance ('cross-domain bridges') but does not significantly enhance understanding of the parameter beyond the 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 clearly states the tool's function: discovering hidden connections between knowledge entities across domains. It explicitly distinguishes itself from sibling tools (e.g., detect_blindspots, trace_concept_evolution) by focusing on cross-domain bridges. The two operational modes (with and without a topic) are also specified.
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 gives clear guidance on when to use the tool: when a topic is provided vs. when scanning the entire graph. It does not mention alternatives or when not to use it, but the conditional behavior is explicit enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the internal process: retrieving relevant entities/relationships, reasoning with an LLM, and supporting two depth modes. It does not mention side effects, but the query nature implies read-only 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 two concise sentences, front-loaded with the main purpose, followed by supporting details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description adequately covers purpose, mechanism, and modes. It lacks an explicit description of the return value, but 'Answer a question' implies a textual answer.
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 already covers both parameters with descriptions, reaching 100% coverage. The description repeats the depth definition but adds no additional semantic value beyond what the schema provides.
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 clearly states the tool's purpose: answering a question using a personal knowledge graph, with retrieval and reasoning. It distinguishes from sibling tools by focusing on question-answering and explicit depth modes.
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 for question-answering over the knowledge graph, but it does not explicitly compare to alternatives like recall_context or discover_connections, nor does it state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose behavioral traits: it 'Shows a timeline of belief changes, key turning points, and what triggered each shift.' This goes beyond the name and gives useful expectations about the output. It does not mention underlying data sources or potential side effects, but the tool is clearly a read-only analysis operation.
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 concise sentences, front-loaded with the main action and followed by concrete output details. Every phrase earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one simple parameter and no output schema, the description is adequately complete. It states both the purpose and the nature of the returned information (timeline, turning points, triggers), so an agent has enough context to invoke it correctly.
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 coverage is 100% with the single parameter 'concept' described as 'The concept name to trace evolution for.' The description repeats this concept but adds no additional parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 uses a specific verb ('Trace') and resource ('concept evolution'), clearly distinguishing it from sibling tools like query_mind or discover_connections. It explicitly defines the tool's scope as temporal evolution of understanding.
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 when a user wants to see how their understanding of a concept has changed over time, but it does not explicitly contrast with siblings like query_mind or recall_context. No when-not-to-use guidance or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the tool surfaces notes/ideas from the knowledge graph, implying a read-only retrieval operation. It also adds the helpful context that it targets forgotten information, giving insight into its purpose and expected output. It does not disclose potential limitations or side effects, but the verb 'surface' suggests no mutation, which is adequately transparent.
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 extremely concise at two sentences, front-loading the use case and action. The first sentence clearly states what the tool does, and the second adds value by explaining the benefit ('connect current work with past knowledge'). Every word earns its place, with no unnecessary detail or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two simple parameters and no output schema, the description covers the essential context: what it does, when to use it, and the source (knowledge graph). It doesn't describe the return format in detail, but 'surface' implies a list of notes/ideas, which is sufficient given the tool's simplicity. The description also clarifies its role among siblings by emphasizing the writing context.
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 already provides 100% coverage for both parameters (current_text and max_results), so the description does not need to add much. It does not go beyond the schema, though it reinforces the purpose of current_text by tying it to 'while writing'. This matches the baseline of 3 for high schema coverage.
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 uses a specific verb ('surface') and resource ('related notes and ideas from your knowledge graph'), clearly stating the tool's function. It distinguishes itself from siblings by framing the use case explicitly as 'while you are writing', which sets it apart from tools like query_mind or discover_connections. The purpose is immediately clear and actionable.
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 a clear context for when to use the tool: 'While you are writing'. This implies the user is drafting content and needs to recall relevant past knowledge. However, it does not explicitly mention when not to use it or name alternative sibling tools, so it falls short of a 5 but is still well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![cognitive-exoskeleton-mcp MCP server](https://glama.ai/mcp/servers/hanjiang-215/cognitive-exoskeleton-mcp/badges/card.svg)](https://glama.ai/mcp/servers/hanjiang-215/cognitive-exoskeleton-mcp)

Score Badge

Copy to your README.md:

[![cognitive-exoskeleton-mcp MCP server](https://glama.ai/mcp/servers/hanjiang-215/cognitive-exoskeleton-mcp/badges/score.svg)](https://glama.ai/mcp/servers/hanjiang-215/cognitive-exoskeleton-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hanjiang-215/cognitive-exoskeleton-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server