MCP Server Adapter Pattern
MCP-AQL is primarily designed to consolidate and expose MCP server operations through a consistent query contract with runtime introspection.
Public MCP server adapter examples are planned, but not yet published.
On this page
Jump to a section
Use the outline to move through longer pages without losing your place.
Related reading
Read the formal docs
Use these pages when you want the contract details behind this pattern instead of just the high-level guidance.
Explore more patterns
These related profiles show how the same protocol ideas shift across different target environments.
When this pattern fits
Best fit
- The upstream system already exposes MCP tools or tool-like operations.
- You want runtime discovery to remain central instead of freezing a large static tool surface.
- You need a clear path from interrogated MCP behavior into a spec-aligned adapter contract.
Watch for
- Operation naming or parameter drift between upstream descriptions and adapter output.
- Tools with unclear side effects that need better CREATE, UPDATE, DELETE, or EXECUTE classification.
- Discovery artifacts that can fall out of sync with the normative draft if generation is loose.
Recommended Baseline
Protocol Shape
- Expose
introspectas mandatory discovery entrypoint. - Route operations via CRUDE endpoints or single mode.
- Return discriminated union responses: success/data or success/error.
- Keep operation metadata and execution behavior aligned.
Safety & Runtime
- Validate unknown parameters explicitly.
- Apply structured error codes for machine readability.
- Bound batch sizes and execution resource usage.
- Optionally enforce policy modules (gatekeeper/danger-zone style).
Conceptual Example
{
"operation": "get_element",
"params": {
"element_name": "api-architecture-expert"
}
}
The operation name and parameters are adapter-defined; clients should discover valid operations via introspect before execution. This page is guidance, not a published adapter implementation.