A
licenseNot graded
qualityC
maintenanceEnables searching and retrieving Claude Code conversation history via hybrid semantic and keyword search, allowing the agent to access its own past interactions.
4
MIT
hist-bridge
by maqitong
hist-bridge is an MCP server that bridges conversation history across multiple AI coding agents (Claude Code, Codex, Cursor, GLM), enabling seamless context handoff and continuation between tools.
list_sources()– Check which conversation sources (claude, codex, cursor, glm) are configured and available.list_conversations()– Browse past sessions across all sources, filterable by source, project path, title keyword, and limit (up to 200), sorted most-recent-first.get_conversation()– Load a full conversation as a Markdown transcript, compact handoff summary card, or structured JSON, with options to limit messages and include/exclude tool calls and reasoning traces.search_conversations()– Full-text search across conversation titles, message bodies, and tool call arguments/results, returning matches with snippets (up to 100 results).summarize_conversation()– Deterministically generate a handoff card (goals, completed work, blockers, to-dos, status) without using an LLM — ideal for long sessions to save context tokens.Thread management – Link multiple cross-tool conversations into logical threads; list, retrieve merged transcripts, summarize, append, or unlink threads.
Debug CLI – Test functionality directly without MCP: list, get, summarize, search.
Supports Claude Code, Codex, Cursor, and GLM, with configurable source paths and integration via MCP server registration or Claude Code plugin (enabling /resume commands and continue-foreign skills).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@hist-bridgelist my recent codex conversations"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
hist-bridge
用多个 AI 编程 Agent 协作时,在它们之间无缝衔接同一个对话。
当你用 Claude Code、Codex、Cursor 等多个 Agent 编码时——它们各有所长,但上下文断在每个工具里、互不相通。hist-bridge 把它们打通:在当前 Agent 里列出 / 搜索 / 摘要 / 载入其它 Agent 的历史会话,把它当作上下文接着往下做;再用「会话链 (thread)」把跨工具的多次往返当成一个连续对话来统一管理。
一句话:同一个编码任务,让不同 Agent 协同接力,而不是各聊各的。 想用 Codex 起草、用 Claude 深挖、用 Cursor 调,中间不丢上下文——这就是 hist-bridge 解决的事。
实现上是上下文接力(把历史对话作为上下文喂给当前 Agent 继续),不是无损的完整状态重放——跨厂商的内部推理状态/工具执行状态无法迁移。对"接着聊、接着做"而言完全够用。
支持来源:Claude Code、Codex、Cursor(含在 Cursor 里用 GLM 跑的会话)、以及另一个 z.ai 后端的 Claude Code(GLM)。
它能读哪些历史
来源 (source) | 存储 | 说明 |
|
| Claude Code 原生 transcript |
|
| Codex CLI rollout |
|
| Cursor 的 composer/bubble;在 Cursor 里用 GLM 跑的会话也在这里,按 model 区分(GLM-5/GLM-5.1) |
| 另一个 Claude Code(z.ai 后端)的 | 与 claude 同格式,默认关闭,需配 root |
Related MCP server: Claude Code History MCP
暴露的 MCP 工具
list_sources()— 列出已配置来源及是否可用。list_conversations({source?, project?, query?, limit?})— 列历史会话,按时间倒序。get_conversation({source, id, format?, max_messages?, include_reasoning?, include_tools?})— 把某次会话渲染成可续接内容。format:markdown(完整 transcript,默认)|summary(紧凑交接卡)|json(结构化)。summarize_conversation({source, id})— 抽取式压缩成「🎯目标 / ✅已完成 / ⚠️卡点 / 📋待办 / 🧭最后状态」交接卡。无需 LLM、确定性、省上下文,长会话优先用它。search_conversations({query, source?, limit?})— 跨来源全文检索(先标题,后正文)。
会话链 (thread) —— 把跨工具的多次会话当成一个连续对话:
link_thread({title?, members:[{source,id}...]})— 把若干会话按 hop 顺序标记为同一条逻辑对话。list_threads()— 列出所有链及成员(含每个成员是否可用)。get_thread({thread_id, format?, max_messages?})— 把整条链的成员会话按序合并成一个连续转写;自动剥掉 hist-bridge 自己嵌入过的转写块(# 历史会话:/# 🗂 交接摘要:)避免历史重复。summarize_thread({thread_id})— 对整条链出一张交接卡。append_to_thread({thread_id, source, id})— 在另一个工具续接产生新会话后,把它接到链尾。unlink_thread({thread_id})— 删除链(只删关联,不动底层会话)。
线程元数据存在用户级目录(win:%APPDATA%\hist-bridge\threads.json;mac/linux:~/.config/hist-bridge/threads.json),可用 HIST_BRIDGE_THREAD_STORE 覆盖。典型用法:在 Claude 聊→载入 Codex 续→link_thread claude:<id> codex:<新id>→以后任一工具 get_thread/summarize_thread 就能把整条往返当一个对话载入,不再套娃。
摘要器(省上下文)
长会话(几十上百条消息)直接全量载入会吃掉大量上下文。summarize_conversation / format:"summary" 用确定性规则从归一化对话里抽取:首条用户消息→目标;write/edit 工具参数→改动文件;shell 命令→已运行命令;isError 结果→卡点;工具自带的 todo 列表(Cursor todos、Claude TodoWrite)→待办;最后一条真实用户/助手消息→当前状态。一张卡通常只有原文的几十分之一,但保留了「目标 + 进度 + 下一步」——续接问答足够。
安装
npm install
npm run build # 生成 dist/在 Claude Code 用
方式 A — 直接注册 MCP server(最快):
claude mcp add --scope user hist-bridge -- node "<绝对路径>/hist-bridge/dist/server.js"之后在 Claude Code 里直接说:「列出我最近的 codex 对话」「把第 3 个载进来接着聊」。重启 Claude Code 生效。
方式 B — 作为插件安装(额外带 /resume 命令和续接技能):
本仓库已是合法插件结构(.claude-plugin/plugin.json 内联了 MCP server 声明,外加 commands/ + skills/)。通过你的插件 marketplace 或本地插件机制安装后,会多出:
/hist-bridge:resume [codex|glm|claude|搜索词]斜杠命令continue-foreign技能(自动梳理目标/已完成/未完成再续接)
在 Codex 用
编辑 ~/.codex/config.toml,加:
[mcp_servers.hist-bridge]
command = "node"
args = ["<绝对路径>/hist-bridge/dist/server.js"]
startup_timeout_sec = 20然后在 Codex 里就能调 list_conversations / get_conversation 等工具。Codex 自己的历史它本来就能 codex resume;这个 server 额外给它跨工具 + 统一检索。
配置 GLM 来源
GLM 有两个去处,按你怎么用分别覆盖:
在 Cursor 里用 GLM → 已被
cursor来源自动覆盖,按model字段(GLM-5 / GLM-5.1 等)就能认出来,无需额外配置。在另一个 z.ai 后端的 Claude Code 里用 GLM(文件格式同 Claude Code)→ 启用
glm来源:环境变量(最简单):
HIST_BRIDGE_GLM_ROOT=<那个实例的 projects 目录>(自动启用)。或改
config.json里sources.glm.root并把enabled设为true。若那份历史在另一台机器,把对应的
.jsonl同步过来再指向即可。
Cursor 来源说明
默认按平台自动探测
state.vscdb路径(win/mac/linux);也可在config.json的sources.cursor.root指定。读取时会先把
state.vscdb拷到临时目录再以只读打开,不碰你正在运行的 Cursor,也不会写回。同一个库里也存着
cursorAuth/*令牌——本工具只读composerData/bubbleId,不会导出这些密钥。
调试 CLI(不连 MCP 直接试)
npm run cli -- sources
npm run cli -- list [codex|cursor|glm|claude] [--project X] [--query Y] [--limit N]
npm run cli -- get <source> <id> [--max N] [--json] [--reasoning]
npm run cli -- summarize <source> <id> # 紧凑交接卡
npm run cli -- search <关键词> [source]已知边界
会话格式是各工具私有且会变的;解析器做了防御,但厂商改格式时可能需要更新适配器。
Codex 的推理(reasoning)是加密的,无法还原;Claude 不在 transcript 里存 system prompt(Codex 存),归一化时会体现这种不对称。
search_conversations的正文扫描有数量上限(默认 60 个会话)以控制开销;标题命中不受限。Cursor 读取依赖 Node 内置
node:sqlite(需 Node ≥ 22.13,本机 Node 24 直接可用;旧版本上 cursor 来源会被报为不可用而非报错)。读取时把state.vscdb连同-wal/-shm一起拷到私有临时目录(0600 权限、进程退出即删),以只读方式打开;副本含cursorAuth/*令牌,故不落在共享/tmp、用完即清。摘要器是确定性抽取式,不调 LLM:目标取首条用户消息、已完成取工具调用、卡点取报错结果、待办取工具原生 todo 列表——它不"理解"语义,只做高信噪比的结构化提取。
Available Tools
5 toolsget_conversationLoad a past conversationA
Load the full content of one past conversation (by source + id) as a readable Markdown transcript, so you can continue it. Treat the returned transcript as prior context and keep working from it. Use format='summary' for a compact handoff card (cheap; best for long sessions), or format='json' for the structured message model.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | conversation id from list_conversations | |
| format | No | 'markdown' full transcript (default) | 'summary' compact handoff card | 'json' structured | |
| source | Yes | 'claude' | 'glm' | 'codex' | 'cursor' | |
| max_messages | No | keep only the last N messages (for long sessions) | |
| include_tools | No | include tool calls/results (default true) | |
| include_reasoning | No | include assistant thinking (default false) |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It explains the output format and context usage, but it omits important details about parameters like max_messages, include_tools, and include_reasoning, as well as any side effects, permissions, or rate limits.
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 three sentences, front-loaded with the core purpose, followed by guidance on output usage and format options. Every sentence adds value without 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?
Given the tool has 6 parameters, no annotations, and no output schema, the description covers the main purpose and format guidance but does not elaborate on the behavior of parameters like max_messages, include_tools, and include_reasoning, leaving gaps in completeness.
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 value for the 'format' parameter by explaining use cases for 'summary' and 'json', but it does not enhance meaning for the other five parameters 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 loads a past conversation by source and id as a readable Markdown transcript, with the specific purpose of continuing it. The verb 'Load' and resource 'past conversation' are precise, and the tool's function is distinct from siblings like list_conversations or search_conversations.
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 provides guidance on when to use different format options (summary for compact handoffs, json for structured models), but it does not explicitly contrast with sibling tools or state when not to use this tool versus alternatives like summarize_conversation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_conversationsList past conversationsA
List past AI coding conversations across tools (Claude Code, Codex, Cursor, GLM), most recent first. Use this to let the user pick a conversation to continue. Returns id, source, title, project, model, updatedAt, messageCount.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | max results (default 20) | |
| query | No | substring match on the conversation title | |
| source | No | filter to one source: 'claude' | 'codex' | 'cursor' | 'glm' | |
| project | No | substring match on project path / cwd |
TDQS
A4/5.0
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 describes the output fields and ordering but does not disclose potential side effects, rate limits, authentication needs, or behavior when no conversations exist. For a read operation, this is adequate but not exceptional.
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 three sentences, front-loaded with the main purpose, and contains no unnecessary words. Every sentence adds 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 the simple list structure, 4 optional parameters, and no output schema, the description covers the key aspects: what it lists, ordering, return fields, and use case. It lacks details on pagination limits or empty results, but the limit parameter covers pagination implicitly.
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 all 4 parameters, so the baseline is 3. The tool description does not add additional meaning beyond what the schema already provides for each 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 the tool lists past AI coding conversations across specific tools, sorted most recent first, and identifies the return fields. It distinguishes itself from sibling tools like search_conversations by implying a broader, chronological listing.
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 states a use case: 'let the user pick a conversation to continue.' It doesn't explicitly exclude alternatives like search_conversations, but the context of a broad listing versus searching provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesList history sourcesA
List the configured conversation sources (claude, codex, cursor, glm) and whether each is available on this machine.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it lists configured sources and checks availability. No hidden or destructive actions are implied, and the description is transparent about the read-only nature.
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?
A single sentence that front-loads the action and necessary detail. No wordiness; every part is essential.
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?
Despite no output schema, the description sufficiently describes what the tool returns (list of sources with availability). For a parameterless tool, this is complete and actionable.
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 no parameters, so per the baseline rule (0 params = baseline 4). The description does not need to add parameter details since schema coverage is 100% trivially.
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 the tool lists configured conversation sources and their availability, with specific examples (claude, codex, cursor, glm). It clearly differentiates from sibling tools that deal with conversations themselves, not sources.
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 does not explicitly state when to use this tool versus alternatives or provide any usage context. It is straightforward but lacks guidance for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_conversationsSearch past conversationsA
Full-text search across past conversations (titles, message bodies, and tool results/args). Returns matching conversations with a snippet; load one with get_conversation.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | text to search for | |
| source | No | filter to one source: 'claude' | 'codex' | 'cursor' | 'glm' |
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses search scope and returns snippets, but does not mention pagination, ordering, case-sensitivity, or performance characteristics. Adequate but lacks some behavioral details a read-only search tool should disclose.
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 concise sentences, front-loaded with action, no redundant words. Every sentence adds 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 no output schema and 3 params, description covers search scope, return type (snippets), and links to get_conversation. Missing details like default limit, source enumeration reference, and potential pagination, but overall adequate.
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 67% (query described, source limited enum in description). Description adds context that query searches across titles, bodies, and results, but does not explain limit's default or behavior. Adds some value but not full compensation for missing parameter 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?
Clearly states full-text search across conversations including titles, message bodies, and tool results/args. Distinguishes from sibling tools like get_conversation (loads one) and list_conversations (likely lists without search).
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 to use this tool to search and then load with get_conversation. Implies not for loading full content, but does not explicitly mention when to use alternatives like list_conversations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_conversationSummarize a past conversationA
Return a compact 'handoff card' (目标 / 已完成 / 卡点 / 待办 / 最后状态) for one conversation, extracted deterministically without an LLM. Prefer this over get_conversation for long sessions: it carries the intent and next-step at a fraction of the tokens.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | conversation id from list_conversations | |
| source | Yes | 'claude' | 'glm' | 'codex' | 'cursor' |
TDQS
A4/5.0
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 states the summary is 'extracted deterministically without an LLM,' which is a useful behavioral trait. However, it does not explicitly state whether the tool is read-only or has side effects, leaving some ambiguity. For a tool that likely only reads data, mentioning it does not modify the conversation would improve 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 consists of two concise sentences. The first sentence defines the output format (handoff card with five fields). The second sentence provides usage guidance and comparison to sibling. No extraneous information; every sentence earns its place.
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 2 parameters, no output schema, and no annotations, the description adequately explains the return format (a structured handoff card) and the deterministic extraction method. It also guides usage in context of long sessions. However, it could be more complete by mentioning what the tool does NOT include (e.g., full conversation text) to set expectations further.
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 the baseline is 3. The description does not add any additional meaning about the parameters beyond what the schema already provides. The schema's descriptions ('conversation id from list_conversations' and the list of allowed sources) are sufficient, and the description doesn't need to repeat them.
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 'Return' and describes the output as a compact 'handoff card' with five deterministic fields (目标/已完成/卡点/待办/最后状态). It explicitly distinguishes from sibling tool 'get_conversation' by noting it is for long sessions, making purpose clear.
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 states 'Prefer this over get_conversation for long sessions' and explains why (carries intent/next-step at fewer tokens). This provides clear guidance on when to use the tool vs the sibling, though it does not explicitly mention 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.
TDQS
A4.1/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing conversations, searching, retrieving full content, summarizing, and listing sources. No two tools overlap in functionality.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (list_conversations, search_conversations, get_conversation, summarize_conversation, list_sources), making them predictable and easy to understand.
Tool Count5/5
With 5 tools, the server is well-scoped for its purpose of browsing and continuing past conversations. Each tool serves a necessary role without redundancy.
Completeness4/5
The tool surface covers the core workflows: listing, searching, retrieving full content, and summarizing. A delete or manage conversation tool is missing but not essential for the server's stated purpose.
Maintenance
ActivityStale
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Persistent cross-session memory shared by Codex, Claude Code, ChatGPT, and other AI agents.
Share context and questions between Claude instances — VS Code, claude.ai web, and mobile.
One identity across Claude Code, Codex, Cursor, Gemini, Windsurf: shared inbox and handoffs.
Shared memory for AI coding agents. Save once, reuse from Cursor, Claude Code, Codex.
Related MCP Servers
- AlicenseNot gradedqualityDmaintenanceSearch and reference your Claude Code conversation history directly from Claude, with full-text search, conversation viewing, and project browsing.28MIT
- AlicenseNot gradedqualityDmaintenanceEnables searching and browsing past Claude Code conversations directly from within an active Claude session, with full-text search and cost tracking.MIT
- AlicenseNot gradedqualityAmaintenanceEnables Claude Code to search and retrieve past chat history from Claude.ai exports and Claude Code sessions, allowing the AI to reference previous conversations and decisions.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/maqitong/hist-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server