{"slug":"mcp-best-practices","title":"mcp-best-practices","summary":"Build, harden, and debug production MCP servers with the TypeScript SDK. Use when writing or reviewing an MCP server or its tools - picking a transport, designing tool schemas and results, handling errors, adding OAuth, cutting token bloat, or migrating SDK versions. Also covers ","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-08-30T09:47:20.579054Z","repo":{"url":"https://github.com/tenequm/skills","stars":37,"forks":1,"license":"MIT","updatedAt":"2026-09-22T22:37:09Z"},"bodyHtml":"
\n

name: mcp-best-practices\ndescription: Build, harden, and debug production MCP servers with the TypeScript SDK. Use when writing or reviewing an MCP server or its tools - picking a transport, designing tool schemas and results, handling errors, adding OAuth, cutting token bloat, or migrating SDK versions. Also covers MCP Apps, extensions, and the Registry. Assumes a working server already exists rather than scaffolding one from scratch.\nmetadata:\nversion: \"1.1.1\"\ncategories: \"development, integrations\"\ntopics: \"mcp, typescript-sdk, tool-design, transports, server-hardening\"\nupstream: \"@modelcontextprotocol/sdk@1.30.0, @modelcontextprotocol/server@2.0.0, @modelcontextprotocol/ext-apps@1.7.5, modelcontextprotocol-spec@2026-07-28\"\nopenclaw:\nhomepage: https://github.com/tenequm/skills/tree/main/skills/mcp-best-practices\nemoji: \"\uD83D\uDD0C\"\nenvVars:\n- name: MAX_MCP_OUTPUT_TOKENS\nrequired: false\ndescription: Claude Code client-side cap on MCP tool result size, referenced in the result-size budget guidance

\n

MCP Best Practices

\n

Decision reference for building production MCP servers with the TypeScript SDK. Not a tutorial - assumes you already have a working server and need to make it correct, fast, and secure.

\n

Quick Reference

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ComponentCurrentNotes
Spec (released)2026-07-28 (specification)Stateless/sessionless overhaul - see \"Spec 2026-07-28\" below and references/spec-2026-07-28.md
Spec (still deployed)2025-11-25What most shipped clients and servers actually speak today; the v2 SDK's default
TS SDK (current)v2.0.0 (2026-07-27), nine packages in lockstep: /server, /client, /core, /hono, /express, /node, /fastify, /codemod, /server-legacySpeaks 2025-era by default; 2026-07-28 is opt-in
TS SDK (legacy)v1.30.0 (@modelcontextprotocol/sdk)Bug + security fixes for >=6 months after v2 GA; source on the v1.x branch
JSON Schema2020-12 default (2019-09 / draft-07 accepted since v2.0.0)-
TransportStreamable HTTP (remote), stdio (local)SSE + WebSocket removed in v2
ExtensionsMCP Apps (Stable, SEP-1865), Auth Extensions (official), Tasks (ext-tasks)Domain-specific WGs
RegistryPreview with v0.1 API freeze since 2025-10-24 (registry)GA pending
\n

v2 imports (current):

\n
import { McpServer } from \"@modelcontextprotocol/server\";\nimport { WebStandardStreamableHTTPServerTransport } from \"@modelcontextprotocol/server\";\nimport { ProtocolError, ProtocolErrorCode } from \"@modelcontextprotocol/core\";\n
\n

v1 imports (legacy line, still widely deployed):

\n
import { McpServer } from \"@modelcontextprotocol/sdk/server/mcp.js\";\nimport { WebStandardStreamableHTTPServerTransport } from \"@modelcontextprotocol/sdk/server/webStandardStreamableHttp.js\";\nimport { StdioServerTransport } from \"@modelcontextprotocol/sdk/server/stdio.js\";\n
\n

The Two Eras

\n

The most decision-relevant fact after the 2026-07-28 release: upgrading to SDK v2.0.0 does not move you to the new spec. A hand-constructed Client/Server/McpServer keeps speaking the 2025-era protocol it was written for.

\n

Every revision from 2024-10-07 through 2025-11-25 opens with initialize and shares one wire behavior - the SDK calls that family legacy. 2026-07-28 starts the modern era: no initialize, a server/discover advertisement instead, a _meta envelope on every request. Selection is explicit:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
versionNegotiation.modeBehavior
absent / 'legacy'The 2025 initialize handshake, byte for byte. No probe. This is the default.
'auto'Probe with server/discover; fall back to initialize against a 2025-only server
{ pin: '2026-07-28' }That revision or nothing - a pin never falls back
\n

Build new servers on the 2025-era wire unless you control both ends. The stateless design guidance throughout this skill is what makes the eventual era switch cheap.

\n

Tooling: SDK docs (v2); MCP Inspector, which connects as legacy by default (see \"Testing Against Each Era\" in references/spec-2026-07-28.md); the conformance suite; and the mcp-server-dev plugin for scaffolding.

\n

Server Setup

\n

Transport Decision

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ScenarioTransportKey Config
Remote, stateless (K8s, CF Workers)WebStandardStreamableHTTPServerTransportsessionIdGenerator: undefined, enableJsonResponse: true
Remote, stateful (long tasks, SSE)WebStandardStreamableHTTPServerTransportsessionIdGenerator: () => randomUUID()
Local CLI / Claude DesktopStdioServerTransportDefault
Legacy SSE clientsSSE removed in v2 - migrate to Streamable HTTP-
\n

Stateless Pattern (recommended for remote deployment)

\n

Per-request server+transport creation is the canonical pattern. Maintainer @ihrpr confirms: \"each transport should have an instance of MCPServer\" (#343). Sharing instances leaks cross-client data (GHSA-345p-7cg4-v4c7).

\n
app.post(\"/mcp\", async (c) => {\n  const server = new McpServer({ name: \"my-server\", version: \"1.0.0\" });\n  // Register tools, resources, prompts...\n  registerTools(server);\n\n  const transport = new WebStandardStreamableHTTPServerTransport({\n    sessionIdGenerator: undefined,   // stateless - no session tracking\n    enableJsonResponse: true,        // JSON responses, no SSE streaming\n  });\n\n  // All tools/resources must be registered before connect() (#893)\n  try {\n    await server.connect(transport);\n    return transport.handleRequest(c.req.raw);\n  } finally {\n    await transport.close();\n    await server.close();\n  }\n});\n
\n

The McpServer must be per-request, but its constant inputs must not be. Hoist to module level: Zod schemas, annotation objects ({ readOnlyHint: true, ... }), tool description strings, payment configs, upstream API clients.

\n

If you only route POST (the common stateless layout), answer GET /mcp with an explicit 405 Method Not Allowed - the spec requires it when no SSE stream is offered, and the official TS client reads 405 as the benign no-stream signal, while an empty 200 sends it into a reconnect storm.

\n
\n

For transports, sessions, HTTP/2 gotchas, and K8s deployment: see references/transport-patterns.md

\n
\n

Framework Integration

\n

The transport is web-standard, so Hono and the Workers runtime need no adapter; v2 also ships @modelcontextprotocol/hono (createMcpHonoApp()) and @modelcontextprotocol/express (wrapping NodeStreamableHTTPServerTransport for IncomingMessage/ServerResponse). On Cloudflare Workers call preloadSchemas() at module scope - v2's workerd build does it automatically. Examples: references/transport-patterns.md.

\n

Tool Design

\n

Registration API

\n

v1 (legacy line) - server.tool(name, description, zodShape, annotations, handler). Positional overloads are ambiguous; same fields as v2 below minus outputSchema. Removed entirely in v2.

\n

v2 (current) - registerTool() with config object:

\n
server.registerTool(\"search_docs\", {\n  title: \"Document Search\",\n  description: \"Search documents by keyword or phrase\",\n  inputSchema: z.object({\n    query: z.string().describe(\"Search query\"),\n    max_results: z.number().optional().describe(\"Max results (default 20)\"),\n  }),\n  outputSchema: z.object({\n    results: z.array(z.object({ id: z.string(), text: z.string() })),\n    has_more: z.boolean(),\n  }),\n  annotations: { readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: true },\n}, async ({ query, max_results }) => {\n  const result = await fetchDocs(query, max_results);\n  return {\n    // Both channels carry IDENTICAL bytes. Divergent payloads = the text block\n    // silently vanishes on Claude Code/Codex/Copilot. See \"Tool Result Delivery\" below.\n    structuredContent: result,\n    content: [{ type: \"text\", text: JSON.stringify(result) }],\n  };\n});\n
\n

Naming

\n

Spec 2025-11-25 (SHOULD, not MUST): 1-128 chars, case-sensitive, A-Za-z0-9_-. only. DO: search_docs, get_user_profile, admin.tools.list. DON'T: search (generic names collide across servers), Search Docs (spaces disallowed). Service-prefix (github_*, jira_*) when multiple servers are active - LLMs confuse generic names.

\n

Schema Rules

\n

.describe() on every field - this is what LLMs use for argument generation. Three constructs break silently (z.union(), raw JSON Schema, z.transform()), as does client-side AJV strict validation - see \"Known SDK Bugs\" below.

\n

Pagination is the primitive most servers hit first: a tools/list or resources/list with 50+ entries should paginate. The protocol cursor is opaque - never parse or synthesize it; loop until nextCursor is absent. It is distinct from in-tool offset/limit args.

\n
\n

Zod-to-JSON-Schema conversion rules, outputSchema/structuredContent patterns, non-text content types, the other tool-definition fields (icons, listChanged, execution.taskSupport), and the remaining primitives (prompts, resources, resource templates, completions, cancellation): see references/tool-schema-guide.md

\n
\n

Annotations

\n

All are optional hints (untrusted from untrusted servers per spec):

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
AnnotationDefaultMeaning
readOnlyHintfalseTool doesn't modify its environment
destructiveHinttrueMay perform destructive updates (only when readOnly=false)
idempotentHintfalseRepeated calls with same args have no additional effect
openWorldHinttrueInteracts with external entities (APIs, web)
\n

Set them accurately - clients use them for consent prompts and auto-approval decisions.

\n

The \"Lethal Trifecta\": private-data access + exposure to untrusted content + external communication in one agent creates data-theft conditions (demonstrated with a malicious calendar event, an MCP calendar server, and a code-execution tool). Design tool sets so no single agent holds all three.

\n

Stateful Tools

\n

With no protocol-level session on 2026-07-28, cross-call state uses server-minted handles passed as ordinary tool arguments: a creation tool returns { basket_id: \"bsk_a1b2c3\" }, later tools take basket_id as an argument, and the model carries it forward. A handle is a name, not a capability - validate the caller against it on every call, keep it opaque with real entropy, and state its retention policy in the creation tool's description. Expired or unknown handles return a tool execution error so the model can recover by creating new state. Full rules: references/spec-2026-07-28.md.

\n

Tool Result Delivery: content vs structuredContent

\n

The footgun: when a tool returns BOTH a text content block and structuredContent, several major clients (Claude Code, Codex CLI, VS Code Copilot, Goose) silently drop the text block and forward only structuredContent to the model. If the two payloads differ, the human-readable one vanishes. This is client behavior the spec does not constrain - not an SDK transform. Don't return both channels expecting both to reach the model.

\n

Empirically tested - Claude Code 2.1.165 (MCP 2025-11-25)

\n

Measured with claude -p --output-format=stream-json, reading the exact tool_result the model received:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Tool returnsWhat the model receives
One text block, no structuredContenttext verbatim
content: [] + structuredContentJSON.stringify(structuredContent) as a string in the content slot - works
text block + structuredContenttext block silently dropped; structuredContent wins
text + structuredContent + outputSchemasame - outputSchema makes zero difference
two text blocks, no structuredContentboth preserved verbatim
\n

structuredContent is not a separate typed channel to the model on Claude Code - it is stringified into the standard tool_result content slot, so it costs the same tokens as the equivalent JSON-as-text. It does not buy cheaper or out-of-band structured data.

\n

Intentional, per Anthropic maintainer (anthropics/claude-code#9962): structuredContent support landed in Claude Code v2.0.21 and \"we made structuredContent the default when both formats are present... optimizing for agent performance.\" Reproduced across unrelated servers (Laravel, Roblox Studio, YouTube) - host-side precedence, not a server bug.

\n

What the spec actually says (2025-11-25)

\n

There is no precedence rule - the spec never says which field a client should prefer when both are present (Discussion #1563), and that gap is the documented root cause of client divergence. The only relevant normative line is a backwards-compat SHOULD: \"a tool that returns structured content SHOULD also return the serialized JSON in a TextContent block.\" The official TypeScript SDK passes both fields through verbatim; any stringify-into-content you observe is the host harness, not the SDK.

\n

Cross-client behavior (the matrix above is Claude Code only)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ClientWhen both content + structuredContent present
Claude Code CLI, OpenAI Codex CLI, VS Code Copilot, Gooseshadow - only structuredContent reaches the model (text dropped)
Cursor, Claude.ai web, ChatGPT MCP connectorprefer content / surface both to the model
Google ADK (framework)forwards both by default; content-only is opt-in
\n

(Non-Claude-Code rows come from issue trackers and maintainer statements, not the stream-json harness - treat exact delivery as client-version-dependent.)

\n

The rule for server authors

\n\n

content blocks are not text-only - image, audio, resource_link, and embedded resource blocks all exist, with annotations (audience, priority, lastModified); for those and the image preview + URL pattern see references/tool-schema-guide.md.

\n

Error Handling

\n

Two distinct mechanisms with different LLM visibility:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
TypeLLM Sees It?Use For
Tool error (isError: true in CallToolResult)Yes - enables self-correctionInput validation, API failures, business logic errors
Protocol error (JSON-RPC error response)Maybe - clients MAY exposeUnknown tool, malformed request, server crash
\n

Per SEP-1303 (merged into spec 2025-11-25): input validation errors MUST be tool execution errors, not protocol errors. The LLM needs to see \"date must be in the future\" to self-correct.

\n
// DO: Tool execution error - LLM can self-correct\nreturn {\n  isError: true,\n  content: [{ type: \"text\", text: \"Date must be in the future. Current date: 2026-03-25\" }],\n};\n\n// DON'T: Protocol error for validation - LLM can't see this\nthrow new McpError(ErrorCode.InvalidParams, \"Invalid date\");\n
\n

Known SDK behavior: converting an McpError thrown from a tool handler into a CallToolResult drops the error.data field, so structured data embedded there may never reach the client. The x402/MPP ecosystem standardized on isError: true results with structuredContent for this reason.

\n
\n

For full error taxonomy, code examples, payment error patterns, and why -32042 is not available as a \"Payment Required\" code: see references/error-handling.md

\n
\n

Resources and Instructions

\n

Set instructions in the server constructor - a system-level hint to the LLM about how to use your server:

\n
const server = new McpServer({\n  name: \"docs-api\",\n  version: \"1.0.0\",\n  instructions: \"Knowledge base API. Use search_docs for full-text search, get_doc for retrieval by ID. All tools are read-only.\",\n});\n
\n

Ship guides and structured data as resources under a docs:// URI scheme (server.resource(...)) - see \"Other Server Primitives\" in references/tool-schema-guide.md.

\n

Performance

\n

Token Bloat Mitigation

\n

Tool definitions consume context window before any conversation starts. GitHub MCP: 20,444 tokens for 80 tools (SEP-1576).

\n

Strategies:

\n
    \n
  1. 5-15 tools per server - community sweet spot. Split beyond that.
    2. \n
  2. Outcome-oriented tools - bundle multi-step operations into single tools (e.g., track_order(email) not get_user + list_orders + get_status).
    3. \n
  3. Response granularity - return curated results, not raw API dumps. 800-token user object vs 20-token summary.
    4. \n
  4. outputSchema + structuredContent - typed output for programmatic/PTC clients. Caveat: on shadowing clients structuredContent is stringified into the model's context at the same token cost as text - not a free out-of-band channel (see \"Tool Result Delivery\").
    5. \n
  5. Dynamic tool loading - register only relevant tool subsets per request context (e.g. a ?tools=search,fetch query param). Pair with listChanged if the set changes mid-session.
    6. \n
  6. Progressive tool discovery / code mode - large-catalog clients increasingly use a search_tools meta-tool and programmatic tool calling, where structuredContent is consumed outside the model context (client best practices). Curated, well-described tools make these flows work.
    7. \n
\n

Result-Size Budgets (per-client caps)

\n

Clients silently truncate large tool results. Budget for the strictest client you target:

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ClientDefault capConfigurable
Claude Code25,000 tokens (warning at 10k)MAX_MCP_OUTPUT_TOKENS env; per-tool _meta[\"anthropic/maxResultSizeChars\"] up to 500,000 chars
OpenAI Codex CLI10,000 bytes on byte-policy models (includes the JSON envelope)tool_output_token_limit config
Gemini CLI40,000 chars (head 20% / tail 80% trim; full output saved to a file)settings; 0 or negative disables
\n

Enforce your own cap server-side - see \"Result-Size Budgets and Truncation\" in references/tool-schema-guide.md. Two rules worth stating here: never truncate isError results (payment/auth challenges must survive intact), and treat client budgets as per-connection properties - accept them as URL query params (?max_chars=, alongside ?tools=) rather than growing every tool schema with override args.

\n

No-Parameter Tools

\n

For tools with no inputs, use an explicit empty schema - not undefined or omission:

\n
inputSchema: { type: \"object\" as const, additionalProperties: false }\n
\n

Security

\n

Top Threats (real-world incidents, 2025-2026)

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
AttackExampleMitigation
Tool poisoningHidden instructions in descriptions (WhatsApp MCP, Apr 2025)Review tool descriptions; clients should display them
Supply chainMalicious npm packages (Smithery breach, Oct 2025)Pin versions, audit dependencies
Stdio config injectionUser-controlled input reaches StdioServerParameters unsanitized (OX Security, 2026-04-15)Sanitize stdio config in client code; prefer first-party servers. Treated as \"by design\" - not patched in the SDK
Cross-server shadowingMalicious server overrides legitimate tool namesService-prefix tool names; validate tool sources
Token theftOver-privileged PATs with broad scopesMinimal scopes; OAuth 2.1 Resource Indicators (RFC 8707)
Token passthroughServer accepts/forwards tokens not issued for itValidate audience claim; never transit client tokens to upstream APIs
Confused deputyProxy server consent cookies exploited via DCRPer-client consent before forwarding to third-party auth
Session hijackingStolen/guessed session IDs for impersonationCryptographically random IDs, bind to user identity, never use for auth
Cross-client response leakShared McpServer/transport reused across clients (CVE-2026-25536, affects v1.10.0-1.25.3)Require SDK >= v1.26.0; per-request server+transport
UriTemplate ReDoSMalicious URI patterns (CVE-2026-0621)Upgrade to v1.25.2+ / v2.0.0-alpha.1+
\n

Generic hygiene still applies: validate inputs at tool boundaries, enforce per-user access control, rate limit, never interpolate tool input into shell commands, block private IPs on outbound fetches, bind local servers to 127.0.0.1.

\n

Server-Side Requirements (spec normative)

\n\n

Auth (OAuth 2.1)

\n

MCP normatively requires OAuth 2.1 (draft-ietf-oauth-v2-1-13), not 2.0 - PKCE mandatory, implicit flow removed. Servers are Resource Servers; clients MUST send Resource Indicators (RFC 8707) binding tokens to your server.

\n\n
\n

For full security attack/mitigation patterns and auth implementation details: see references/security-auth.md

\n
\n

Known SDK Bugs

\n

Must-know as of sdk@1.30.0 / server@2.0.0:

\n\n
\n

Full table (statuses, transport-closure stack overflow, HTTP/2, raw JSON Schema, z.transform(), ReDoS): see references/sdk-bugs.md

\n
\n

V2 Migration

\n
\n

For comprehensive migration guide with all breaking changes and before/after code: see references/v2-migration.md

\n
\n

Key breaking changes:

\n
    \n
  1. Package split: @modelcontextprotocol/sdk -> @modelcontextprotocol/server + /client + /core
    2. \n
  2. ESM-first (CJS builds restored in beta.2), Node.js 20+ (Bun/Deno supported)
    3. \n
  3. Zod v4 required (or any Standard Schema library)
    4. \n
  4. McpError -> ProtocolError (from @modelcontextprotocol/core)
    5. \n
  5. extra parameter -> structured ctx with ctx.mcpReq
    6. \n
  6. server.tool() -> registerTool() (config object, not positional args)
    7. \n
  7. SSE server transport removed (clients can still connect to legacy SSE servers)
    8. \n
  8. @modelcontextprotocol/hono and @modelcontextprotocol/express middleware packages
    9. \n
  9. DNS rebinding protection enabled by default for localhost servers
    10. \n
\n

v1.x gets 6 more months of support after v2 stable ships. No rush, but write new code with v2 patterns in mind.

\n

Spec 2026-07-28 (released)

\n

Published 2026-07-28 (release announcement, changelog) - now the latest revision. Remember it is opt-in on the SDK (see \"The Two Eras\"): 2025-11-25 remains what most deployed software speaks.

\n

Four shifts that change a decision you make today:

\n\n

The content vs structuredContent dual-delivery footgun is unchanged - no precedence rule landed, so the guidance above still holds.

\n
\n

Everything else - MRTR, subscriptions/listen, _meta identity keys, requestState, Mcp-Method/Mcp-Name, cacheable results, per-request log level, auth changes, the removals (SSE resumability, ping, execution.taskSupport), era testing, working groups: see references/spec-2026-07-28.md

\n
\n

Extensions

\n

Optional, strictly additive capabilities named {vendor-prefix}/{extension-name} (official: io.modelcontextprotocol/*; third-party: reversed domain). Negotiated in initialize capabilities on 2025-era wires; on 2026-07-28 clients advertise support per request in _meta[\"io.modelcontextprotocol/clientCapabilities\"]. Official ones: MCP Apps (/ui, interactive HTML UIs, Stable, widely supported), OAuth Client Credentials (Draft), Enterprise-Managed Authorization (Stable 2026-06-18) - client matrix.

\n

Server capabilities beyond tools, all 2025-era APIs (the SDK default):

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
CapabilityPurposev2 API
ElicitationRequest structured user input mid-toolctx.mcpReq.elicitInput()
SamplingRequest LLM completion from clientctx.mcpReq.requestSampling()
TasksLong-running ops with lifecycle managementOfficial extension (SEP-2663)
ProgressIncremental progress on requestsctx.mcpReq.sendProgress()
\n

On 2026-07-28 servers cannot send requests to clients at all: elicitation and sampling go through MRTR (return an InputRequiredResult, read inputResponses on the retry). Tasks moved out of core into the polled io.modelcontextprotocol/tasks extension (ext-tasks).

\n
\n

For MCP Apps architecture, ext-apps SDK, and build patterns: see references/mcp-apps.md\nFor the extensions system, auth extensions, elicitation/sampling/tasks detail, and the MCP Registry: see references/extensions-registry.md

\n
\n","files":[{"path":"CHANGELOG.md","sizeBytes":31085,"isText":true},{"path":"LICENSE.txt","sizeBytes":9157,"isText":true},{"path":"references/error-handling.md","sizeBytes":12456,"isText":true},{"path":"references/extensions-registry.md","sizeBytes":16084,"isText":true},{"path":"references/mcp-apps.md","sizeBytes":12712,"isText":true},{"path":"references/sdk-bugs.md","sizeBytes":7112,"isText":true},{"path":"references/security-auth.md","sizeBytes":24630,"isText":true},{"path":"references/spec-2026-07-28.md","sizeBytes":29927,"isText":true},{"path":"references/tool-schema-guide.md","sizeBytes":29192,"isText":true},{"path":"references/transport-patterns.md","sizeBytes":17855,"isText":true},{"path":"references/v2-migration.md","sizeBytes":25187,"isText":true},{"path":"SKILL.md","sizeBytes":33524,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"clean","suspicious":0,"notes":0,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-10T18:19:35.000855Z","sha256":"A6A39BD1A56C710D054DCF3F17BE724C1840EE43CE43649659F3BD9F5B54FC56","sizeBytes":99705},"review":null,"source":{"repositoryUrl":"https://github.com/tenequm/skills","path":"skills/mcp-best-practices","license":"MIT","commit":"3aa8070376a087ac5a4b1fca0749723fc176d003","subtreeSha":"ACCA213CCBFEE017F8058FA442003ECF645E5CB109341656558B4295A1407435","lastSyncedAt":"2026-09-28T20:55:29.777172Z"},"reviewedAt":"2026-09-10T18:20:50.991501Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/tenequm/skills/tree/main/skills/mcp-best-practices"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install tenequm-skills@llmmart"},{"target":"git","command":"git clone https://github.com/tenequm/skills.git"}]}