Build Claude-Powered Apps with SDKs

This skill guides application work using the Claude API, Anthropic SDKs, or Agent SDK. It starts by identifying the project language and choosing the simplest integration surface that meets the requirement. Classification, extraction, summarization, and question answering can use a single call; code-controlled multi-step work can use a workflow; open-ended tool-driven work may justify an agent.

The API supports custom tool definitions and either an SDK-managed or manual loop. Agent SDK is the documented path for built-in file, web, and terminal access, permissions, and MCP integration, with Python and TypeScript references. Language-specific API material also covers Java, Go, Ruby, C#, PHP, and raw HTTP. JavaScript uses the TypeScript reference, while Kotlin and Scala use Java guidance.

Use it for an actual Claude integration rather than unrelated programming. Before choosing an agent, assess complexity, value, viability, and whether errors can be detected and recovered from. A simpler call or workflow is preferred when those conditions do not justify open-ended execution.

Model choice follows the user's quality, latency, provider, and budget constraints. Exact identifiers and capabilities require account and official-documentation checks; cached examples are not a current compatibility matrix. SDK installation, uploads, batches, tools, and persistent memory need authorization within the relevant scope and resource budget. Existing authorization remains valid within that scope.

Inputs include the language, task, model constraints, data sensitivity, tool authority, and execution limits. Outputs are a selected surface, relevant reference path, and implementation guidance. The request architecture centers on POST /v1/messages, with separate batch, file, model-discovery, and token-counting endpoints. Anthropic embeddings require a separately approved provider rather than an assumed native embedding endpoint.

Structured responses and strict tool schemas constrain formats but do not establish factual correctness or permission. Validate tool inputs, business constraints, paths, and outputs before side effects. Use reviewed SDK versions and lockfiles, deadlines, bounded retries, turns, tool calls, output, and storage. Permissions and working directories do not provide operating-system isolation.

Preserve complete assistant content, tool results, thinking signatures, and compaction state. Collect all tool results for a turn, handle pause_turn, and inspect final stop reasons and usage. Streaming does not increase output limits or turn a partial, refused, or token-limited response into a validated answer. Check content block types instead of assuming the first block is text.

Credentials stay in approved storage. External uploads and hosted tools require attention to disclosure, retention, and deletion ownership. Avoid raw private requests, exception bodies, or file names in shared logs. Generated files need sanitization, and downloads use exclusive creation in a private directory. Environment-specific tests remain necessary before relying on the integration.