AGENT CONTEXT / DOCS

Choose your agent, system, and model.

Understand MCP requirements, local models, shared connections, and what has been verified.

What makes an agent compatible?

Your coding agent or host needs an MCP client that can list and call tools over stdio or Streamable HTTP. The AI model can be local or cloud-hosted. A plain model endpoint does not automatically read or write Agent Context.

Client configuration presets are available for Cursor, VS Code/Copilot, Gemini CLI, and generic MCP clients, alongside the Claude Code and Codex setup commands. These are configuration examples; every third-party client UI has not been tested.

Operating systems and requirements

The npm release bundles the React dashboard and server libraries. Python and native dependency compilation are not required. The AI model’s RAM, GPU, and storage needs are separate from the context server’s requirements.

Using a local model

Use a local inference runtime such as Ollama or llama.cpp with a tool-capable model and an MCP-capable host. The host can be your coding-agent application or another runtime with an MCP integration.

1. Start your local model and select it in an agent or host that supports both that model endpoint and MCP tools.
2. Install Agent Context and configure its stdio command, or connect to your running HTTP instance.
3. Enable the MCP tools and use the same project ID as your other agents.
4. Ask the agent to call list_projects, record a test handoff, and read it back with get_context. Confirm the actual tool calls, not just a text description.

agent-context-mcp config --client generic --db /absolute/path/to/shared/context.sqlite3

Agent Context does not require a model API key. A fully local workflow is possible when the model and host both run locally and use local services. Hosted models and any external tools you enable keep their own network and account requirements.

Tool-use reliability depends on the model, its template, and the host’s tool execution. We have not benchmarked or validated every local model. Start with a small test project before relying on automatic handoffs.

Runtime references: Ollama tool calling and llama.cpp server documentation.

Sharing context across systems

Choose a team connection method: Wi-Fi/LAN, private VPN, SSH tunnel, or HTTPS.

• Same computer: use the same absolute SQLite database path in the dashboard and every stdio configuration.
• Different computers or cloud agents: connect to one persistent server using its reachable /mcp URL, Streamable HTTP, and a bearer token. Use HTTPS for remote access.
• Same project: use the same project ID and a different agent ID for each session. Agents must record their work so the next agent can read it.

Do not share SQLite by placing a live database on a network filesystem. Use one HTTP server to share access remotely. A cloud agent cannot reach your laptop’s localhost without a separately configured network connection.

What the public website provides

This website hosts the documentation and downloadable releases. It does not host your project database or act as your MCP endpoint. Run the installed server locally or on your own persistent infrastructure.

What is verified today?

Automated checks cover shared handoffs, MCP SDK communication, authentication, task claims, backups, and configuration output. Two subprocess tests are skipped in this restricted environment. Browser interactions, every named coding client, all operating systems, and local-model combinations still need direct verification.

Context is recorded work

The server does not automatically capture conversations or inspect your repository. Add the shared workflow to each agent’s instructions: read context before editing, claim a task, record meaningful changes and test results, and leave a handoff before stopping.