a5sql-mcp: Skill for Codex

MCP Architecture Patterns

Use this skill to review MCP server design through the pattern vocabulary from Carson Rodrigues and Oysturn Vas, "MCP Server Architecture Patterns for LLM-Integrated Applications", arXiv:2606.30317v1.

Do not treat the taxonomy as a replacement for repo-specific constraints. If another skill defines domain boundaries, security rules, release gates, or non-goals, apply that skill first and use this skill as an architecture review lens.

Review Workflow

1. Identify the server's externally visible surface: tools, resources, prompts, transports, auth model, state, downstream systems, and generated outputs.
2. Classify the primary pattern from implementation signals, not from tool names alone. Statefulness and domain logic can be cross-cutting attributes rather than the primary pattern.
3. Check whether the chosen pattern matches the problem. Prefer the smallest pattern that preserves a clear LLM-facing contract.
4. Run the anti-pattern checks before recommending implementation.
5. Report concrete design actions: keep, split, rename, add metadata, add paging, add sanitization, add structured errors, add versioning, or defer as out of scope.

Pattern Guide

Resource Gateway

Use for read-mostly access to backend data: files, databases, document stores, or APIs. The MCP server mediates access and gives the LLM stable resources, IDs, summaries, bounded snippets, and parameterized read tools.

Review for:

• A single layer that enforces access boundaries, root scopes, masking, sanitization, and pagination.
• Stable LLM-facing schemas that do not expose backend format churn directly.
• Resource or query decomposition that keeps large data out of single responses.
• Explicit treatment of retrieved content as untrusted when it can contain user or external text.

Avoid treating Resource Gateway as permission to expose raw backend content. The gateway exists to shape, constrain, and label data before the LLM receives it.

Tool Orchestrator