Skip to main content
Glama

DevsContext

MCP server that gives AI coding agents synthesized engineering context — requirements, decisions, architecture, and standards — from your actual tools.

The Problem

AI coding agents lack context. They don't know your team's decisions, architecture patterns, or coding standards. Connecting raw MCP servers floods them with irrelevant data they can't prioritize. Large companies build internal context infrastructure. DevsContext brings that to everyone.

Related MCP server: projscan

Try It Now

pip install devscontext
devscontext demo

No API keys needed. Shows synthesized context for a sample payments ticket.

What You Get

When you say "work on PROJ-123" in Claude Code, DevsContext fetches from Jira, meeting transcripts, and your docs, then synthesizes it into this:

## Task: PROJ-123 — Add retry logic to payment webhook handler

### Requirements
1. Implement exponential backoff for failed webhook deliveries
2. Max 5 retry attempts over 24 hours
3. Dead-letter queue for permanently failed webhooks
4. Metrics for retry success/failure rates

Acceptance criteria: [Jira PROJ-123]
- [ ] Webhooks retry with exponential backoff (1min, 5min, 30min, 2hr, 12hr)
- [ ] Failed webhooks move to DLQ after 5 attempts
- [ ] Dashboard shows retry metrics

### Key Decisions
- **Use SQS with visibility timeout** for retry scheduling, not cron jobs.
  Decided by @sarah in March 15 sprint planning. Rationale: SQS handles
  timing natively, reduces operational overhead. [Meeting: Sprint 23 Planning]

- **Exponential backoff schedule**: 1min → 5min → 30min → 2hr → 12hr.
  Based on payment processor rate limits. [Comment by @mike, Mar 16]

### Architecture Context
Webhook flow: `PaymentController` → `WebhookService.dispatch()` → SQS queue
→ `WebhookWorker.process()` → external endpoint.

Add retry logic in `WebhookWorker.process()` at:
`src/workers/webhook_worker.ts:45-80`

DLQ table schema in `migrations/004_webhook_dlq.sql`. [Architecture: payments-service.md]

### Coding Standards
- Use `Result<T, WebhookError>` pattern, don't throw exceptions
- Retry delays: use `calculateBackoff(attempt)` helper from `src/utils/retry.ts`
- Tests: mock SQS with `@aws-sdk/client-sqs-mock`, see `tests/workers/` for examples
[Standards: typescript.md, testing.md]

### Related Work
- PROJ-456: "Payment webhook initial implementation" (Done) — base implementation
- PROJ-789: "Add webhook monitoring dashboard" (In Progress) — will consume the metrics

One synthesized block. Everything the AI needs to write correct code.

Quick Start

pip install devscontext
devscontext init

Set your credentials:

export JIRA_EMAIL="you@company.com"
export JIRA_API_TOKEN="your-token"
export ANTHROPIC_API_KEY="your-key"  # for synthesis

Connect to Claude Code:

claude mcp add devscontext -- devscontext serve

Then in Claude Code:

> work on PROJ-123

Works With

IDE / Tool

Setup Guide

Status

Claude Code

Quick Start

Tested

Cursor

Setup Guide

Tested

Windsurf

Setup Guide

Tested

Any MCP client

devscontext serve via stdio

Compatible

Supported Sources

Source

What's Fetched

Status

Jira

Ticket details, comments, linked issues, acceptance criteria

Stable

Fireflies

Meeting transcripts, decisions, action items

Stable

Local Docs

Architecture docs, coding standards, ADRs

Stable

Slack

Channel discussions, threads, decisions

New

Gmail

Email threads related to tickets

New

Coming soon: Linear, Notion, Confluence

Pre-processing Agent

Build context proactively before developers pick up tickets:

# Start the agent (polls Jira for ready tickets)
devscontext agent start

# Single run for CI/cron
devscontext agent run-once

# Check pre-built context status
devscontext agent status

Configure in .devscontext.yaml:

agents:
  preprocessor:
    enabled: true
    jira_status: "Ready for Development"
    jira_project: "PROJ"

See docs/pre-processing.md for the full guide.

Plugin System

DevsContext uses a plugin architecture for adapters and synthesis:

  • Adapters: Fetch context from sources (Jira, Slack, docs, etc.)

  • Synthesis Plugins: Combine context (LLM, template, passthrough)

See docs/plugins.md for creating custom plugins.

Configuration

DevsContext uses .devscontext.yaml in your project root:

sources:
  jira:
    enabled: true
    base_url: "https://your-company.atlassian.net"
    email: "${JIRA_EMAIL}"
    api_token: "${JIRA_API_TOKEN}"

  docs:
    enabled: true
    paths:
      - "./docs"
      - "./CLAUDE.md"

  slack:
    enabled: true
    bot_token: "${SLACK_BOT_TOKEN}"
    channels: ["engineering", "payments-team"]

synthesis:
  provider: "anthropic"
  model: "claude-haiku-4-5"

Full configuration reference: docs/configuration.md

How It Works

  1. Fetch: When you mention a ticket, DevsContext fetches from all configured sources in parallel

  2. Extract: It finds relevant content — ticket matches docs by component/label, searches meeting transcripts for keywords

  3. Synthesize: An LLM combines raw data into a structured context block with sources cited

No background processes. No vector database. Just on-demand fetching and synthesis.

MCP Tools

Tool

When to Use

Example

get_task_context

Starting work on a ticket

"work on PROJ-123"

search_context

Questions about architecture or past decisions

"how do we handle payment retries?"

get_standards

Checking coding conventions

"what are our testing standards?"

Development

git clone https://github.com/Pro0f/devscontext.git
cd devscontext
pip install -e ".[dev]"

# Run tests
pytest

# Lint
ruff check . && mypy src/

Contributing

Contributions welcome! See CONTRIBUTING.md for guidelines.

Ideas for contributions:

  • New adapters (Linear, Notion, Confluence)

  • Better keyword extraction

  • Caching improvements

License

MIT

Available Tools

4 tools
devscontext_statusA

Check DevsContext configuration, source connectivity, and health status. Use this to verify your setup or debug connection issues.

Inputs: no named parameters.

get_standardsA

Use this when checking coding conventions before or during implementation. Returns coding standards, style guides, and best practices from local docs. Filter by area: 'testing', 'error-handling', 'typescript', 'api', etc. Use when the user asks 'what are our testing conventions?' or 'how should I handle errors?' or before writing significant code.

Inputs: area.

get_task_contextA

Use this when starting work on a Jira ticket. Fetches and synthesizes everything you need: ticket requirements, acceptance criteria, discussion comments, related meeting transcripts, architecture docs, ADRs, and applicable coding standards. Call this FIRST when the user says 'work on PROJ-123' or 'start TICKET-456'.

Inputs: task_id (required), refresh.

search_contextA

Use this for freeform questions about the codebase, architecture, or past decisions. Searches across Jira tickets, meeting transcripts, and documentation. Use when the user asks questions like 'how do we handle errors?', 'what was decided about webhooks?', or 'why did we choose SQS?'. Input is a natural language question.

Inputs: query (required).

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.2/5.0

    Scored across 4 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose: health check, coding standards, ticket context, and general search. Descriptions are precise and non-overlapping.

    Naming Consistency4/5

    Most tools follow a verb_noun pattern (get_standards, get_task_context, search_context), but devscontext_status deviates with a server prefix and no verb, causing minor inconsistency.

    Tool Count5/5

    Four tools cover the essential functionalities of a development context assistant without excess or deficiency, well-scoped for the domain.

    Completeness5/5

    The tool surface covers status checking, coding standards, Jira ticket context, and freeform search across multiple sources, leaving no obvious gaps for its intended use.

    Maintenance

    ActivityInactive
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • F
      license
      Not graded
      quality
      Not graded
      maintenance
      An MCP server that provides persistent project context, workflow management, and knowledge capture for AI coding agents. It enables agents to maintain structured memory across sessions by tracking project profiles, conventions, skills, and technical debt.
      7
      -
    • A
      license
      Not graded
      quality
      C
      maintenance
      An MCP server that provides AI coding agents with AST-accurate, context-budget-aware codebase querying, safety gates, and team policy integration via structured tools and a local plugin layer.
      112 npm
      4
      MIT
    • A
      license
      B
      quality
      B
      maintenance
      MCP server providing persistent engineering memory and spec-driven development workflows for AI coding agents, preserving learnings across sessions.
      41
      Business Source 1.1