cognitive-harness-mcp

by gwq0514

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct operation: search, list, stats, summary, write, update, and forget are clearly separated by purpose. Search and list both retrieve memories but are differentiated by query-based filtering versus chronological browsing.
Naming Consistency4/5
All tools share the cognitive_ prefix and mostly use verb-style names like cognitive_search, cognitive_write, and cognitive_update. The pattern is slightly weakened by noun-style names cognitive_stats and cognitive_summary, but the convention remains highly predictable.
Tool Count5/5
Seven tools is well-scoped for a memory management server: full CRUD plus search, statistics, and aggregated summary. Each tool earns its place without redundancy or bloat.
Completeness5/5
The tool surface fully covers the memory lifecycle: write, read via search/list/summary, update, and forget with both degrade and delete modes. The addition of stats and summary fills retrieval and introspection needs, leaving no obvious gaps.
Average 4.2/5 across 7 of 7 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds ordering and pagination context, but it claims '默认返回最近 20 条' while the schema's limit default is 50—an internal contradiction that makes the described behavior misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core behavior, which is good. However, the final clause about defaulting to 20 entries is not only unnecessary but contradicts the schema, so the sentence does not fully earn its place.
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 simple read-only paginated list tool, the schema and annotations carry much of the needed information. Still, the default discrepancy between description and schema, plus the absence of any guidance distinguishing this from cognitive_search, leaves meaningful gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for limit and offset, so a baseline of 3 is warranted. However, the description introduces inaccurate parameter-related information by stating a default of 20 items while the schema specifies limit default 50, which actively undermines correct invocation.
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 a specific verb and resource: listing all user memories in reverse chronological order with pagination. The phrase '全部用户记忆' differentiates it from search-oriented siblings like cognitive_search, though it does not explicitly name any sibling.
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?
'用于浏览记忆全貌' gives a clear scenario for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives such as cognitive_search or cognitive_summary, so it falls short of full routing 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?
Annotations already indicate this is a non-read-only, non-destructive write operation. The description adds some context, such as requiring causal explanations for rule-type memories and returning a new memory_id, but it does not disclose duplicate behavior, overwrite semantics, or permission requirements. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with its purpose and use cases, and the Args/Returns sections are scannable. However, the Args list largely duplicates the input schema, and the phrase '见下方枚举说明' points to an enumeration that is not actually present in the description text.
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?
It covers when to use the tool, rule-content guidance, several defaults, and an explicit return shape, which is valuable because no output schema exists. It does not explicitly mention using cognitive_update for edits or explain message_id/conversation_id, but the schema fills those gaps.
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%, so the description is not required to explain every parameter. It mostly repeats the schema's parameter list and adds limited new meaning. The 'must' wording for causal explanations conflicts slightly with the schema's '建议' (recommended) wording, which reduces reliability.
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 opens with a specific action-resource pair ('写入一条关于用户的认知记忆') and enumerates the content categories it supports, making the tool's purpose clear. It does not explicitly contrast itself with siblings like cognitive_update or cognitive_forget, so it stops short of a 5.
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?
It explicitly states when to use the tool: for factual facts, preferences, rules, implied meanings, emotional patterns, values, workflows, and important events. It lacks exclusions or direct references to sibling tools for alternative operations, which prevents a top score.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds useful behavioral details beyond the annotations, such as the two output formats (system_prompt vs markdown) and the return shape including summary and memory_count. There is no contradiction with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a one-sentence summary of purpose and content, a one-sentence usage recommendation, and a brief Args/Returns breakdown. Every sentence adds value and the most important information is front-loaded.
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 that there is only one optional parameter, rich annotations, and no output schema, the description is complete enough. It explains the return value explicitly and describes both possible format values, so an agent has everything needed 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?
The input schema has 100% description coverage for the only parameter, including an enum, a default value, and a clear explanation of each format option. The description repeats this information but does not add meaning beyond what the schema already provides, so it earns the baseline score.
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: it returns a compressed user cognitive profile ("印象") with specific content categories like interaction preferences, core profile, domain cognition, known facts, and follow-ups. It distinguishes itself from item-by-item retrieval by explicitly claiming to be more efficient, making it easy to separate from siblings like cognitive_search and cognitive_list.
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 explicitly says when to use it: at the start of a conversation or when a comprehensive understanding of the user is needed. It also frames the tool as more efficient than per-item retrieval. However, it does not name specific alternative sibling tools or state when not to use it, so it stops one step short of full usage guidance.
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?
Beyond annotations, the description discloses key behavioral details: the operation is a partial update, returns an error when the memory is missing, and returns the full updated entry or null. This adds meaningful context without contradicting the idempotentHint annotation.
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 compact and well-structured, with a clear opening statement followed by Args and Returns sections. The Args list is slightly redundant with the schema, but the Returns section is essential since no output schema exists.
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 an 8-parameter mutation tool with no output schema, the description covers the essential contract: update behavior, error case, return shape, and updatable fields. It could go further with an example, but nothing critical is missing.
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%, so the baseline is 3. The description adds value by clarifying partial-update semantics (only provided fields are updated) and by pointing out that memory_id can be sourced from cognitive_search/cognitive_list.
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 precise operation—partial update of an existing memory—and explicitly notes the error case when the memory is not found. This clearly distinguishes it from sibling tools like cognitive_write or cognitive_forget.
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 clearly implies this tool is for updating an already-existing memory, and even tells the agent where to obtain the memory_id (cognitive_search / cognitive_list). However, it does not explicitly state when to prefer this over cognitive_write or avoid using it for creation.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior, lowering the burden on the description. The description adds value by naming the exact categories of statistics returned, giving concrete behavioral context about the tool's output without contradicting any annotation.
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 one tight sentence that leads with the action verb, lists the concrete statistics, and closes with the intended purpose. Every clause contributes information; there is no redundancy or filler.
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?
With no output schema, the description rightly carries the burden of explaining the return payload and does so by listing the main statistical categories. It remains slightly incomplete because it does not specify the exact format (counts vs. percentages) or the structural shape of the response, and it does not explicitly distinguish itself from cognitive_summary.
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 schema description coverage is vacuously 100%, so the baseline is 4. The description compensates by detailing what the no-argument call returns—total, type distribution, domain distribution, and confirmation-rule count—making the empty input schema meaningful.
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 specifies a verb ('返回', returns) and a resource ('记忆存储的统计信息'), then enumerates the exact metrics: total, distribution by type, distribution by domain, and confirmed-rule count. This makes it easily distinguishable from sibling tools like cognitive_search and cognitive_write.
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 a clear usage context—'用于了解记忆覆盖面' (for understanding memory coverage)—which tells an agent when a stats overview is appropriate. However, it does not explicitly contrast with cognitive_summary or cognitive_list, so an agent might still be unsure which aggregate view to pick among those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses critical behavioral detail: degrade preserves the evidence chain and halves confidence, while delete is permanent and unrecoverable. This gives the agent essential awareness of side effects and irreversibility, which annotations alone do not fully convey.
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, front-loaded with the core action, and logically organized with Args and Returns sections. Every line adds value, and there is no filler or redundant elaboration.
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?
Even without an output schema, the description explicitly specifies the return shape: { success: boolean, mode: string }. It also covers both modes, their side effects, default behavior, and the optional reason parameter. This is sufficient for an agent to invoke the tool correctly and understand the result.
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?
The schema already documents all parameters with 100% coverage, so the baseline is 3. The description adds meaningful behavioral semantics, particularly that degrade halves confidence and delete is irreversible, going beyond the schema's enum descriptions. The Args section also clearly marks reason as optional.
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 core action: '删除或降级一条用户记忆' (delete or degrade a user memory). It further specifies two distinct modes with concrete semantics, making it easily distinguishable from sibling tools like cognitive_search, cognitive_write, and cognitive_update.
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 clear situational guidance: degrade is recommended when '用户想法变了' (the user's thoughts changed), while delete is for complete removal and marked as irreversible. It does not explicitly mention alternative sibling tools for non-destructive updates, but the mode-selection guidance is clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description goes beyond annotations by disclosing confidence-based ordering, pagination, empty-result semantics (total=0 empty list is not an error), and the include_dynamic default. This is rich, non-obvious behavioral context.
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 well-organized into purpose, usage guidance, args, return shape, examples, and error handling—each section earns its place. Core purpose and usage are front-loaded, and the length is appropriate given the tool's complexity.
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?
The description documents all parameters, the exact return object structure, pagination behavior, example queries, and error semantics. Nothing an agent needs to invoke the tool correctly is missing, and the usage context is clear.
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%, so the baseline is 3. The description adds value with natural-language examples mapping to keyword/domain parameters and restates all defaults and filters. However, there is a minor inconsistency: the Args list says 'emotion' while the schema enum uses 'emotional', which could mislead an agent.
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 verb ('检索' = retrieve) and resource ('用户认知记忆'), and clarifies it returns relevant memory entries sorted by confidence with pagination. The '当对话涉及...' clause clearly distinguishes it from sibling write/update/forget tools. An agent can tell this is the retrieval tool among the siblings.
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 explicitly lists trigger conditions (historical preferences, identity, ongoing projects, past events) and instructs to call this tool before answering to avoid guessing. It does not explicitly contrast with cognitive_list or cognitive_stats, so it misses a full when-not/alternative comparison, but the guidance is strong enough for correct selection.
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-harness-mcp MCP server](https://glama.ai/mcp/servers/gwq0514/cognitive-harness-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gwq0514/cognitive-harness-mcp)

Score Badge

Copy to your README.md:

[![cognitive-harness-mcp MCP server](https://glama.ai/mcp/servers/gwq0514/cognitive-harness-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gwq0514/cognitive-harness-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/gwq0514/cognitive-harness-mcp'

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