tool_use mechanism when you’re building your own agent runtime,
without going through the MCP transport.
When to use this:
- You’re hosting your own agent and want full control over the prompting and the loop.
- You’re embedding Lavendly inside a larger product where the MCP stdio model doesn’t fit (serverless, edge, etc.).
- You want to combine Lavendly tools with tools from other systems in one tool call surface.
The pattern
Fetch the Lavendly operation catalog
GET /v1/_schema returns every operation with its input shape.
Convert that into Claude’s tool definition format once at startup.Load a skill into your system prompt
Concatenate one or more skill bodies (storyteller, multi-clip,
cost-aware) into the system prompt. This is what makes the agent
use the tools well.
Reference implementation (Node)
vs.call(name, args) is a thin dispatcher provided by the SDK that
forwards to the right HTTP endpoint based on the operation name. It
honors idempotency keys passed in args.idempotency_key.
Reference implementation (Python)
Composing skills
To layer multiple skills (storyteller + cost-aware), concatenate them in priority order:Why bother with the SDK pattern vs MCP?
| MCP | Anthropic SDK pattern | |
|---|---|---|
| Setup | Add one entry to a config file | Code |
| Tool transport | stdio JSON-RPC | In-process HTTP |
| Customization | Limited, clients dictate the prompt | Full, you own the system prompt |
| Multi-tool composition | One MCP per server, runtime merges | All tools in one catalog |
| Latency | Subprocess per call | In-process |
| Best for | End users in Claude Desktop, Cursor, Claude Code | Engineers building their own agent product |