Skip to content

PATTERN Cited by 1 source

MCP tools + skills unified platform

Intent

Split the operational-AI platform into two layers — a shared MCP tool layer and a pluggable skills layer — so every new use case is a new skill, not a new pipeline (Source: sources/2026-04-16-meta-capacity-efficiency-at-meta-how-unified-ai-agents-optimize-performance-at-hyperscale).

Canonical instance

Meta Capacity Efficiency Platform (2026-04-16). Meta's framing: "The breakthrough was realizing that both problems share the same structure... We didn't need two separate AI systems. We needed one platform that could serve both."

Architecture:

  1. MCP Tools layer — standardized LLM-invocation interfaces for the operational data sources: profiling queries, experiment results, configuration history, code search, documentation.
  2. Skills layer — domain-expertise modules telling an LLM which tools to invoke and how to interpret results (e.g. "consult the top GraphQL endpoints for endpoint latency regressions"; "look for recent schema changes if the affected function handles serialization"; "regressions from logging can be mitigated by increasing sampling").
  3. Per-use-case agents — distinct skill bundles composed over the shared tool layer:
    • AI Regression Solver (defense)
    • Opportunity Resolver (offense)
    • Conversational efficiency assistants
    • Capacity-planning agents
    • Personalized opportunity recommendations
    • Guided investigation workflows
    • AI-assisted validation

Meta: "Each new capability requires few to no new data integrations since they can just compose existing tools with new skills."

When to reach for it

  • You have multiple downstream AI use cases that all need to read from a shared operational data fabric (profiling, logs, traces, code, config, experiments).
  • You expect the use case count to grow faster than the tool count — i.e. the expensive-to-build thing is the tool (data integration), the cheap thing is the skill (markdown + routing logic).
  • Your organisation has reusable senior-engineer reasoning patterns that currently live in people's heads + team wikis, and you want to apply them uniformly.
  • You already have — or are willing to build — MCP-compatible servers for your internal data sources.

Mechanism

Build the shared tool surface once

  • Inventory the data sources every performance-engineering task already uses.
  • Wrap each as an MCP tool with a minimal single-verb surface ("each tool does one thing").
  • Invest in tool breadth (coverage) more than tool depth (chained operations). Chaining lives in skills.

Decouple skills from tools

  • Skills reference tools by name, not by implementation detail.
  • When a tool's backend changes (e.g. profiling migrates from v1 to v2 indexing), the skill catalogue is unaffected.
  • Skills are markdown + routing, not fine-tuned weights or embeddings — preserves model-agnosticism (concepts/encoded-domain-expertise).

Compose agents per use case

  • An agent = system prompt + selected skill subset + agent-level configuration (e.g. PR-generation vs in-editor-suggestion).
  • Specialization happens at the agent / skill level, not the tool level (cf. patterns/specialized-agent-decomposition).
  • Two worked agent compositions on the Meta platform:
  • AI Regression Solver = FBDetect-ingest skills + mitigation skills + PR-author-routing skill.
  • Opportunity Resolver = opportunity-metadata skills + optimization-pattern skills + in-editor-render skill.

Pay the compounding dividend

  • Adding a new AI use case = writing a new skill-bundle agent.
  • Typical cost profile: tools are expensive to build, skills are cheap to write. Meta's observation: "few to no new data integrations" per new capability.

Why it works

  • Tool reuse amortizes data-integration cost. Profiling integration is built once; every agent benefits.
  • Skill authoring is a senior-engineer leverage mechanism. A senior engineer writes a skill; every agent applies it uniformly thereafter.
  • Model-agnostic investment compounds. When the underlying LLM is replaced, the skill catalogue + tool layer survive unchanged.
  • Specialization without silos. Agents specialize (see patterns/specialized-agent-decomposition) but don't fork their own data layer; cross-agent coherence is free.

Tradeoffs

  • Tool-granularity discipline. If tools are too coarse ("one endpoint that does everything") the skill layer has nothing to compose; if too fine ("one endpoint per SQL clause") the skill layer drowns in mechanics.
  • Skill-conflict resolution. Two skills matching the same trigger need a routing / prioritization rule; not described in Meta's post.
  • Skill lifecycle. Skills encode reasoning patterns that evolve; someone has to own skill deprecation + versioning. Meta does not detail this.
  • Cold-start. Bootstrapping takes nontrivial up-front work — the tool layer must already cover the data surface before skills pay off.
  • Observability across agents. Centralised data means centralised failure modes; one tool regression cascades to every downstream agent.

Relationship to sibling patterns

  • patterns/tool-decoupled-agent-framework — the infrastructure half of this pattern (framework, LLM client, conversation state, MCP transport). MCP-tools-plus-skills is the specific architectural shape a tool-decoupled framework takes when it serves an operational-AI use case.
  • patterns/specialized-agent-decomposition — the agent-composition half. Meta's platform adds a fifth framing to this pattern's taxonomy: skill-based decomposition over a shared tool surface (alongside Storex domain-based / Dash sub-tool / DS-STAR role-in-refinement-loop / Pre-Compute Engine offline-context-generation).
  • patterns/centralized-ahead-of-time-indexing (Meta Glean) — the precedent for the "centralize once, query from everywhere" bet, applied to code indexing rather than operational data.
  • patterns/precomputed-agent-context-files (Meta Pre-Compute Engine) — the offline-artifact cousin. Both bet on model-agnostic markdown encoding; this pattern is the runtime-invoked variant, that pattern is the offline-preloaded variant.

Seen in

Last updated · 319 distilled / 1,201 read