Skip to content

Latest commit

 

History

History
168 lines (127 loc) · 9.46 KB

File metadata and controls

168 lines (127 loc) · 9.46 KB

Context Engineering Capability Roadmap

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.


Current State (27 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

1. Governance (New Area)

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)


2. Cost Attribution (New Area)

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)


3. Developer Experience (New Area)

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)


Capability Summary

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

Full Lifecycle Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                          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  │ │                  │ │                  │
└──────────────────┘ └──────────────────┘ └──────────────────┘

Shared Adapters Required

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)