This roadmap tracks planned capability expansions for the context engineering use case beyond the current Profile → Enrich → Compose → Generate → Publish → Discover → Observe architecture. The full lifecycle target adds: Govern, Cost Attribution, and Developer Experience.
Each proposed capability follows the same Naftiko v0.5 schema, directory structure, and triple-exposure pattern (HTTP, MCP, Agent Skill) as the existing capabilities.
| Area | Count | Capabilities |
|---|---|---|
| Profile | 5 | AI Readiness, Context Efficiency, MCP Inventory, MCP Duplicates, API Doc Quality |
| Enrich | 4 | AI Descriptions, Examples, Task Mapping, Context Annotations |
| Compose | 4 | MCP Tools, Server Boundaries, Context Schemas, Context Overlays |
| Generate | 3 | MCP from OpenAPI, MCP from Arazzo, MCP Sandbox |
| Publish | 4 | Backstage, GitHub Registry, Docker, Microcks |
| Discover | 3 | MCP Servers, Semantic Search, Recommendations |
| Observe | 4 | Usage Datadog, Usage New Relic, Context Cost, Context Quality |
MCP servers and AI integrations create new security, compliance, and policy surfaces that existing API governance doesn't cover. These capabilities bring governance into the context engineering loop — securing MCP in IDEs, managing auth flows, and enforcing policies at the MCP layer.
| Capability | What It Does |
|---|---|
govern-mcp-auth |
Manage OAuth and identity propagation for MCP servers — on-behalf-of (OBO) flows, token scoping, credential rotation |
govern-mcp-policy |
Apply runtime policies to MCP server usage — rate limits, allowed operations, data classification, team-level permissions |
govern-mcp-security-review |
Security assessment for MCP deployments — network calls, data exposure, attack surface analysis |
govern-mcp-ide-controls |
Govern MCP usage in developer IDEs — what's blessed, what's blocked, visibility into what's calling what |
govern-mcp-streaming-security |
Manage SSE/streaming MCP transport through enterprise proxies and firewalls |
MRD Problems Addressed:
- Problem 3: Need governed approach to 3rd-party services via MCP server
- Problem 4: Need to securely enable MCP in developer IDEs
- Problem 5: Need MCP streaming to work with enterprise security infrastructure
- Problem 6: Need MCP to integrate with existing API governance tooling
- Problem 8: Need to govern MCP servers not one-to-one with APIs
Design Partner Sources: Ford (auth flows, streaming/SSE challenges), Cvent (security review at scale), Goldman Sachs (access management), Chase (Spectral-based governance)
AI FinOps demands cost visibility at the capability level — not just model tokens, but upstream API costs driven by MCP tool calls. These capabilities connect context engineering to financial outcomes.
| Capability | What It Does |
|---|---|
track-cost-mcp-tokens |
Track and attribute token usage across MCP tool calls by team, domain, and capability |
track-cost-upstream-apis |
Attribute upstream API costs (3rd-party calls triggered by MCP tools) to capabilities and teams |
track-cost-context-waste |
Quantify cost of context window waste — oversized payloads, unused fields, redundant tool calls |
MRD Problems Addressed:
- Problem 7: Need AI FinOps — cost visibility and control across AI services
- Problem 24: Need to manage spend across all 3rd-party APIs — not just AI
Design Partner Sources: Ford (total cost of ownership visibility), Chase (cost attribution by domain)
Meeting developers where they work — in the IDE and copilot — is the most effective way to drive adoption of governed, well-composed MCP tools. These capabilities surface context engineering directly in developer workflows.
| Capability | What It Does |
|---|---|
surface-context-ide |
Expose available MCP tools as IDE and copilot suggestions when developers need API integrations |
surface-context-pr-check |
PR-level check that flags when new code creates a duplicate MCP server or uses raw API calls instead of an existing capability |
MRD Problems Addressed:
- Problem 2: Need to incentivize developers to reuse APIs when developing — in IDE and copilot
- Problem 19: Need discoverability, not just governance — the real barrier to reuse
Design Partner Sources: Cvent (copilot-embedded discovery), Chase (MCP servers from catalog for copilot), Microsoft (developer evangelism through MCP)
| Area | Built | Proposed | Total |
|---|---|---|---|
| Profile | 5 | 0 | 5 |
| Enrich | 4 | 0 | 4 |
| Compose | 4 | 0 | 4 |
| Generate | 3 | 0 | 3 |
| Publish | 4 | 0 | 4 |
| Discover | 3 | 0 | 3 |
| Observe | 4 | 0 | 4 |
| Govern | 0 | 5 | 5 |
| Cost | 0 | 3 | 3 |
| Developer Experience | 0 | 2 | 2 |
| Total | 27 | 10 | 37 |
┌─────────────────────────────────────────────────────────────────────┐
│ PROFILE (5) │
│ AI Readiness Context Efficiency MCP Inventory MCP Duplicates │
│ API Doc Quality │
└────────────────────────────────┬────────────────────────────────────┘
▼
Assessed API & MCP Landscape
│
┌──────────────────┼──────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ ENRICH (4) │ │ COMPOSE (4) │ │ GOVERN (5) │
│ AI Descriptions │ │ MCP Tools │ │ Auth │
│ Examples │ │ Server Bounds │ │ Policy │
│ Task Mapping │ │ Context Schemas │ │ Security Review │
│ Context Annot. │ │ Context Overlays │ │ IDE Controls │
│ │ │ │ │ Streaming │
└────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘
└────────────────────┼────────────────────┘
▼
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ GENERATE (3) │ │ PUBLISH (4) │ │ DISCOVER (3) │
│ MCP from OpenAPI │ │ Backstage │ │ MCP Servers │
│ MCP from Arazzo │ │ GitHub Registry │ │ Semantic Search │
│ MCP Sandbox │ │ Docker │ │ Recommendations │
│ │ │ Microcks │ │ │
└──────────────────┘ └──────────────────┘ └──────────────────┘
│
┌────────────────────┼────────────────────┐
▼ ▼ ▼
┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐
│ OBSERVE (4) │ │ COST (3) │ │ DX (2) │
│ Usage Datadog │ │ MCP Tokens │ │ IDE Surface │
│ Usage New Relic │ │ Upstream APIs │ │ PR Check │
│ Context Cost │ │ Context Waste │ │ │
│ Context Quality │ │ │ │ │
└──────────────────┘ └──────────────────┘ └──────────────────┘
New shared adapters still needed:
| Adapter | Service | Area |
|---|---|---|
consumes-spectral.yml |
Spectral/vacuum linting engine | Govern |
consumes-openai.yml |
OpenAI API for enrichment | Enrich (AI-powered) |
consumes-anthropic.yml |
Anthropic API for enrichment | Enrich (AI-powered) |
Already built in this project (shared/):
consumes-microcks.yml,consumes-docker.yml(new)
Existing adapters consumed from the capabilities and api-reusability repos:
consumes-github.yml(Profile, Publish)consumes-backstage.yml(Profile, Publish, Discover)consumes-datadog.yml,consumes-newrelic.yml(Observe)