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.
MCP server that gives AI coding agents synthesized engineering context — requirements, decisions, architecture, and standards — from your actual tools.
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
pip install devscontext
devscontext demoNo API keys needed. Shows synthesized context for a sample payments ticket.
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.
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-123IDE / Tool | Setup Guide | Status |
Claude Code | Tested | |
Cursor | Tested | |
Windsurf | Tested | |
Any MCP client |
| Compatible |
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
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.
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.
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
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.
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?" |
git clone https://github.com/Pro0f/devscontext.git
cd devscontext
pip install -e ".[dev]"
# Run tests
pytest
# Lint
ruff check . && mypy src/Contributions welcome! See CONTRIBUTING.md for guidelines.
Ideas for contributions:
New adapters (Linear, Notion, Confluence)
Better keyword extraction
Caching improvements
MIT
Check DevsContext configuration, source connectivity, and health status. Use this to verify your setup or debug connection issues.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool checks configuration, source connectivity, and health status, implying a read-only diagnostic operation. This is adequate for a simple status check.
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, each earning its place: first states action and resources, second provides usage guidance. No wasted words.
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 no parameters, no output schema, and simple purpose, the description is complete. It tells the agent what the tool does and when to use it.
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?
There are zero parameters, so baseline is 4. The description adds meaning by explaining what the tool checks (configuration, connectivity, health) beyond the empty schema.
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 verb 'Check' and the resources: configuration, source connectivity, health status. It distinguishes itself from siblings like get_standards, get_task_context, and search_context by focusing on diagnostics rather than retrieving specific data.
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 says to use it 'to verify your setup or debug connection issues.' This provides clear usage context. It does not mention when not to use it, but for a health check tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Filter by area: 'testing', 'typescript', 'error-handling', etc. Omit to get all standards. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It only states 'returns' data, implying read-only, but does not disclose any side effects, authentication needs, rate limits, or other behavioral traits beyond basic purpose.
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?
Description is well-structured with purpose first, then usage guidance. It is efficient but could be slightly more concise; however, every sentence adds value.
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?
For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, usage, and filtering. It explicitly states the return type (coding standards, etc.), which is sufficient.
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 100% and the description repeats the same filtering examples as the schema parameter description. No additional meaning added beyond what schema already provides.
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 returns coding standards, style guides, and best practices, and specifies the action ('checking conventions'). It distinguishes from sibling tools (devscontext_status, get_task_context, search_context) which cover different domains.
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?
Explicitly states when to use: before/during implementation, when user asks about conventions. Provides example queries. Does not include explicit when-not-to-use, but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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'.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | Jira ticket ID (e.g., 'PROJ-123', 'TICKET-456') | |
| refresh | No | Force refresh, bypassing cache |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the scope (fetching multiple content types) and hints at caching via 'refresh' parameter, but lacks details on expected latency, required permissions, error handling, or what happens if the ticket doesn't exist.
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: first sentence states purpose and what it provides, second sentence gives specific usage triggers. Every sentence adds value, no fluff, and front-loaded with key information.
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?
Lists the types of content it synthesizes (requirements, comments, docs, standards, etc.), which is useful but incomplete. There is no output schema, so the description should clarify the return format (e.g., structured summary vs. raw text) but does not. Also lacks details on error states or prerequisites.
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 100% with both parameters described. The description does not add extra parameter-level details beyond the schema (task_id format, refresh behavior). Baseline score of 3 is appropriate as the description provides no additional parameter semantics.
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 'fetches and synthesizes' and clearly identifies the resource (Jira ticket). It lists multiple content types (requirements, comments, transcripts, docs, etc.), distinguishing it from sibling tools like get_standards (only standards) or search_context (general search).
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?
Explicitly states when to use: 'when starting work on a Jira ticket' and provides concrete trigger phrases ('work on PROJ-123', 'start TICKET-456'). Advises to 'call this FIRST', giving strong context, though it does not explicitly list when not to use or directly contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language question or search terms |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must carry the full burden. It discloses search sources (Jira, transcripts, documentation) and confirms input is natural language. However, it does not mention response format, scope limitations, or any behavioral traits like read-only nature. Adequate but not comprehensive.
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?
Three sentences efficiently conveying purpose, examples, and input format. No fluff or redundancy. Front-loaded with the core purpose.
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 simple tool with one parameter and no output schema, description covers sources and usage examples adequately. Could mention what kind of results are returned, but not essential for selection decision.
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 description coverage is 100% (single query parameter with description 'Natural language question or search terms'). The description essentially repeats this as 'Input is a natural language question', adding no new meaning beyond the schema.
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?
Description clearly states it's for freeform questions about codebase, architecture, or past decisions, searching across Jira, transcripts, and documentation. Distinguishes from siblings like devscontext_status or get_standards by emphasizing freeform natural language queries.
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?
Explicitly provides example questions ('how do we handle errors?', etc.) indicating when to use. Does not explicitly list when not to use or alternatives, but the examples give clear context for appropriate use cases.
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.
v0.1.0devscontext_statusget_standardsget_task_contextsearch_contextScored 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.
Context engineering for AI coding agents: product context, project missions, and 360 memory.
One shared context your team's AI tools read & write over MCP. No re-explaining. Free.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
