Skip to main content

Context broker MCP server — retrieves rules, reasoning, skills, and commands from company resources (markdown, GitHub, Confluence, Notion, Jira, Linear, Slack) via repo-owned topic configuration.

Project description

keystone-mcp

An MCP server that retrieves contextual information from company resources and surfaces it to coding agents as rules, reasoning, skills, and commands.

The agent treats each kind differently:

  • rules — constraints to obey (must / should / may)
  • reasoning — background facts and intent
  • skills — procedural how-to knowledge (multi-step playbooks)
  • commands — canned invocations (shell commands, scripts, named recipes)

Instead of cramming organizational context into every system prompt, the agent reads context://{topic} resources or calls get_context(topic) and the broker fans the request out to the right backing source.

Status

Phases 1–12 shipped. Seven external adapters plus a harness adapter, shared classifier, multi-source merge with conflict resolution, persistent sqlite cache, FastMCP-conforming surface (resources for read-only data, tools for parameterized reads and writes), and a harness scaffold tool surface. 217 tests pass.

See PLAN.md for the full design and remaining open work.

Adapters

Adapter Auth What it emits
markdown none (repo-local) rules / reasoning / skills / commands
github PAT CODEOWNERS, branch protection (rules); PRs, releases (reasoning)
confluence email + API token page content (all four kinds)
notion integration token page content (all four kinds), database rows (reasoning)
jira email + API token issues, JQL search (reasoning)
linear personal API key issues, GraphQL filter (reasoning)
slack bot OAuth token pinned messages (rules), recent discussion (reasoning)

Install

Until the package is published (Phase 11), clone and run from source:

git clone tacoda_github:tacoda/keystone-mcp.git
cd keystone-mcp
uv sync

Run the server:

uv run python -m keystone_mcp.server

Or wire it into a Claude Code project as an MCP server. Add to .mcp.json:

{
  "mcpServers": {
    "keystone": {
      "command": "uv",
      "args": [
        "--directory", "/path/to/keystone-mcp",
        "run", "python", "-m", "keystone_mcp.server"
      ],
      "env": {
        "KEYSTONE_CONFIG": "/path/to/your/project/.keystone/context.yaml"
      }
    }
  }
}

The config path defaults to .keystone/context.yaml relative to the working directory; override with KEYSTONE_CONFIG.

Quickstart

  1. Create .keystone/context.yaml in your project:

    sources:
      docs:
        type: markdown
        root: .keystone/context/
    
    topics:
      deploy-policy:
        description: |
          Rules and context for production deploys.
        sources:
          - source: docs
            query: { file: deploy-policy.md }
            classify:
              rules: { heading: "Rules", severity: must }
              reasoning: { heading: "Background" }
        cache: 15m
    
  2. Create .keystone/context/deploy-policy.md:

    # Deploy Policy
    
    ## Rules
    
    - MUST run full CI green before any production deploy.
    - SHOULD prefer Tuesday/Wednesday morning deploys.
    
    ## Background
    
    The team adopted these rules after a 2025 incident.
    
  3. Start the server. The agent now sees deploy-policy in list_topics and can read context://deploy-policy to load the envelope.

The repo's own .keystone/context.yaml is a working example with topics for deploys, ownership, coding standards, and a release playbook (plus commented-out examples of every external adapter).

MCP surface

Tools

Tool Returns
get_context(topic) full envelope (rules + reasoning + skills + commands)
list_topics(tag?) directory of configured topics
harness_bootstrap() scaffold the harness skeleton at .keystone/harness/
harness_new_guide(name, tier?) scaffold a new guide
harness_new_sensor(name, kind?, mode?) scaffold a sensor + matching script (computational) or prompt (inferential)
harness_new_script(name, body?) scaffold a sensor script (or ad-hoc shell script)
harness_new_prompt(name, body?) scaffold a sensor prompt (or ad-hoc prompt for inferential checks)
harness_new_skill(name, description?) scaffold skills/<name>/SKILL.md (FastMCP-native)
harness_new_adapter(agent) scaffold a per-agent adapter dir
harness_target_add(agent, project_root?) install agent menu file at project root

Prompts

Lifecycle workflows that seed multi-step agent conversations. The agent invokes a prompt, walks the phases, and calls scaffold tools along the way.

Prompt Purpose
bootstrap() one-time codebase analysis → fill state ledgers under corpus/state/
task(description) end-to-end work: spec → orient → implement → verify → review
audit() dual-flywheel: learning (capture) + pruning (retire stale)
learn(finding) capture a finding into learning/inbox/ for batched promotion

All harness paths are fixed under .keystone/harness/ — the .keystone/ directory is team-shared and version-controlled. Never put secrets there. Reference them via env:VAR in .keystone/context.yaml instead. Scaffold tools refuse to write files whose names look like secrets (secret, token, credential, password, api_key, private, envfile, …).

Resources

URI Purpose
context://list configured topic directory
context://{topic} full envelope for one topic
source://{name}/health adapter reachability + auth state
harness://status harness layout audit (root=harness)
harness://{root}/status harness layout audit at a custom root
harness://options valid scaffold-tool arguments

Envelope shape

Every retrieval returns the same envelope. Example:

{
  "topic": "deploy-policy",
  "rules": [
    {
      "id": "rules-001",
      "text": "run full CI green before any production deploy.",
      "source": "markdown://deploy-policy.md#rules",
      "severity": "must"
    }
  ],
  "reasoning": [
    {
      "text": "The team adopted these rules after a 2025 incident.",
      "source": "markdown://deploy-policy.md#background"
    }
  ],
  "skills": [],
  "commands": [],
  "fetched_at": "2026-06-10T14:32:00+00:00",
  "cache_hit": false
}

Configuration

Topics

Topics are the agent-facing abstraction. Each topic binds one or more adapter calls and declares how their output classifies into the four kinds:

topics:
  repo-policy:
    description: Combined ownership and branch-protection rules.
    sources:
      - source: docs
        query: { file: owners.md }
        classify:
          rules: { heading: "Required reviewers" }
      - source: gh
        query: { type: codeowners }
      - source: gh
        query: { type: branch_protection, branch: main }
    cache: 5m

Single-source topics can use the shorthand:

topics:
  rollback:
    description: Rollback procedure.
    source: docs
    query: { file: rollback.md }
    classify:
      rules: { heading: "Rules" }

Multi-source merge

When two sources contribute rules whose normalized text matches:

  • Highest severity wins (must > should > may).
  • Ties at the top severity keep both rules so each source stays cited.

Reasoning, skills, and commands stay additive — no deduplication.

Classify selectors

markdown, confluence, and notion share the same heading-based vocabulary. Sections split by H2; skills/commands sub-split by H3.

classify:
  rules:
    heading: "Rules"             # single or list, e.g. ["Rules", "Must"]
    severity: must               # default for bullets without MUST/SHOULD/MAY prefix
  reasoning:
    heading: "Background"
    # or
    all: true                    # everything not matched by another kind
  skills:
    heading: "Procedures"        # each H3 → one skill (name + body)
  commands:
    heading: "Commands"          # each H3 → one command (first code block = invocation)

For github, jira, linear, slack the query type determines the kind (e.g. codeowners → rules, recent_prs → reasoning).

Secrets

Reference environment variables with the env: prefix:

sources:
  gh:
    type: github
    repo: acme/widgets
    auth: env:GITHUB_TOKEN

The loader fails fast at startup if a referenced env var is unset.

Cache

Default is in-memory (lost on restart). Persistent sqlite cache survives process restarts:

cache:
  backend: sqlite
  path: .keystone/cache.db

Per-topic TTLs use 5s / 10m / 2h / 1d syntax.

Development

uv sync                     # install deps
uv run pytest -q            # run tests
uv run python -m keystone_mcp.server   # run server

The test suite uses respx to mock all external APIs — no live credentials required.

License

TBD.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

keystone_mcp-0.1.0.tar.gz (60.7 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

keystone_mcp-0.1.0-py3-none-any.whl (56.2 kB view details)

Uploaded Python 3

File details

Details for the file keystone_mcp-0.1.0.tar.gz.

File metadata

  • Download URL: keystone_mcp-0.1.0.tar.gz
  • Upload date:
  • Size: 60.7 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.11.8 {"installer":{"name":"uv","version":"0.11.8","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"macOS","version":null,"id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}

File hashes

Hashes for keystone_mcp-0.1.0.tar.gz
Algorithm Hash digest
SHA256 81ba1b98cc7f07e57ad4b492dab02b5735bb5bcfd67fdebf7d7daeeedc9e2c90
MD5 ab0c5f077f7a6028fb4c30dcfea851cb
BLAKE2b-256 121e15c0114e5844325fffcfdea554044e837980c9f0a2cab768e336018024a4

See more details on using hashes here.

File details

Details for the file keystone_mcp-0.1.0-py3-none-any.whl.

File metadata

  • Download URL: keystone_mcp-0.1.0-py3-none-any.whl
  • Upload date:
  • Size: 56.2 kB
  • Tags: Python 3
  • Uploaded using Trusted Publishing? No
  • Uploaded via: uv/0.11.8 {"installer":{"name":"uv","version":"0.11.8","subcommand":["publish"]},"python":null,"implementation":{"name":null,"version":null},"distro":{"name":"macOS","version":null,"id":null,"libc":null},"system":{"name":null,"release":null},"cpu":null,"openssl_version":null,"setuptools_version":null,"rustc_version":null,"ci":null}

File hashes

Hashes for keystone_mcp-0.1.0-py3-none-any.whl
Algorithm Hash digest
SHA256 3a3530205ea4c2b72c371788fa8aed2edb85f0478b878fb01d67b264f7f3837a
MD5 95f7d31f7fac00f266bead21d494485c
BLAKE2b-256 2091bcb5916800a67eebf1b0494ac58d07780d922fc7b3c30eae52d550b6de35

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page