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
1
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.2
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.
3
Run the tool-use loop
On each
tool_use block from Claude, call the matching Lavendly
HTTP endpoint. Return the result as tool_result. Repeat until
Claude stops with end_turn.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?
If you ever need both, say, internal tooling via the SDK pattern plus
end users via MCP, the same skill file works in either case.