DevsContext
Coming soon - integration with Confluence
Email threads related to tickets
Ticket details, comments, linked issues, acceptance criteria
Coming soon - integration with Linear
Coming soon - integration with Notion
Channel discussions, threads, decisions
Click on "Deploy 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., "@DevsContext get context for PROJ-123"
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.
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 demoNo 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 metricsOne synthesized block. Everything the AI needs to write correct code.
Quick Start
pip install devscontext
devscontext initSet your credentials:
export JIRA_EMAIL="you@company.com"
export JIRA_API_TOKEN="your-token"
export ANTHROPIC_API_KEY="your-key" # for synthesisConnect to Claude Code:
claude mcp add devscontext -- devscontext serveThen in Claude Code:
> work on PROJ-123Works With
IDE / Tool | Setup Guide | Status |
Claude Code | Tested | |
Cursor | Tested | |
Windsurf | Tested | |
Any MCP client |
| 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 statusConfigure 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
Fetch: When you mention a ticket, DevsContext fetches from all configured sources in parallel
Extract: It finds relevant content — ticket matches docs by component/label, searches meeting transcripts for keywords
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 |
| Starting work on a ticket | "work on PROJ-123" |
| Questions about architecture or past decisions | "how do we handle payment retries?" |
| 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 toolsdevscontext_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
Scored across 4 tools
Each tool has a clearly distinct purpose: health check, coding standards, ticket context, and general search. Descriptions are precise and non-overlapping.
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.
Four tools cover the essential functionalities of a development context assistant without excess or deficiency, well-scoped for the domain.
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
Related MCP Connectors
Context engineering for AI coding agents: product context, project missions, and 360 memory.
The context platform for AI agents: code search, team decisions, and grounded project context.
Team memory for AI coding agents and code reviews, reviewed by humans and served over MCP.
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
Related MCP Servers
- FlicenseNot gradedqualityNot gradedmaintenanceAn 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-
- AlicenseNot gradedqualityCmaintenanceAn 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 npm4MIT
- AlicenseBqualityBmaintenanceMCP server providing persistent engineering memory and spec-driven development workflows for AI coding agents, preserving learnings across sessions.41Business Source 1.1
- AlicenseNot gradedqualityDmaintenanceAn MCP server that gives AI coding agents structured access to a project's architecture, rules, modules, and technical decisions.MIT