The Skilled OpenAPI plugin turns an existing REST API into a skilled MCP server without rewriting any controllers. A signed skill bundle (an OpenAPI spec plus an OpenAPI Overlay annotated with skill grouping) is consumed at runtime by the plugin, projected into the FrontMCPDocumentation Index
Fetch the complete documentation index at: https://docs.agentfront.dev/llms.txt
Use this file to discover all available pages before exploring further.
SkillRegistry, and exposed through three meta-tools — search_skill, load_skill, execute_action. The per-operation tools stay hidden from tools/list so the LLM never sees a 150-endpoint dump.
Skills, not flat tools
The MCP client sees curated skills. Per-operation tools are hidden behind the skill abstraction.
Signed, hot-swappable bundles
OPA-style JWT-of-hashes signing on every bundle. Atomic apply with rollback. Skills update without a server restart.
Standards-aligned wire format
Bundle is an OpenAPI Overlay (OAI 1.0/1.1) carrying skill annotations. Anticipates SEP-2076 (Skills as MCP primitive).
Five-gate authorization stack
Bundle signature → RFC 8707 audience check → per-skill ABAC → credential allowlist → outbound SSRF + IP blocklist.
The problem this solves
Wrap your REST API with a flat OpenAPI→MCP generator and you hit a familiar wall:- The agent sees 47 (or 470) tool definitions and can’t pick the right one. Claude reliability degrades past ~20 tools; OpenAI GPT Actions caps at 30; Cursor caps at 40.
- Token cost explodes on every
tools/listeven when the agent uses two endpoints. - Credentials end up in tool input schemas — every MCP client sees them.
- Schema changes ship through a server redeploy, not your CI pipeline.
How it works
The MCP client only ever sees the three meta-tools plus whatever skills the active bundle declares. Per-operation tools are reachable only throughexecute_action, which evaluates the action’s requiredAuthorities against the caller’s authInfo before the executor builds the outbound request.
When to use this plugin (and when not to)
| Scenario | Use this plugin | Use the OpenAPI adapter instead |
|---|---|---|
| 5–20 hand-curated endpoints, MCP-native server | ✅ | |
| 50+ endpoints, multi-service, customer-facing | ✅ | |
| Schema changes ship through CI, not redeploys | ✅ | |
You need every operation visible in tools/list | ✅ | |
| You need ABAC per operation + signed-bundle origin trust | ✅ |
What ships in v1.2.0
- Three bundle sources: static (filesystem with optional
fs.watch), npm (dynamic import of a published bundle package), saas-pull (HTTPS GET against a configured endpoint with JWT, interval polling, last-good cache fallback). - OpenAPI Overlay + custom JSON wire formats, both validated by Zod and cross-referenced for service / authBinding / operationId integrity.
- Bundle signing via RS256 / Ed25519 JWT-of-hashes, modeled on OPA’s signed-bundle pattern.
- OpenAPI runtime executor that reuses
@frontmcp/adapters/openapi’sbuildRequest/parseResponse— not a re-implementation. - Layered SSRF defenses: scheme allowlist, host allowlist, post-DNS IPv4/IPv6 blocklist (RFC 1918, link-local incl. AWS/GCP/Azure metadata 169.254.169.254, loopback, ULA), cloud-metadata hostname blocklist.
- ABAC integration via
@frontmcp/auth’sAuthoritiesEngine(RBAC + ABAC + custom evaluators). notifications/skills/list_changedbroadcast on every bundle swap, withbundleVersionon every skill so polling clients can detect changes regardless of clientlist_changedsupport.
Next steps
Quick Start
Install, point the plugin at a fixture bundle, and call
execute_action end-to-end in 5 minutes.Bundle Format
The wire format the plugin consumes — services, authBindings, skills, operations, signature envelope.
Security
Bundle signing, RFC 8707, SSRF defenses, OWASP MCP Top 10 mapping.
API Reference
Exported types, classes, DI tokens.