Knowledge BaseTool Creation

Creating a Tool

MergeSafe is explicit about tool creation. You define the tool contract yourself, choose the execution path deliberately, and save drafts before publish turns the project state into a versioned pack.

On this page

Start with the tool contract Define schemas early Choose the binding that matches the execution path Think in drafts first, publish second

Start with the tool contract

Tool creation starts from the behavior you want an agent or runtime caller to invoke. The safest path is to define the user-facing action first, then decide what inputs are required, what output should come back, and what real product path should perform the work.

Docs should describe this as manual tool creation. That is the active product direction and it avoids implying that MergeSafe is automatically inferring tools from scans, recordings, or generic browser behavior.

Define schemas early

Input and output schemas are part of the core tool model, not just a publish-time detail. They shape what the tool expects, what runtime validation can enforce, and how safely consumers can call the tool.

Use the input schema to describe what a caller must provide.
Use the output schema to describe the stable result shape the caller should receive.
Treat schema work as part of tool design, because mapping and response-shape problems often surface there first.

Choose the binding that matches the execution path

Choose HTTP when the tool should call an existing authenticated route or API-backed action through browser networking.
Choose Hook when the tool should invoke an explicit product-side callable function or hook path inside the runtime context.
Do not treat bindings as interchangeable styling. They encode real execution assumptions and failure modes.

Think in drafts first, publish second

Create, save, and revise tools as draft project state before you publish. That gives you room to refine schema shape, binding configuration, and operational expectations before a new pack version is produced.

The publish system later evaluates the project state and determines which tools are invalid, skipped, or publishable. A careful draft mindset keeps that boundary clear.