This article is auto-synced from its in-app version in Tai.
The Connector Builder turns a read-only source (a REST or GraphQL API, a SQL or MongoDB database, an MCP server, a JSON or XML feed, even a single web page) into a connector your agents can query, through a chat instead of code.
When you'd use this
You want agents to answer from a live source that TAI doesn't ship a connector for yet: a public data API (weather, exchange rates, public holidays), a SaaS tool your company already uses (a helpdesk, a CRM, a project board), or an internal feed. Describe the source and the questions agents should answer, and the Builder proposes a plan, writes and tests the connector, and hands you a verified version to activate. For the everyday use of connectors, such as browsing the catalogue or assigning one to an agent, see Connectors.
Steps
In the sidebar, open Connectors, then All Connectors, and click Create connector. Give it a name and an optional one-line description and continue. You land in the Connector Builder.
In the chat, describe the source (a URL or a link to its documentation) and what your agents should be able to answer with it. The assistant asks one question at a time until it understands the job.
Review the plan the assistant proposes: the hosts it will reach, the credential fields it will declare (names only), and a table of operations with their inputs. Ask for changes until the plan is right, then approve it. Nothing is generated before you approve.
If the source needs authentication, enter the real values for the credential fields from the plan in the Credentials panel next to the chat and click Save credentials. The values are stored against this connector and never appear in the chat.
Watch the assistant write the connector and self-test every operation against the real source. It narrates what each test showed and fixes failures itself, so you don't need to relay errors.
When every operation passes, the assistant submits the connector for verification. The Submitted connector panel on the right shows the verification report: a contract check, a check that only the declared hosts are reached, a code safety check, and an independent review of the connector's stated intent. If verification finds issues, the assistant corrects them and resubmits.
Read the report and click Activate. The assistant may also propose a catalogue name and description for what it actually built; accept with Update connector or keep your own.
Click Open test drive to try the connector in the Connector Lab with a live chat and an invocation trace, then assign it to an agent from the agent's General tab.
To start over with a clean conversation, click New session. The connector and its saved credentials stay; only the chat restarts.
Writing a good first prompt
The Builder works best when the first message settles two things:
Say what agents should answer, not just what the API offers. "Agents should be able to say whether it will rain in Lisbon this weekend" produces two focused operations. "Connect the weather API" produces a guess.
Decide scope up front for large APIs. A CRM or helpdesk has hundreds of endpoints. Name the one area you need ("only support tickets, not contacts or deals") and the assistant curates a handful of operations instead of dumping the whole surface.
For ten complete first messages you can paste as they are, see Connector Builder examples.
What you can connect
REST APIs: public data APIs, the SaaS tools your company already uses, internal services.
GraphQL APIs: one endpoint, read-only queries. The platform reads each query before it is sent and refuses anything that would write or subscribe.
SQL databases: PostgreSQL and MySQL. Each operation runs exactly one SELECT, in a read-only transaction the platform opens on the connector's behalf. Enter the credentials of a read-only database role.
NoSQL databases: MongoDB, with find and aggregate reads pinned to one database. Enter the credentials of a read-only database role.
MCP servers: each tool the server offers becomes an operation.
Feeds and web pages: a JSON or XML feed, or a single HTML page.
One connector reaches one source. A second system is a second connector.
The assistant applies a few rules on your behalf, so you don't need to ask for them:
Read-only. Every operation only reads. If you ask for create, update or delete, the assistant explains that writes aren't supported and builds the read-only subset.
One source per connector. A connector reaches only the exact hosts named in the plan: at most three, no wildcards. A second system is a second connector.
Curated, not dumped. At most 30 operations, usually fewer than ten: the ones your stated questions need.
Shaped results. List and search operations return the fields agents need, with row and size limits, rather than whole records. Tell the assistant which fields matter.
Extraction, not judgement. A connector returns clean data; scoring, comparing and interpreting happen in the agent that calls it.
Credentials
Never paste a key, token or password into the chat. If you do, the assistant refuses to use it and asks you to remove it. Enter values only in the Credentials panel.
The assistant declares where the source expects the value (a header, a query parameter or HTTP Basic auth), and TAI attaches it to each call outside the connector's sandbox. Tell the assistant the mechanism if you know it ("send as
Authorization: Bearer <token>"), otherwise it asks.When the header is
Authorization, the value you save is sent as-is: for a bearer token, save the full value,Bearerfollowed by a space and the token.A Builder-built connector keeps its own credential values, separate from the shared provider credentials under Settings → Credentials. See Credentials.
Revising an active connector
Once a connector is active you can reopen it to fix a problem found in use, add or change an operation, or follow a change in the source's API.
Open the connector from Connectors, then All Connectors, and click Revise with AI. In the Connector Lab, the same button appears for the selected connector.
The assistant loads the active version's code, runs it unchanged against the source to confirm where things stand, and then proposes only what will change. Nothing is rewritten before you approve.
It builds, self-tests and submits the revision as in a first build. The Submitted connector panel adds Changes against the active version: operations added, changed or removed, hosts added or removed, whether the code or the credential fields changed. When an operation is removed or changed, it also lists the agents and skills that use the connector, since the change affects them on activation.
Click Activate to put the revision live. Until then, agents keep using the active version.
The revision chat is separate from the conversation that first built the connector, and saved credentials stay as they are. A revision keeps the connector's credential fields: changing them on an active connector isn't supported yet. The Versions section on the connector's page lists every version, newest first, with the version each revision was based on, and lets you view its code.
Tips and limits
Browsing connectors is open to all users; building a connector, editing or deleting a connector your company built, and test-driving one in the Connector Lab, require the Company Admin role.
Connectors are read-only. There is no way to create, update or delete records in the source system through a connector.
Self-tests run against the real source with the credentials you saved, so a rate-limited or metered API is called a handful of times during a build.
If the assistant cannot get an operation working after several attempts, it tells you what is blocking it, usually an ambiguous source behaviour or a limit only you can raise. Answer in the chat and it resumes from where it stopped.
Connector code runs in a separate, sandboxed runtime and never makes network calls itself: each request goes back through TAI, which checks the host against the plan and attaches the credentials. See Connectors.
Related