zhiji-memory

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation5/5
Each tool targets a distinct operation: memory assembly, search, ingestion, profile/facts retrieval, status, proactive reminders, and feedback. Even the similar workspace_assemble and memory_search are clearly differentiated by depth (inference vs recall-only). No overlapping purposes.
Naming Consistency4/5
All tools use snake_case with 'zhiji_' prefix, but verb placement varies: some are verb_noun (workspace_assemble, memory_search), others noun_verb (profile_get, facts_get), and 'status' is just a noun. Minor inconsistency but still predictable and readable.
Tool Count5/5
9 tools is well-scoped for a memory server. Each tool serves a clear need: ingest (text and file), search (light and heavy), retrieve profile/facts, status check, proactive reminders, and feedback. Nothing feels extraneous or missing.
Completeness3/5
Covers creation (ingest) and retrieval (search, profile, facts) well, but lacks update/delete tools for memories. Feedback allows quality adjustments but not content modifications. Prospective and status are nice additions, but lack of full CRUD is a notable gap.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 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 MIT License.
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 must disclose behavioral traits. It states the output is a natural language summary, but lacks details on side effects, permissions, or data freshness.
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, with two efficient sentences that first describe the tool's function in detail and then specify the output form. 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?
Given the complexity of a 7-layer profile, the description provides a good overview. However, it could mention output structure or limitations, especially without an output schema.
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 only parameter is userEmail, with a clear schema description. The description adds no extra semantic information beyond the schema, so a baseline score of 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 clearly states the tool gets a text summary of user profile, specifying the 7 layers and 36 dimensions. It distinguishes from sibling retrieval tools like zhiji_memory_search and zhiji_facts_get by focusing on a comprehensive profile.
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 for obtaining a profile summary suitable for system prompts, but does not explicitly state when to use this tool over siblings or any conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or side effects. For a simple status check, minimal transparency is offered beyond the basic purpose.
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 a single, concise sentence that efficiently communicates the tool's function and key outputs with no superfluous information.
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 no output schema, the description covers the main return values (health status, file count, etc.). It lacks detail on response format or interpretation, but for a simple status tool it is mostly complete.
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?
With zero parameters, the baseline is 4. The description adds meaning by specifying the output metrics (file count, memory blocks, FTS availability), which compensates for the absence of parameter documentation.
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 queries memory-bridge service health status and scale, specifying file count, memory block count, and FTS availability. Its purpose for connectivity diagnosis is explicit, and it distinguishes from sibling tools that handle workspace, search, ingest, etc.
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 connectivity diagnosis but does not explicitly state when to use or not use this tool over alternatives. No sibling differentiation or exclusions are provided.
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 must convey behavioral traits. It mentions the output includes structured facts with subject attribution, confidence, and conflict status, but does not disclose data freshness, permission requirements, or side effects. For a read-like operation, this is adequate but minimal.
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 consists of two concise sentences: the first states the core function and output format, the second adds usage guidance. Every word serves a purpose with 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?
Given the tool has one optional parameter and no output schema, the description covers the essential purpose, output characteristics, and typical use cases. It could be improved by specifying the exact output structure or data source, but is sufficient for an agent to select and understand the tool.
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 complete coverage for the single parameter 'userEmail' with a description. The tool description adds no additional semantics beyond the schema, meeting the baseline but not exceeding it.
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 retrieves a list of structured facts from conversations, specifying attributes like subject attribution, confidence, and conflict status. It distinguishes itself from narrative memory tools by emphasizing precise facts, and provides concrete use cases (verifying names/dates/quantities). The verb '获取' and resource '结构化事实清单' are specific 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 explicitly indicates scenarios where this tool is suitable (precise fact-checking) and contrasts with narrative memory, implying when not to use it. However, it does not name alternative sibling tools directly (e.g., zhiji_memory_search), leaving the agent to infer the distinction.
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 provided, so description must disclose behavioral traits. It mentions data source (zhiji prospective monitor) but doesn't state if operation is read-only, requires permissions, or has rate limits. For a query, read-only nature is implied but not 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?
Three sentences: first states purpose and return, second gives use case, third cites data source. No redundant words, front-loaded with key information.
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 tool with two optional parameters and no output schema, the description adequately covers purpose, return fields, and usage context. Could mention return format more precisely, but acceptable.
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 descriptions for both parameters. The description adds context about 'hours' being the scanning window but doesn't enrich parameter meaning beyond what schema already provides. Baseline score of 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 clearly states the tool queries upcoming/imminent prospective intentions (to-dos, promises, plans) and returns specific fields. It distinguishes from sibling tools like zhiji_memory_search or zhiji_profile_get by focusing on proactive reminders.
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?
Explicitly says 'suitable for agent to proactively remind user it's time to do something', giving clear use context. Doesn't specify when not to use, but sibling tool names and descriptions provide sufficient differentiation.
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?
No annotations are provided, so the description carries full burden. It discloses behavioral traits such as latency (10-15 seconds for slow-thinking queries involving LLM inference) and lists returned components. However, it does not explicitly state read-only nature or idempotency, which is acceptable given the context.
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 well-structured with the main purpose first, followed by a list of components and a note on latency. It is detailed but not overly verbose; every sentence adds value. Slightly longer than necessary but efficient.
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 the absence of an output schema, the description adequately lists the key return components (memoryContext, profile, factContext, etc.) and mentions behavioral aspects (latency for certain queries). For a tool with three parameters and moderate complexity, it is sufficiently complete.
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 descriptions for all three parameters. The description adds meaning beyond the schema by explaining the query's role, providing default values for userEmail (MB_USER_EMAIL) and maxResults (6), and clarifying usage 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 clearly states the tool assembles '知己的统一记忆上下文' (unified memory context) for a query, listing specific components (memoryContext, profile, factContext, etc.) and positioning it as a one-stop entry for injecting user understanding into LLM conversations. This distinguishes it from siblings like zhiji_memory_search (memory search only) and zhiji_profile_get (profile only).
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 this is the primary comprehensive tool for assembling context ('一站式入口'), but does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisites. The guidance is mostly implicit.
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?
The description details the internal search pipeline (11-stage hybrid search), but does not explicitly state that the tool is read-only or safe. As no annotations are provided, the description carries full burden; it is mostly transparent but lacks explicit assurance of no 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 concise sentences, front-loaded with the core function and technical detail, followed by usage context. Every part is informative and no words are wasted.
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 what the tool does, how it works, and when to use it. It mentions the return format (memory fragments with source and score). However, it does not specify pagination or sorting behavior, which could be useful for a search tool.
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%, so baseline is 3. The description adds context about return format (source and score) but does not add meaning beyond the schema for the three parameters. It does not compensate for any gaps, as there are none.
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 performs a hybrid search in long-term memory using full-text trigram, vector semantics, and time decay, returning memory fragments with source and score. It distinguishes itself from sibling 'workspace_assemble' by being lighter and focused on recall without reasoning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says '比 workspace_assemble 轻量,适合只要召回不要推理的场景' (lighter than workspace_assemble, suitable for scenarios needing only recall without reasoning), providing clear guidance on when to use this tool versus an alternative.
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?
Describes the behavioral impact in detail: feedback enters the self-evolution reward signal (implicitPositiveRate) and performs Q-value reinforcement on recently retrieved memory blocks. It explains the effect of the 'weak' parameter (halving intensity). No annotations were provided, so the description fully carries the burden of transparency.
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 yet comprehensive, front-loading the core purpose and then detailing effects and parameters. Every sentence adds value without redundancy. The structure is logical: purpose, mechanism, parameter notes, and usage caveat.
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 the tool's complexity (5 parameters, no output schema), the description covers input semantics and behavioral effects well. It lacks explicit mention of the return value (e.g., success/failure), but this is minor since the focus is on submitting feedback. Overall, it provides sufficient context for effective use.
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 baseline is 3. The description adds value by explaining the 'weak' parameter's effect (halving intensity for uncertain feedback) and the meaning of 'up' and 'down' ratings in the context of memory reinforcement. This goes beyond the schema's basic descriptions.
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?
Description clearly states the tool's purpose: submitting explicit feedback (up/down) for the last memory recall/answer quality. It distinguishes itself from sibling tools like zhiji_memory_search and zhiji_workspace_assemble, which are for searching or assembling memories, not feedback.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives. It notes that for precise feedback on specific memory blocks, one should first call zhiji_workspace_assemble or zhiji_memory_search. This helps the agent choose the right tool.
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?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It mentions the specific extraction pipelines (Whisper, Tesseract OCR, document parsing), warns about the time-consuming nature of audio/video transcription on CPU, and details the acoustic emotion analysis, including how isUserVoice affects user profile versus emotion library. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structurally well-organized, starting with the core purpose and sibling distinction, then source options, performance warning, and emotion analysis. It is somewhat lengthy but every sentence adds value. Could be slightly more concise, but the clarity and completeness justify a high score.
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 the complexity of the tool (multiple file types, pipelines, performance issues, emotion analysis, parameter interdependencies), the description is comprehensive. It covers what the tool does, how to use it, important caveats, and behavioral traits. However, it lacks explicit mention of return values or confirmation of success, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds significant meaning beyond the schema. It explains the rationale behind isUserVoice (acoustic emotion into user profile vs just library), clarifies that filename is used for type detection, and provides context for the three source options with usage recommendations. This enrichment justifies a score above the baseline of 3.
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: ingesting files (audio, images, PDF, etc.) via extraction pipelines (Whisper, OCR, document parsing) into long-term memory. It explicitly distinguishes from the sibling tool zhiji_memory_ingest which only accepts text, using the phrase '只收文本' (only accepts text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: for files like audio, images, documents, versus zhiji_memory_ingest for plain text. It explains the three source options (path, url, base64) with appropriate use cases and warnings (e.g., '大文件不建议内联' for base64). It also warns about timeouts for audio/video transcription and cautions about misusing the isUserVoice parameter.
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?
No annotations provided, but description fully carries the burden: discloses asynchronous behavior (vector embedding, profile extraction, fact extraction, importance scoring) and the limitation to text-only input.
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?
Concise, front-loaded with main action, then covers async processing, then constraints and alternatives. Every sentence is informative with no waste.
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?
For a tool with 4 parameters, 2 required, no output schema, the description provides all necessary context: what it does, how it works, constraints, alternatives (zhiji_ingest_file). The agent can correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions; description adds extra context: messages pairing requirement, default userEmail from MB_USER_EMAIL, and that conversationId appends to the same conversation.
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?
Clearly states it writes a conversation round into long-term memory, distinguishes from zhiji_ingest_file for non-text files, and explains the asynchronous processing that follows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use zhiji_ingest_file instead (for non-text inputs). Also provides constraints: messages must be paired user-assistant with at least one user message, and conversationId can be reused to append.
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:

[![zhiji-mcp MCP server](https://glama.ai/mcp/servers/xfhxxffhh224/zhiji-mcp/badges/card.svg)](https://glama.ai/mcp/servers/xfhxxffhh224/zhiji-mcp)

Score Badge

Copy to your README.md:

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

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