Reuse thunk interfaces and plug-in connections

An interface is the list of tools a thunk advertises — each tool's name, description, and inputs — with no implementation attached. Another thunk can require that exact surface without naming who provides it. A third thunk can be created from the same file so it starts with those tools already stubbed out.

This is different from publishing a thunk as an MCP server for an external AI assistant, and from importing another thunk as a tool library. Those both bind you to one specific thunk. An interface lets you write against a contract, then plug in any connection that matches it.

There are three things you can do with an interface:

Export one from a thunk that already has tools.
Require one as a plug-in connection on another thunk.
Implement one by creating an MCP server from the file.

Export an interface

On a thunk that already has tools, open Admin → Deploy → Export and go to the Export Interface tab. Choose the name, description, and tools an outside caller should see, the same way you would when publishing the thunk as an MCP server.

The same tab has Download interface file and Copy to clipboard. The file is JSON: a name, a version, a description, and the tool signatures you turned on. Share it with whoever is building the calling thunk. Check against an interface compares this thunk's published tools to a file someone else depends on, so you can see a mismatch before they try to bind.

The file describes only the tools that are switched on for export. A tool you left unchecked is not in the contract.

Exporting the file does not turn the MCP server on. Publishing is a separate switch on the Enabled/Disabled tab.

Require an interface — a plug-in connection

A plug-in connection is a parameter of this thunk: a name plus the tools whatever is plugged in must provide. The thunk's steps call those tools through the name, so you can change the connection behind it later without rewriting the workflow.

Plug-in connections live on the thunk, not on your account. You do not create them under Account → Connections. Open the thunk's Connections pane and choose New plug-in connection….

Give it a Name — how this thunk will refer to the connection, for example CRM.
Choose an interface file, or pick a connection whose current tools should become the contract.
Optionally bind it now to an environment connection that provides exactly those tools. You can leave it unbound and bind it later from the connection's detail view.

The thunk's agent sees the tools under names that include the plug-in name (find_account_crm). Rebinding to a different matching connection does not rename them.

Matching is exact. The bound connection must expose each required tool with the same name, the same description, and the same inputs. Extra tools on the provider are fine. A rewritten description or a renamed argument is not — the parameter then contributes no tools, rather than a different surface than the one you designed against.

If a third-party MCP server's tools do not match the interface — different names, wording, or arguments — do not loosen the contract. Create an adapter: an MCP server from the same interface file whose tool bodies call the physical server. Bind the plug-in connection to the adapter.

A plug-in connection is a connection like any other at the step level. After you add it, enable or narrow it on a step the same way you would a library from Connections to business applications.

Implement an interface

To build a thunk that provides an interface, create an MCP server from the home page and upload the interface file on the description step. The Review step lists each tool with a type beside it — AI, Code, Database, Document Template, or Spreadsheet Lookup. New tools start as AI tools. You can change the type; you cannot change the name, description, or inputs. Those come from the file, because that is what other thunks bind to.

Thunk creates one custom tool per contract entry. The bodies are still yours to write. Creating the server this way does not publish it. When the implementations are ready, turn the export on under Admin → Deploy → Export.

You can also match a single new tool to one entry of an interface. On + Add New Tool, point at a file you upload or at an interface one of this thunk's plug-in connections already uses, then pick the tool it should match. Thunk fills in that tool's name, description, and inputs and leaves you to describe what it should do. Those three then stay fixed while the tool builder writes the implementation.

Coding agents

A coding agent building through the Builder API can do the same three things. The interface is always an inline JSON object — never a file upload.

Export. set_export turns the publish switch on and chooses tools. get_definition section export includes the interface document for the tools that are switched on, plus mcpUrl.
Require. add_thunk_connection with kind: "plugIn" declares a plug-in connection (alias + interface). Pass bindTo to bind or rebind it to an environment connection that matches; enabled: false removes the declaration from this thunk. get_definition section plugIns lists what this thunk requires.
Implement. create_thunk with kind: "mcpServer" and an interface object scaffolds one custom tool per contract entry. That does not publish the server — call set_export when the bodies are ready. batch_tools can pin a new tool to one interface entry with signature; later updates refuse changes to that tool's name, description, or input schema.
Check. Pass matchInterface on get_definition to see whether this thunk's published tools still satisfy a contract. Extra tools on this thunk are allowed; a missing or changed required tool is a mismatch.