agentleFS
taurgistaurgis/sfcc-dev-mcp/.github/skills/mcp-development/SKILL.md

mcp-development

Skill27 starsChanged 10 months agoMITView on GitHub

Mandatory preflight for MCP server design/review/audit tasks. Defines production best practices for architecting, securing, testing, and operating TypeScript MCP servers, including transport design, schema validation, error handling, and deployment.

17 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use cashier-stripe-development, passport-development and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • whisper-moneySkill

    cashier-stripe-development

    Handles Laravel Cashier Stripe integration including subscriptions, webhooks, Stripe Checkout, invoices, charges, refunds, trials, coupons, metered billing, and payment failure handling. Triggered when a user mentions Cashier, Billable, IncompletePayment, stripe_id, newSubscription, Stripe subscriptions, or billing. Also applies when setting up webhooks, handling SCA/3DS payment failures, testing with Stripe test cards, or troubleshooting incomplete subscriptions, CSRF webhook errors, or migration publish issues.

    Also in 5 projects that use this

  • datashamanSkill

    passport-development

    Develops OAuth2 API authentication with Laravel Passport. Activates when installing or configuring Passport; setting up OAuth2 grants (authorization code, client credentials, personal access tokens, device authorization); managing OAuth clients; protecting API routes with token authentication; defining or checking token scopes; configuring SPA cookie authentication; handling token lifetimes and refresh tokens; or when the user mentions Passport, OAuth2, API tokens, bearer tokens, or API authentication. Make sure to use this skill whenever the user works with OAuth2, API tokens, or third-party API access, even if they don't explicitly mention Passport.

    Also in 6 projects that use this

  • gdarkoSkill

    fortify-development

    ACTIVATE when the user works on authentication in Laravel. This includes login, registration, password reset, email verification, two-factor authentication (2FA/TOTP/QR codes/recovery codes), profile updates, password confirmation, or any auth-related routes and controllers. Activate when the user mentions Fortify, auth, authentication, login, register, signup, forgot password, verify email, 2FA, or references app/Actions/Fortify/, CreateNewUser, UpdateUserProfileInformation, FortifyServiceProvider, config/fortify.php, or auth guards. Fortify is the frontend-agnostic authentication backend for Laravel that registers all auth routes and controllers. Also activate when building SPA or headless authentication, customizing login redirects, overriding response contracts like LoginResponse, or configuring login throttling. Do NOT activate for Laravel Passport (OAuth2 API tokens), Socialite (OAuth social login), or non-auth Laravel features.

    Also in 7 projects that use this

  • datashamanSkill

    configuring-horizon

    Use this skill whenever the user mentions Horizon by name in a Laravel context. Covers the full Horizon lifecycle: installing Horizon (horizon:install, Sail setup), configuring config/horizon.php (supervisor blocks, queue assignments, balancing strategies, minProcesses/maxProcesses), fixing the dashboard (authorization via Gate::define viewHorizon, blank metrics, horizon:snapshot scheduling), and troubleshooting production issues (worker crashes, timeout chain ordering, LongWaitDetected notifications, waits config). Also covers job tagging and silencing. Do not use for generic Laravel queues without Horizon, SQS or database drivers, standalone Redis setup, Linux supervisord, Telescope, or job batching.

    Also in 6 projects that use this

  • ownegoSkill

    livewire-development

    Use for any task or question involving Livewire. Activate if user mentions Livewire, wire: directives, or Livewire-specific concepts like wire:model, wire:click, wire:sort, or islands, invoke this skill. Covers building new components, debugging reactivity issues, real-time form validation, drag-and-drop, loading states, migrating from Livewire 3 to 4, converting component formats (SFC/MFC/class-based), and performance optimization. Do not use for non-Livewire reactive UI (React, Vue, Alpine-only, Inertia.js) or standard Laravel forms without Livewire.

    Also in 5 projects that use this

  • m3ueSkill

    ai-sdk-development

    TRIGGER when working with ai-sdk which is Laravel official first-party AI SDK. Activate when building, editing AI agents, chatbots, text generation, image generation, audio/TTS, transcription/STT, embeddings, RAG, vector stores, reranking, structured output, streaming, conversation memory, tools, queueing, broadcasting, and provider failover across OpenAI, Anthropic, Gemini, Azure, Groq, xAI, DeepSeek, Mistral, Ollama, ElevenLabs, Cohere, Jina, and VoyageAI. Invoke when the user references ai-sdk, the `Laravel\Ai\` namespace, or this project's AI features — not for Prism PHP or other AI packages used directly.

    Also in 5 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

49 rules. 0 are common, 42 are distinctive, and 7 are very specific to this project.

  • 0

    Common

    Most of the 16 edited versions we read keep these.

  • 42

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Always load this skill before designing, implementing, reviewing, auditing, or hardening TypeScript MCP servers.

    line 8
  2. Very specific:

    If you must support legacy clients, document exact compatibility with 2024-11-05 HTTP+SSE behavior.

    line 13
  3. Distinctive:

    Treat protocol version negotiation as mandatory, not optional.

    line 14
  4. Distinctive:

    If you adopt v2 package split, ensure examples use the correct package names for server, client, and runtime transports.

    line 35
  5. Distinctive:

    Do not assume server-side SSE transport support in new SDK major versions.

    line 36
  6. Distinctive:

    Treat MCP as three actors:

    line 40
  7. Distinctive:

    Keep domain logic transport-agnostic.

    line 63
  8. Distinctive:

    Use newline-delimited JSON-RPC messages and avoid corrupting framing.

    line 73
  9. Distinctive:

    Treat Streamable HTTP as the modern transport.

    line 77
  10. Very specific:

    Avoid any; use unknown at untrusted boundaries.

    line 87
  11. Distinctive:

    Use type narrowing and exhaustive checks.

    line 88
  12. Distinctive:

    Use Zod at every external boundary:

    line 93
  13. Distinctive:

    Use specific names and clear descriptions.

    line 114
  14. Distinctive:

    Prefer constrained schemas (enums, min/max, regex, unions).

    line 116
  15. Distinctive:

    Keep outputs structured and predictable.

    line 117
  16. Distinctive:

    Prefer output schemas for machine-consumable responses.

    line 118
  17. Distinctive:

    Use stable URI design.

    line 130
  18. Distinctive:

    Add pagination for large listings.

    line 132
  19. Distinctive:

    Use templates and completion for dynamic URI argument guidance.

    line 134
  20. Distinctive:

    Keep prompt templates deterministic and concise.

    line 143
  21. Distinctive:

    Treat prompts as user-controlled workflow scaffolding, not hidden policy overlays.

    line 144
  22. Very specific:

    Use includeContext carefully.

    line 161
  23. Distinctive:

    Keep token budgets explicit and bounded.

    line 162
  24. Distinctive:

    Keep form schemas simple and explicit.

    line 178
  25. Distinctive:

    Avoid collecting sensitive values via insecure channels.

    line 179
  26. Very specific:

    Never write logs to stdout.

    line 196
  27. Very specific:

    Avoid console.log in server paths.

    line 198
  28. Very specific:

    If text leaks into stdout, JSON-RPC framing can break and the client may disconnect.

    line 200
  29. Distinctive:

    Use structured logs with severity levels.

    line 220
  30. Distinctive:

    Keep request identifiers to correlate protocol events and downstream calls.

    line 222
  31. Distinctive:

    Prefer OAuth 2.1 or equivalent bearer-token controls.

    line 231
  32. Distinctive:

    Use short-lived credentials and rotation policies.

    line 233
  33. Distinctive:

    Do not accept token passthrough patterns that bypass proper audience validation.

    line 234
  34. Distinctive:

    Never use session IDs as authentication credentials.

    line 241
  35. Distinctive:

    Treat resource/tool content as potentially adversarial.

    line 245
  36. Distinctive:

    Treat annotations and model-supplied hints as untrusted unless you explicitly trust the source.

    line 249
  37. Distinctive:

    Add rate limits, execution timeouts, and resource quotas.

    line 255
  38. Distinctive:

    Run with least-privilege filesystem and network access.

    line 256
  39. Distinctive:

    Follow MCP authorization discovery and challenge flows for remote transports.

    line 260
  40. Distinctive:

    Keep stdio/local auth strategy separate from network resource-server auth strategy.

    line 262
  41. Very specific:

    Test capability negotiation (initialize) against the protocol version you target.

    line 276
  42. Distinctive:

    Verify schema validation failures return deterministic, model-correctable errors.

    line 278
  43. Distinctive:

    Test cancellation and task polling/result flows when implemented.

    line 279
  44. Distinctive:

    Add health checks and readiness probes.

    line 295
  45. Distinctive:

    Ensure graceful shutdown includes SSE stream cleanup and pending task persistence strategy.

    line 298
  46. Distinctive:

    Run lint, type-check, tests, and security scans on every PR.

    line 302
  47. Distinctive:

    Use least-privilege CI tokens.

    line 303
  48. Distinctive:

    Keep secrets in managed secret stores, never in logs.

    line 304
  49. Distinctive:

    Add rollback-friendly deployment strategy (canary/blue-green).

    line 305

“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

MCP Development Skill

Always load this skill before designing, implementing, reviewing, auditing, or hardening TypeScript MCP servers.

Protocol Target

  • Target MCP protocol revision: 2025-11-25.
  • If you must support legacy clients, document exact compatibility with 2024-11-05 HTTP+SSE behavior.
  • Treat protocol version negotiation as mandatory, not optional.

When to Use

  • Building a new MCP server from scratch
  • Choosing between STDIO and Streamable HTTP transport
  • Designing tools, resources, and prompts with strict schemas
  • Hardening security for multi-tenant or networked deployments
  • Setting up testing, CI/CD, and production operations
  • Reviewing an existing MCP server for protocol correctness and resilience

When NOT to Use

  • Simple one-off scripts with no MCP protocol surface
  • Frontend-only tasks unrelated to MCP integration
  • Generic REST API design without MCP-specific concerns

SDK Version Guardrails

  • Be explicit about TypeScript SDK generation in docs and examples.
  • Current official guidance indicates v2 is still evolving; validate stability expectations before production rollout.
  • If you adopt v2 package split, ensure examples use the correct package names for server, client, and runtime transports.
  • Do not assume server-side SSE transport support in new SDK major versions; confirm with the current migration docs.

Architecture First

Treat MCP as three actors:

  • Host: the user-facing AI application
  • Client: host-side protocol manager for one server connection
  • Server: your TypeScript process exposing tools/resources/prompts

Separate two layers:

  • Data layer: JSON-RPC 2.0 semantics and MCP capability lifecycle
  • Transport layer: how bytes move (STDIO or Streamable HTTP)

Transport Decision Matrix

VectorSTDIOStreamable HTTP
Runtime modelChild process per clientIndependent network service
ConcurrencySingle client per processMulti-client and multiplexed
LatencyVery low local latencyNetwork and TLS overhead
Auth complexityLocal trust boundaryOAuth/token/TLS required
Best fitLocal IDE, desktop workflowsShared services, SaaS, multi-tenant

Guideline:

  • Keep domain logic transport-agnostic.
  • Implement transport as an adapter at the edge.
  • Reuse one server core for both local STDIO and production Streamable HTTP.

Transport Compliance Essentials

STDIO

  • stdout is protocol-only JSON-RPC traffic.
  • Send logs and diagnostics to stderr only.
  • Use newline-delimited JSON-RPC messages and avoid corrupting framing.

Streamable HTTP

  • Treat Streamable HTTP as the modern transport; legacy HTTP+SSE is compatibility mode.
  • Honor required headers and session lifecycle semantics.
  • Validate Origin and Host for browser-facing or local-network-exposed endpoints.
  • Preserve protocol version continuity via MCP-Protocol-Version on subsequent requests.

TypeScript Foundations

Compiler Discipline

  • Enable strict TypeScript settings.
  • Avoid any; use unknown at untrusted boundaries.
  • Use type narrowing and exhaustive checks.
  • Handle nullish values consistently with explicit fallbacks.

Runtime Validation Boundary

Use Zod at every external boundary:

  • Tool input arguments
  • Prompt arguments
  • Resource template parameters
  • Environment configuration and secrets

Pattern:

  1. Parse unknown input with Zod.
  2. Return precise validation failure details.
  3. Execute business logic only after parse success.

Also validate environment and secret configuration at startup so the server fails fast with actionable diagnostics.

Core MCP Primitives

Tools (Actions)

Tools are the action surface. Design for model reliability:

  • Use specific names and clear descriptions.
  • Describe when the tool should and should not be used.
  • Prefer constrained schemas (enums, min/max, regex, unions).
  • Keep outputs structured and predictable.
  • Prefer output schemas for machine-consumable responses.
  • Return structuredContent when feasible, with text content for compatibility.

Failure handling rule:

  • For business-level failures, return tool content with isError: true.
  • Reserve protocol-level JSON-RPC errors for malformed requests, missing methods, or internal faults.

Resources (Read-only Context)

Resources provide durable context.

  • Use stable URI design.
  • Support template-based dynamic resources where appropriate.
  • Add pagination for large listings.
  • Notify clients when resource inventories change if your server supports it.
  • Use templates and completion for dynamic URI argument guidance.
  • Support subscriptions and updated notifications when data changes frequently.

Prompts (Reusable Scaffolding)

Prompts should be reusable and parameterized:

  • Capture repeatable workflows.
  • Inject runtime arguments instead of hardcoding context.
  • Keep prompt templates deterministic and concise.
  • Treat prompts as user-controlled workflow scaffolding, not hidden policy overlays.

Advanced Workflows

Sampling

Sampling allows the server to request model generations from the host.

Use it for:

  • Intermediate synthesis or transformations
  • Reasoning-heavy internal steps
  • AI-assisted decision support without server-owned model keys

Best practices:

  • Request only the minimum required context scope.
  • Use includeContext carefully; newer protocol guidance soft-deprecates broader context usage unless explicitly supported.
  • Keep token budgets explicit and bounded.
  • Preserve user approval and review boundaries.

Elicitation

Elicitation asks the user for missing structured input mid-workflow.

Use it when:

  • Required parameters are missing
  • Multiple risky paths need user selection
  • Human confirmation is needed before mutation

Best practices:

  • Define required input shape via JSON schema.
  • Keep form schemas simple and explicit.
  • Avoid collecting sensitive values via insecure channels.
  • Resume workflow only after validated response.
  • Make error and cancellation states explicit.

Progress, Cancellation, and Tasks

  • Accept and propagate progress tokens for long-running operations.
  • Send progress notifications with monotonic updates.
  • Implement cancellation handling and idempotent cleanup paths.
  • For long async operations, prefer task-based execution where clients support it.

Error Handling and Logging

The STDIO Rule

For STDIO servers, stdout is protocol-only.

  • Never write logs to stdout.
  • Route all logs and diagnostics to stderr.
  • Avoid console.log in server paths.

If text leaks into stdout, JSON-RPC framing can break and the client may disconnect.

JSON-RPC Error Mapping

Map failures intentionally:

  • -32700: Parse error
  • -32600: Invalid request object
  • -32601: Method not found
  • -32602: Invalid params
  • -32603: Internal error
  • -32000 to -32099: App-specific server errors

Custom error classes:

  • Preserve prototype chains for reliable instanceof checks.
  • Centralize mapping from app errors to JSON-RPC errors.

Logging guidance:

  • Use structured logs with severity levels.
  • Redact secrets and sensitive payload fragments.
  • Keep request identifiers to correlate protocol events and downstream calls.

Security Baseline

Assume untrusted input, even from the model itself.

Identity and Transport

  • Enforce TLS for network transports.
  • Prefer OAuth 2.1 or equivalent bearer-token controls.
  • Validate token audience/scope on every call.
  • Use short-lived credentials and rotation policies.
  • Do not accept token passthrough patterns that bypass proper audience validation.

Local and Network Hardening

  • Bind local services to 127.0.0.1 when intended for local use.
  • Validate Host and Origin headers.
  • Reject insecure callback and auth URL configurations.
  • Never use session IDs as authentication credentials.

Prompt Injection and Over-Agency

  • Treat resource/tool content as potentially adversarial.
  • Sanitize and constrain tool inputs.
  • Minimize tool privileges and reachable blast radius.
  • Segment sessions to avoid context bleed between users.
  • Treat annotations and model-supplied hints as untrusted unless you explicitly trust the source.

Supply Chain and Runtime Controls

  • Pin and scan dependencies.
  • Maintain a software bill of materials when possible.
  • Add rate limits, execution timeouts, and resource quotas.
  • Run with least-privilege filesystem and network access.

OAuth and Authorization

  • Follow MCP authorization discovery and challenge flows for remote transports.
  • Return standards-compliant auth challenges and metadata when access tokens are missing or invalid.
  • Keep stdio/local auth strategy separate from network resource-server auth strategy.

Testing Strategy

Build a layered test pyramid:

  1. Protocol conformance tests for JSON-RPC framing and IDs
  2. Unit tests for business logic and validators
  3. Integration tests for transport and capability negotiation
  4. Security tests for injection, traversal, malformed inputs
  5. Performance tests for concurrency and streaming stability

Protocol-focused additions:

  • Test capability negotiation (initialize) against the protocol version you target.
  • Validate header/session requirements for Streamable HTTP.
  • Verify schema validation failures return deterministic, model-correctable errors.
  • Test cancellation and task polling/result flows when implemented.

Tooling Suggestions

  • MCP Inspector for interactive development and schema verification
  • Jest or Vitest for automated test suites
  • Load testing for Streamable HTTP endpoints
  • Semantic regression checks for prompt/resource quality where needed

Also keep a small suite of fixture-based wire examples to detect accidental response-shape drift.

Deployment and Operations

For Streamable HTTP servers:

  • Containerize for reproducible deployment.
  • Add health checks and readiness probes.
  • Support graceful shutdown on SIGINT and SIGTERM.
  • Close open streams and finish in-flight work before exit.
  • Ensure graceful shutdown includes SSE stream cleanup and pending task persistence strategy.

CI/CD guidance:

  • Run lint, type-check, tests, and security scans on every PR.
  • Use least-privilege CI tokens.
  • Keep secrets in managed secret stores, never in logs.
  • Add rollback-friendly deployment strategy (canary/blue-green).
  • Pin dependencies and run routine supply-chain scanning.

Production Readiness Checklist

  • Transport choice documented with threat model
  • Tool/resource/prompt schemas validated at runtime
  • No non-protocol writes to stdout in STDIO mode
  • Error taxonomy mapped to JSON-RPC codes
  • Auth, TLS, and token/audience validation implemented for network mode
  • Rate limits and timeouts configured
  • Session isolation and context-scoping enforced
  • Protocol, unit, integration, and security tests passing
  • Graceful shutdown and observability in place
  • CI/CD includes dependency and secret hygiene

Quick Wire Examples

Tool result with structured output

{
  "content": [{ "type": "text", "text": "Order total computed." }],
  "structuredContent": { "currency": "USD", "total": 42.5 },
  "isError": false
}

Progress notification

{
  "jsonrpc": "2.0",
  "method": "notifications/progress",
  "params": {
    "progressToken": "op-123",
    "progress": 40,
    "message": "Fetched 2/5 pages"
  }
}

Cancellation notification

{
  "jsonrpc": "2.0",
  "method": "notifications/cancelled",
  "params": {
    "requestId": "tool-call-17",
    "reason": "User cancelled"
  }
}

Minimal Starter Layout

src/
  index.ts                 # transport wiring
  server.ts                # MCP server creation and registration
  config.ts                # env parsing and Zod validation
  capabilities/
    tools.ts
    resources.ts
    prompts.ts
  lib/
    errors.ts
    logger.ts
    security.ts
tests/
  protocol/
  unit/
  integration/

Reference Files

  • references/protocol-versioning-and-negotiation.md
  • references/transports-stdio-vs-streamable-http.md
  • references/tools-resources-prompts-data-shapes.md
  • references/logging-progress-cancellation.md
  • references/tasks-experimental.md
  • references/security-authorization-oauth.md
  • references/typescript-sdk-v1-v2-notes.md

Official References

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.