Claude API Server Tools

Build or audit a fail-closed Claude Platform server-tool plan without inventing fields, versions, defaults, prices, or compatibility. [DOC]

Boundary

• The manifest exposes seven routing IDs. Six are server-owned families; programmatic-tool-calling activates this skill only for the mechanical code_execution/allowed_callers/caller.tool_id/container sub-contract. [CONFIG]
• Route the integral programmatic agent loop, continuation ordering, retry policy, and loop budgets to claude-api-tool-runtime plus katas-deterministic-agent-loop. [CONFIG]
• Route client-only tool_use / tool_result loops, retries, and streaming assembly to claude-api-tool-runtime. [CONFIG]
• Route tool names, descriptions, and input-schema ergonomics to tool-use-design. [CONFIG]
• Route organization-wide privacy policy beyond the source-supported ZDR/retention facts here to data-privacy-governance. [CONFIG]
• Route MCP server or connector implementation to mcp-engineering; this skill only enforces the corpus-stated MCP intersections. [CONFIG]
• Route Files API/PDF lifecycle to claude-api-files-documents, context/cache policy to claude-api-context-management, and application-owned memory/bash/editor/computer handlers to claude-api-client-tools. [CONFIG]

Contract

• Acceptance: return a versioned plan that preserves concrete server-result block types, correct stop-state continuation, exact client-result correlation, tool definitions, caller/container state, domain policy, and supported governance controls. [DOC][INFERENCIA]
• Evidence: every platform claim must map to one of the seven local normalized sources in references/official-source-map.md; otherwise emit coverage_gap and do not convert it into an API rule. [CONFIG]
• No generic API block named server_tool_result is asserted: the corpus shows tool-specific result block types paired to server_tool_use.id through tool_use_id. [DOC]
• Fail closed when a plan mixes allowed_domains with blocked_domains, loses pending tools/container state, answers a srvtoolu_ ID with client tool_result, relies on allowed_callers as authorization, or claims unverified ZDR/cost behavior. [DOC][INFERENCIA]

Procedure

1. Select exactly one activation ID from assets/manifest.json; for programmatic-tool-calling, declare the runtime/kata handoff before validating the server mechanics. [CONFIG]
2. Load only the matching source rows from references/official-source-map.md, then the narrow reference needed for the plan. [CONFIG]
3. Start from templates/server-tool-plan.json; preserve actual request/response field names and keep planner-only governance under governance. [CONFIG]
4. Apply assets/server-tool-checklist.md; distinguish a completed server call from a pending server call by result correlation, not block position. [DOC]
5. Validate with python3 scripts/validate_server_tool_plan.py --plan PLAN.json; semantic errors make the command non-zero, while explicit warnings or coverage_gap entries remain visible in the report. [CÓDIGO]
6. For package maintenance, run bash scripts/check.sh; it executes all eval fixtures and offline unit tests. [CÓDIGO]

Runtime Rules

• A direct server call produces server_tool_use; the API executes it and returns the tool-specific result, normally in the same assistant response. The client must not send a tool_result for srvtoolu_.... [DOC]
• For a server-only parallel group, correlate every tool-specific result to its own server_tool_use by tool_use_id; preserve independent in-band failures, send no client tool_result, and do not synthesize a mixed-client continuation. [DOC][INFERENCIA]
• pause_turn continuation appends the assistant content unchanged and resends the same tools; it adds no user tool_result. Bound repeated continuations. [DOC][INFERENCIA]
• A mixed server/client response ends with tool_use; send one client tool_result per pending client tool_use, with no extra content, and preserve the same tools. The deferred server call executes on continuation. [DOC]
• A programmatic client call has caller.type: code_execution_20260120 and a caller.tool_id that names its parent code-execution server_tool_use; server-side mechanical validation also requires the returned container ID. Loop ownership remains with claude-api-tool-runtime plus katas-deterministic-agent-loop. [DOC][CONFIG]
• allowed_callers guides invocation and participates in validation, but is not a security boundary; enforce authorization in the client tool itself. [DOC][INFERENCIA]
• Web domain lists are mutually exclusive, scheme-free, ASCII-only, and organization-policy constrained; web fetch matches domains only and requires the URL to have appeared in prior conversation context. [DOC]
• Reject Unicode domain entries before policy comparison because visually confusable homographs can bypass human review; request-level allowlists remain subordinate to organization policy. [DOC]
• ZDR is source-supported for web_search_20250305 and web_fetch_20250910; web versions _20260209 or later require allowed_callers: ["direct"] to disable dynamic filtering for ZDR eligibility. Other ZDR claims are a coverage_gap in this corpus. [DOC]
• Keep PHI out of tool definitions even where strict tool use is HIPAA-eligible, and separate API ZDR from search/fetch publisher retention. [DOC]
• Code-execution and programmatic container data can be retained up to 30 days; Files API artifacts created by code execution persist until explicitly deleted. [DOC]
• Treat external programmatic tool results as untrusted strings: validate before interpretation as code, reject recursive $ref/strict/forced-choice incompatibilities, and distinguish direct client execution from self-managed and Anthropic-managed sandboxes. [DOC][CONFIG]
• Advisor usage must be tracked through usage.iterations; advisor subinference is billed separately from top-level executor usage, without embedding numeric prices in the plan. [DOC]
• Tool search has no separate usage.server_tool_use counter; loaded tool definitions count as input tokens. Programmatic efficiency claims require workload measurement and are not guaranteed savings. [DOC]

Expected Output

• A policy plan (schema_version: 1) or execution trace (schema_version: "1.0") conforming to one branch of assets/server-tool-plan.schema.json. [CONFIG]
• A validation report with valid, stable issue codes, and coverage_gaps. [CÓDIGO]
• An evidence ledger listing only source IDs present in references/official-source-map.md. [CONFIG]
• A residual-risk statement for authorization, organization domain policy, retention acceptance, and any unverified ZDR or pricing detail. [INFERENCIA]

Resources

• README.md - package entry point and command examples. [CONFIG]
• references/official-source-map.md - exclusive source inventory and line ranges. [CONFIG]
• references/guardian-gap-contracts.md - exact continuation, lifecycle, error, and boundary gates. [CONFIG]
• knowledge/body-of-knowledge.md and knowledge/knowledge-graph.json - routing and dependencies. [CONFIG]
• assets/manifest.json, assets/server-tool-plan.schema.json, and assets/server-tool-checklist.md - activation and plan contracts. [CONFIG]
• scripts/validate_server_tool_plan.py and scripts/check.sh - stdlib-only offline gates. [CÓDIGO]

Packet

Capas del packet, cargables bajo demanda (disciplina ICM: una capa por vez, nunca todas juntas): references/ guías de profundidad (cargar UNA por etapa) · knowledge/ cuerpo de conocimiento · prompts/ prompts listos · examples/ salida de ejemplo · agents/ subagentes del packet · templates/ plantilla de output · scripts/ automatización local · assets/ recursos estáticos.