custom-tools

List this organization's custom tools, newest first. Use when checking what already exists before writing another.

Create a custom tool: Starlark code for one account, one transform(arguments) function that answers a value. Use only for a calculation or format no existing tool provides, and use it as one step of a flow between the tools that fetch its input and the tool that acts on its output. It cannot call anything: to reach a system, create an HTTP tool pointed at a connection instead.

It arrives as a draft with a stated purpose. Its code is a hermetic transform: it is handed arguments and answers a value, and it cannot reach the network, the file system or anything else — so its declared reach must be empty. Nothing runs it until somebody publishes it.

What it is handed in a conversation is the merged call, not just what it declared. The run loop passes the effective five layers, so a transform also sees any fixed_parameters set on its catalogue row and the system layer's atteq_org_id and atteq_conversation_id. Write it to read the keys it wants and ignore the rest.

What one custom tool is for, and whether it has gone live. Use when you already have the custom tool's id and need its current status.

Delete a custom tool, its versions and its catalogue entry, for good. Use when the tool and all its code should stop existing.

The draft being edited, its code included. Use when you need to read the unpublished code before changing or trying it.

Edit the draft — its name, purpose, code, schemas or declared reach; only the fields sent change. Use when the unpublished tool needs to change before trying or publishing it; nothing here reaches a conversation.

The published version keeps running until publish_custom_tool, and the tool's catalogue entry keeps the name and schema it was published with.

Freeze the draft as a new version and make it the one conversations run. Use once try_custom_tool answers what you expected and the tool should go live.

Until a version is published, the tool's catalogue row (tool_id on the custom tool) exists and runs nothing. That row is what add_step takes and what update_node attaches, and each run uses whichever version is published, so a flow built around the tool needs no edit when the code changes.

Refused if the code will not run at all — it does not parse, it uses something the language does not have, or it defines no transform. The draft is left exactly as it was.

Publish an earlier version again, making it the one conversations run. Use when the current live version is wrong and an earlier one should run instead.

The draft is left alone; this changes what runs, not what is being edited.

Run the draft on sample input, without publishing or registering anything. Use before publish_custom_tool, to check the draft actually does what it should.

This is how you find out what code you were handed actually does. It reaches nothing: the transform is given these arguments and returns a value, and a failure is the answer rather than an error. Shape arguments the way the flow step will hand them — plain values here, since a step's "$ref:<step_id>.<path>" overrides are resolved before the transform sees them. It is not a way to test a tool that calls a system; that is test_tool on the HTTP tool.

It counts as a tool execution, exactly as testing a tool does. The code really runs and really costs something, and the draft it runs has been reviewed by nobody — so the meter is the one lever that makes asking for it repeatedly cost the asker rather than every other tenant.

The versions of this tool that went live, newest first. Use when reviewing history or picking a version to restore.