ToolCoPilot

ToolCoPilot is a chat rail in the tool editor. Describe what you want the tool to do and it writes the operation tree, validates it, runs it and reports back. The editor updates live as it works — you are watching the same draft it is editing. It edits one tool: the one you have open. “Build a tool that books a slot” means configure this tool, renaming it if the current name is a placeholder. It will not create a second tool unless you explicitly ask for one, and it will never delete the one you are in.

​

What it can reach

Its tools are the platform’s own API operations, run in-process as you. It gets the slice that concerns tools, and nothing else. That list is the whole surface. Everything on it is either about this tool, or a read it needs to name something it cannot invent.

​

What it deliberately cannot do

It also never sees a secret’s value. It can read the names in your workspace and write {{secrets.STRIPE_API_KEY}} into the tree; the value stays in the vault. And it runs as you, with your role — an editor drives it, a viewer can watch the conversation but cannot send a message.

​

What it is good at

• Building a tree from a description of an API. Paste the endpoint, the auth scheme and an example response, and say what the agent should do with it. It writes the http operation, the publish_fields that pick the values out, and the say or generate_reply that uses them.
• Fixing a validation error. Paste the error, or just say “validate and fix it”. Validation errors are precise about which operation and which token, and the CoPilot acts on them well.
• Writing a json_schema. Including the property descriptions, which are the part people skip and the model actually reads.
• Reshaping a response. “The API returns a nested array; get the first delivery’s date into tooldata” is a code operation it can write.

It is a worse choice for deciding whether a tool should exist, how many tools you need, or what the escalation policy on a transfer should be. Those are product decisions and it will take whatever you tell it.

​

How to prompt it

Give it the endpoint and the behaviour, not the tree.

The tool should look up a booking by reference. GET https://api.acme.example.com/bookings/{ref} with Authorization: Bearer from the ACME_API_KEY secret. It returns {booking: {date, time, table_size}}. The agent should read the date and time back to the caller and ask if they want to change it.

Things worth saying explicitly, because it will otherwise pick a default and tell you which one it picked:

• Whether a value should go in tooldata (this tool run only) or userdata (the rest of the session).
• Whether the agent should speak the result verbatim (say) or phrase it (generate_reply).
• What should happen when the endpoint fails — on_error is a real choice.

Ask it to validate and run before you believe it. The live snapshot it is given each turn tells it what the draft says, never whether it works.

​

Running your tool

​

Publishing

In this editor, publishing is your call. ToolCoPilot publishes when you ask it to, not on its own, and it says when a change is still only in the draft. Remember the other half: publishing the tool does not change live calls until the agents that attach it are published too. See testing and publishing.

​

Limits

The conversation is stored per tool, so you can close the editor and come back to it. Each CoPilot has its own thread against its own subject.

​

Next