The Agent Context Hub is a shared, versioned context server enabling AI agents to manage operational context in a private GitHub repository. It provides tools to discover, load, query, and update project state, with concurrency controls and permission enforcement across multiple agents and devices.
Discover routes and projects (context_routes): List available project IDs, aliases, and route names.
Bootstrap task context (context_bootstrap): Load minimal, versioned personal/project context and get a workspace revision.
Query context (context_query): Search within scopes and retrieve traceable source excerpts.
Write closeouts (context_closeout): Synchronize evidence-backed summaries, status, and next actions to allowed files, with revision checks.
Review candidates (context_review_candidate): Accept, reject, or supersede unverified observations for formal updates.
Maintain a single source of truth with version control and shared access.
Enforce read/write permissions based on route policies.
Manage lightweight metadata for external resources.
Support secure multi-agent access with individual, revocable tokens.
Provides tools for managing a shared, versioned context workspace in a private GitHub repository, including discovering context routes, bootstrapping task context, querying workspace scopes, and writing evidence-backed closeouts to approved files via Git commits.
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., "@Agent Context Hub Bootstrap context for the mobile app project"
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.
Agent Context Hub is a reusable MCP server for shared, versioned context across AI agents and devices. It is not tied to OpenClaw: Codex, Claude Code, Hermes, Cursor, OpenClaw, and any client that supports Streamable HTTP MCP can connect to the same workspace.
Not a personal workbench. Agent Context Hub is not a dashboard, task manager, chat UI, or a new agent. It is shared-context infrastructure: the private Workspace is the data and facts layer; Agent Context Hub is the access, synchronization, permission, and revision layer.
It keeps human-readable Markdown and YAML in a private GitHub workspace repository and exposes a small MCP interface. This public repository contains only server code, tests, documentation, and generic examples.
Different agents and devices read the same current profile, rules, skills, and project state.
GitHub main stays the source of truth instead of chat history or opaque agent memory.
Each device has its own token and can be revoked independently.
Task closeouts write only allowed project-state files and reject stale concurrent updates.
Related MCP server: Graph
If this is your first real installation and use of Agent Context Hub, do not treat templates/agent-context-workspace as your real Workspace and do not put personal data in the public repository. That directory is only a public starter template / local smoke-test dataset.
If you are using Codex, Claude Code, Hermes, OpenClaw, or another execution-capable Agent, the simplest entry point is to give it this repository and say:
Help me install and use this project for the first time:
https://github.com/zyplong/agent-context-hubThe Agent should interpret this as a real first-time setup, read prompts/00-master-setup-wizard.md, and then proceed phase by phase: environment check → private Workspace → profile prefill → onboarding → Hub → private networking → Device Token → client configuration → MCP registration → first read-only test → cross-Agent synchronization test.
If a local checkout of this repository already exists, the Agent should verify and reuse it instead of cloning another copy. Real personal data belongs only in your own private Workspace repository.
For manual setup, continue with Quick start.
Agent Context Hub manages shared operational context, not a general-purpose RAG knowledge base. It may keep lightweight metadata about important external resources so a new agent knows what exists, why it matters, where it lives, and whether the current client can access it.
The bundled workspace template includes resources/RESOURCE_REGISTRY.yaml for this purpose. Store references and concise summaries there, not full PDFs, document chunks, embeddings, datasets, credentials, or signed download URLs.
When a required resource is unavailable, the agent should report that the current context is insufficient and ask the user to upload the resource, grant access to its existing location, or use an external retrieval/RAG system that owns it.
See Resource boundary | 资源边界（中文）.
Tool | Purpose |
| Discover projects, aliases, and routes. |
| Load minimal task context and return a workspace revision. |
| Search selected workspace scopes with source paths. |
| Write an evidence-backed closeout to approved files. |
| Accept, reject, or supersede one pending candidate without auto-promoting it to formal state. |
The server is protocol-compatible with Streamable HTTP MCP clients. Protocol compatibility does not automatically mean that every client has completed live integration testing.
Client | Status |
OpenClaw | Configuration documented; live validation should still be recorded per release. |
Codex | Protocol compatible; live integration validation pending unless documented in the validation report. |
Hermes | Protocol compatible; live integration validation pending unless documented in the validation report. |
Claude Code | Protocol compatible; live integration validation pending unless documented in the validation report. |
Use the real multi-device validation guide before describing a client or device path as live validated.
The following path only verifies the code, dependencies, and local stdio MCP reads. It is not the real first-time setup flow, and you should not put personal data into the example Workspace.
git clone https://github.com/YOUR_ACCOUNT/agent-context-hub.git
cd agent-context-hub
npm install
npm test
export PERSONAL_CONTEXT_WORKSPACE="$PWD/templates/agent-context-workspace"
npm run devThis connects the stdio MCP server to the public example Workspace for demo / smoke testing. Passing this test does not mean that a private Workspace, remote Hub, cross-device path, or cross-Agent synchronization has been deployed.
For real use, return to “First real setup” above or read Quick start | 快速开始（中文）.
Use templates/agent-context-workspace as the starter for a new private GitHub repository. Replace the sample profile, rules, projects, route map, and resource registry with your own information.
Never publish that workspace. Do not put tokens, private keys, passwords, personal documents, or chat transcripts in it.
context-map.yaml is the important control file. It declares exactly which files a route can read and which project files a closeout may write.
common:
always_read:
- profile/RESPONSE_PREFERENCES.md
- rules/EVIDENCE_POLICY.md
- resources/RESOURCE_REGISTRY.yaml
routes:
sample_project_code:
project_id: sample-project
aliases: [sample-project, Sample Project]
task_aliases: [code, fix, review]
read:
- projects/sample-project/CURRENT_STATE.yaml
- projects/sample-project/NEXT_ACTIONS.md
write:
- projects/sample-project/CURRENT_STATE.yaml
- projects/sample-project/NEXT_ACTIONS.mdFor cross-device use, run the HTTP server on one trusted machine or server and connect clients through HTTPS.
The server reads GitHub through a GitHub App installed only on the private workspace repository. The app needs Contents: Read and write only if you enable context_closeout.
cp .env.example .env
# Fill in your own GitHub App and device-token values. Never commit .env.
npm run build
npm run http:startThe agent calls context_routes if it does not know the available routes.
The agent calls context_bootstrap before work and saves workspaceRevision.
The agent checks whether the returned context is sufficient for the task. If a required external resource is missing or inaccessible, it asks for that resource instead of inventing content.
The agent performs the task.
On completion, pause, or block, it calls context_closeout with that revision, a factual summary, evidence, and next actions.
The server checks the allowlist and concurrency, writes a Git commit, then returns the revision and commit URL.
Unverified observations can be stored as candidates. context_review_candidate may mark them accepted, rejected, or superseded.
Accepted does not mean formal state was updated. An accepted candidate only becomes eligible for a later evidence-backed formal update through a fresh bootstrap and closeout.
Agents should not upload full conversations or source documents into the Hub. Only concise, evidence-backed project state and lightweight resource metadata belong in the workspace.
npm test
npm run typecheck
npm run buildLoad current personal context for a task. Omit project_hint to read common identity and rules only; use route_hint when a project has multiple task-specific routes.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| max_chars | No | ||
| route_hint | No | ||
| project_hint | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and idempotent behavior, so the description doesn't need safety disclosure. It adds valuable behavioral nuance about how output scope changes based on project_hint and route_hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary action, and no unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read-only tool with strong annotations and a small parameter set, the description covers essential usage logic. It could mention return format or when to prefer context_query, but it is adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description explains the semantics of project_hint and route_hint, which is helpful. However, max_chars and task are not addressed, though task is self-explanatory and max_chars has schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads current personal context for a task with a specific verb and resource. It references project and route hints, which hints at differentiation, but doesn't explicitly compare to sibling tools like context_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear conditional guidance: omit project_hint for common identity and rules, use route_hint for multiple task-specific routes. It doesn't explicitly name alternatives or exclusion criteria, but the usage context is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compress a completed, paused, or blocked task into evidence-backed project state and synchronize only files explicitly allowed by the route write policy.
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | ||
| summary | Yes | ||
| evidence | Yes | ||
| route_hint | No | ||
| next_actions | Yes | ||
| project_hint | Yes | ||
| base_revision | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context beyond the annotations by noting that synchronization is limited to files allowed by the route write policy, which is useful for safety. However, with all annotations false, it doesn't disclose whether the operation is reversible, what happens to existing state, or failure conditions, leaving significant gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense sentence that front-loads the primary action and key constraint. Every phrase earns its place, with no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters, no output schema, and sparse annotations, yet the description provides only minimal guidance on how to invoke it. It lacks explanations of parameter values, return behavior, or edge cases, making it insufficiently complete for such a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only hints at the purpose of `evidence` ('evidence-backed') and `route_hint` ('route write policy'). The core parameters (project_hint, base_revision, summary, status, next_actions) are left undefined, leaving the agent to guess their exact meaning and format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('compress' a task into evidence-backed project state) and a resource (completed/paused/blocked tasks), which clearly distinguishes it from sibling tools like query or bootstrap. However, it doesn't explicitly name alternatives or elaborate on what 'compress' entails, leaving some ambiguity about its exact scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by specifying task statuses ('completed, paused, or blocked') and mentioning the route write policy, but it gives no explicit guidance on when not to use it or which sibling tool to prefer. The context is clear but lacks exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the current personal context within explicit scopes and return traceable source excerpts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| scopes | No | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as read-only, idempotent, non-destructive, and closed-world. The description adds valuable behavioral context by mentioning 'explicit scopes' and 'traceable source excerpts', which describe scoping behavior and result traceability. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action ('Search') and follows with the target and output. Every word contributes to the tool's purpose without wasted phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only minimal parameter descriptions, the description provides a high-level view of the tool but lacks detailed behavioral information such as result format, handling of missing scopes, or the effect of max_chars. For a moderately complex tool with 3 parameters and no schema descriptions, this is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its 3 parameters, so the description must compensate. It only adds meaning for the 'scopes' parameter via 'within explicit scopes', but leaves 'query' and 'max_chars' unexplored. The search term behavior and character limit are not mentioned, making the description insufficient for parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Search' with a precise resource 'current personal context within explicit scopes' and specifies output 'traceable source excerpts'. This clearly distinguishes it from sibling tools like context_bootstrap, context_closeout, and context_routes, which imply different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it searches personal context, but it does not explicitly specify when to use this tool over alternatives or mention any exclusions. For example, it doesn't say 'use context_routes for route planning' or 'use this when scoping is needed'. Thus usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List canonical project IDs, exact aliases, task aliases, and route names before choosing project_hint or route_hint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the description only needs to add meaningful context. It does so by specifying exactly what the tool lists (canonical project IDs, aliases, task aliases, route names), which is behaviorally useful for an agent. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that wastes no words. It conveys the action, the output contents, and the intended usage context in a compact, readable form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema) and the strong annotations, the description is complete enough. It explains what will be returned and when to call the tool, which is all an agent needs to invoke it correctly alongside sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema is empty and the description cannot meaningfully elaborate on parameter semantics. The baseline for no-parameter tools is 4, and the description sufficiently clarifies that this is a simple list/discovery operation with no input requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource: canonical project IDs, exact aliases, task aliases, and route names. It also frames the tool as a prerequisite step ('before choosing project_hint or route_hint'), which distinguishes it from sibling tools like context_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('before choosing project_hint or route_hint'), giving clear contextual timing. It does not, however, mention when not to use it or name alternative tools, so it stops short of the full 'when-not/alternatives' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0context_bootstrapcontext_closeoutcontext_querycontext_routesEach tool targets a distinct phase of context management: bootstrap loads, closeout writes/compresses, routes lists available routes, and query searches. There is no functional overlap or ambiguity about which tool to use.
All tools share the 'context_' prefix, with a brief term following. However, 'routes' is a noun while the others are verbs, creating a slight mismatch, yet the pattern remains predictable and readable.
Four tools is a well-scoped set for a context management server. Each tool earns its place and covers a core operation without unnecessary additions.
The tools cover the full lifecycle: discovering available routes, bootstrapping context, querying during a task, and closing out with state compression. No obvious gaps or dead ends exist for the server's purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A MCP server built for developers enabling Git based project management with project and personal…
An MCP server that gives your AI access to the source code and docs of all public github repos
Hosted MCP server for live public-data APIs and Skills for AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/zyplong/agent-context-hub'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
