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
- asmamest/Nexus-Skillstheir own version, first seen Oct 15, 2026
- Dricle/eveiltheir own version, first seen Oct 13, 2026
- RiprLutuk/PasPapantheir own version, first seen Oct 8, 2026
- SalesforceCommerceCloud/b2c-developer-toolingtheir own version, first seen Oct 8, 2026
- trypostit/tryposttheir own version, first seen Oct 8, 2026
- Blair2004/NexoPOStheir own version, first seen Oct 8, 2026
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-moneySkillcashier-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
datashamanSkillpassport-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
gdarkoSkillfortify-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
datashamanSkillconfiguring-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
ownegoSkilllivewire-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
m3ueSkillai-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
Other versions17 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 17
- coollabsio/coolify★ 66ksame name
- Relaticle/relaticle★ 1.8ksame name
- relaticle/relaticle★ 1.8ksame name
- Blair2004/NexoPOS★ 1.3ksame name
- whisper-money/whisper-money★ 1.1ksame name
- trypostit/trypost★ 832same name
- adeze/raindrop-mcp★ 188same name
- RiprLutuk/PasPapan★ 108same name
- SalesforceCommerceCloud/b2c-developer-tooling★ 58same name
- d-padmanabhan/agent-engineering-handbook★ 17same name
7 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- AGENTS.mdAGENTS.md
- ai-instructions/AGENTS.mdAGENTS.md
- agent-authoringSkill
- mcp-log-debuggingSkill
- mcp-programmatic-testingSkill
- mcp-yaml-testingSkill
- salesforce-developer-site-scraperSkill
- salesforce-help-site-scraperSkill
- skill-authoringSkill
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
- Distinctive: line 8
Always load this skill before designing, implementing, reviewing, auditing, or hardening TypeScript MCP servers.
- Very specific: line 13
If you must support legacy clients, document exact compatibility with 2024-11-05 HTTP+SSE behavior.
- Distinctive: line 14
Treat protocol version negotiation as mandatory, not optional.
- Distinctive: line 35
If you adopt v2 package split, ensure examples use the correct package names for server, client, and runtime transports.
- Distinctive: line 36
Do not assume server-side SSE transport support in new SDK major versions.
- Distinctive: line 40
Treat MCP as three actors:
- Distinctive: line 63
Keep domain logic transport-agnostic.
- Distinctive: line 73
Use newline-delimited JSON-RPC messages and avoid corrupting framing.
- Distinctive: line 77
Treat Streamable HTTP as the modern transport.
- Very specific: line 87
Avoid any; use unknown at untrusted boundaries.
- Distinctive: line 88
Use type narrowing and exhaustive checks.
- Distinctive: line 93
Use Zod at every external boundary:
- Distinctive: line 114
Use specific names and clear descriptions.
- Distinctive: line 116
Prefer constrained schemas (enums, min/max, regex, unions).
- Distinctive: line 117
Keep outputs structured and predictable.
- Distinctive: line 118
Prefer output schemas for machine-consumable responses.
- Distinctive: line 130
Use stable URI design.
- Distinctive: line 132
Add pagination for large listings.
- Distinctive: line 134
Use templates and completion for dynamic URI argument guidance.
- Distinctive: line 143
Keep prompt templates deterministic and concise.
- Distinctive: line 144
Treat prompts as user-controlled workflow scaffolding, not hidden policy overlays.
- Very specific: line 161
Use includeContext carefully.
- Distinctive: line 162
Keep token budgets explicit and bounded.
- Distinctive: line 178
Keep form schemas simple and explicit.
- Distinctive: line 179
Avoid collecting sensitive values via insecure channels.
- Very specific: line 196
Never write logs to stdout.
- Very specific: line 198
Avoid console.log in server paths.
- Very specific: line 200
If text leaks into stdout, JSON-RPC framing can break and the client may disconnect.
- Distinctive: line 220
Use structured logs with severity levels.
- Distinctive: line 222
Keep request identifiers to correlate protocol events and downstream calls.
- Distinctive: line 231
Prefer OAuth 2.1 or equivalent bearer-token controls.
- Distinctive: line 233
Use short-lived credentials and rotation policies.
- Distinctive: line 234
Do not accept token passthrough patterns that bypass proper audience validation.
- Distinctive: line 241
Never use session IDs as authentication credentials.
- Distinctive: line 245
Treat resource/tool content as potentially adversarial.
- Distinctive: line 249
Treat annotations and model-supplied hints as untrusted unless you explicitly trust the source.
- Distinctive: line 255
Add rate limits, execution timeouts, and resource quotas.
- Distinctive: line 256
Run with least-privilege filesystem and network access.
- Distinctive: line 260
Follow MCP authorization discovery and challenge flows for remote transports.
- Distinctive: line 262
Keep stdio/local auth strategy separate from network resource-server auth strategy.
- Very specific: line 276
Test capability negotiation (initialize) against the protocol version you target.
- Distinctive: line 278
Verify schema validation failures return deterministic, model-correctable errors.
- Distinctive: line 279
Test cancellation and task polling/result flows when implemented.
- Distinctive: line 295
Add health checks and readiness probes.
- Distinctive: line 298
Ensure graceful shutdown includes SSE stream cleanup and pending task persistence strategy.
- Distinctive: line 302
Run lint, type-check, tests, and security scans on every PR.
- Distinctive: line 303
Use least-privilege CI tokens.
- Distinctive: line 304
Keep secrets in managed secret stores, never in logs.
- Distinctive: line 305
Add rollback-friendly deployment strategy (canary/blue-green).
“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.
Files
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-05HTTP+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
| Vector | STDIO | Streamable HTTP |
| Runtime model | Child process per client | Independent network service |
| Concurrency | Single client per process | Multi-client and multiplexed |
| Latency | Very low local latency | Network and TLS overhead |
| Auth complexity | Local trust boundary | OAuth/token/TLS required |
| Best fit | Local IDE, desktop workflows | Shared 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
stdoutis protocol-only JSON-RPC traffic.- Send logs and diagnostics to
stderronly. - 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
OriginandHostfor browser-facing or local-network-exposed endpoints. - Preserve protocol version continuity via
MCP-Protocol-Versionon subsequent requests.
TypeScript Foundations
Compiler Discipline
- Enable strict TypeScript settings.
- Avoid
any; useunknownat 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:
- Parse unknown input with Zod.
- Return precise validation failure details.
- 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
structuredContentwhen 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
includeContextcarefully; 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.login 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-32000to-32099: App-specific server errors
Custom error classes:
- Preserve prototype chains for reliable
instanceofchecks. - 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.1when intended for local use. - Validate
HostandOriginheaders. - 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:
- Protocol conformance tests for JSON-RPC framing and IDs
- Unit tests for business logic and validators
- Integration tests for transport and capability negotiation
- Security tests for injection, traversal, malformed inputs
- 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
SIGINTandSIGTERM. - 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
stdoutin 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.mdreferences/transports-stdio-vs-streamable-http.mdreferences/tools-resources-prompts-data-shapes.mdreferences/logging-progress-cancellation.mdreferences/tasks-experimental.mdreferences/security-authorization-oauth.mdreferences/typescript-sdk-v1-v2-notes.md
Official References
- https://modelcontextprotocol.io/specification/versioning
- https://modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle
- https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
- https://modelcontextprotocol.io/specification/2025-11-25/basic/security_best_practices
- https://modelcontextprotocol.io/specification/2025-11-25/server/tools
- https://modelcontextprotocol.io/specification/2025-11-25/server/resources
- https://modelcontextprotocol.io/specification/2025-11-25/server/prompts
- https://modelcontextprotocol.io/docs/tutorials/security/authorization
- https://github.com/modelcontextprotocol/typescript-sdk
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
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.

