Connect local or remote MCP servers and their tools show up for the agent on the next turn, scoped to one project or every project.
SettingsMCP servers
Connect local or remote tools that ML.ai can use while working.
Add server
Developers integrating external tools, databases, or custom APIs into their coding workflow through the Model Context Protocol.
Scope a server to one project so the agent can reach that repo’s database.
Add a remote server by URL and share the same tools across the team.
Sign in with OAuth from ML.ai when the remote server supports it.
Point ML.ai at an MCP server by command or URL, add any env vars or headers, and its tools are there for the agent on the next turn.
Local server started by a command
Give the command that starts the server and the env vars it needs, such as a database URL. Secrets stay in the server config instead of the chat.
query(sql)
list_tables()
get_issue(id)
New tools on the next turn
Once a server connects, its tools are available to the agent from the next turn, so you can ask for them in the same conversation.
Use our hosted issues server
Remote server by URL with headers
Remote servers take a URL plus any headers and a timeout, and the ones that use OAuth let you sign in from ML.ai so there is no token to paste.
Add our issues server
Where should this server be available?
This project only
Every project (global)
Scope per project or globally
Keep a database server tied to the repo that uses it, and put tools you reach for everywhere, like an issue tracker, in global scope.
Runs on your machine, so it can reach your dev database
Give the command that starts the server, plus env vars such as a database URL. It runs on your machine, which suits databases, local files and internal CLIs.
Give the server URL, any headers and a timeout. If the server uses OAuth, sign in from ML.ai and its tools appear on the next turn.
From config to the first tool call, a server goes through four steps.
postgresLocal · ProjectConnected
List the tables in our dev database
Called postgres · list_tables()12 tables
What tends to go wrong when you first connect a server.
What goes wrong
How handles it
You add a server mid-conversation and ask for its tools straight away, before the agent has picked them up.
How handles it
Tools appear on the next turn after the server connects, so send one more message and they are ready to use.
Database URLs and API keys end up typed into the chat because there is nowhere else obvious to put them.
How handles it
Local servers take env vars and remote servers take headers, so credentials go in the server config instead of the conversation.
A remote server that is slow to respond can leave the agent waiting on a tool call far longer than you expect.
How handles it
Set a timeout on each server so a slow call gives up after a limit you choose.
Staged changes3 files
src/auth/session.ts+18−4
src/auth/rotate.ts+31
tests/session.test.ts+22
Skills
Prepare a skill instruction in the ML.ai composer.
name: release-notes
release-notes/name: release-notes
SKILL.mddescription: Draft notes from git log
example.md---
A skill is one file with frontmatter
Package the steps for a recurring task into a skill that calls your MCP tools the same way each time.
The agent proposes
$git statusRead&&rm -rf ~Irreversible deletion
Earlier in this session
git log --oneline -5-> read
cat package.json-> read
npm install zod-> write
git push --force origin main-> asks
Each command gets an effect
How shell commands are classified by effect before they run, alongside the tools your servers add.
Yes. When you add a server, choose project scope to keep it with one repo, or global scope to make it available in every project you open.
Add a local server when the tool needs your machine, such as a dev database, local files or an internal CLI: you give the command that starts it. Add a remote server when the tool is hosted: you give its URL, any headers and a timeout.
Not if it supports OAuth: sign in from ML.ai and there is nothing to paste. If it needs a header, reference an environment variable rather than writing the token into a project-scoped config, which lands in the repo.
Add a local or remote MCP server, pick its scope, and the agent can use its tools from the next turn.
