Skip to main content
Because Ultra is itself an MCP server, it exposes built-in tools that your AI agent can call directly. This means you can search for, add, migrate, and monitor MCP connectors without leaving your conversation.
These tools are available automatically when Ultra is connected to your AI agent. No extra configuration needed.
These are Ultra’s own built-in tools. For the inventory of tools your upstream connectors (GitHub, Linear, and so on) expose — with usage, enforcement, and blocking — see Connector Tools in Ultra Hub.

​
Available Tools

Ultra provides these built-in tools:
ultra_servers renders an interactive panel to view, discover, add, and reconnect connectors visually. See the MCP App page.
Most of these need you to be signed in to Ultra Hub. Only ultra_status and ultra_migrate work without it, matching the CLI commands they mirror. If a tool reports that it needs authentication, run ultra login and call it again — there is no need to restart your agent.
In addition to these management tools, Ultra aggregates all tools from your upstream connectors and exposes them through a single connection. Each upstream tool is namespaced with its connector name, so two connectors offering a similarly named tool never collide.

​
ultra_status

Check that Ultra is running and see what’s connected. Example prompts:
  • “Check my Ultra status”
  • “How many MCP tools do I have connected?”
Returns: Ultra version, number of upstream connectors, and total aggregated tool count. Search the official MCP registry and npm for connectors to add. Example prompts:
  • “Search for a Notion MCP connector”
  • “Find MCP connectors for databases”
  • “Search npm for filesystem MCP connectors”
Parameters: Returns: Connector names, descriptions, versions, authors, download counts, and required environment variables.

​
ultra_add

Add an MCP connector and make its tools available immediately. No restart required. Example prompts:
  • “Add the GitHub MCP connector”
  • “Install the filesystem connector so you can read my project files”
  • “Add the Slack MCP connector at https://mcp.slack.com/mcp”
Parameters: What happens:
  1. Ultra resolves the connector from the registry or connects to the URL
  2. Validates any required environment variables
  3. Adds the connector to your Ultra config
  4. Hot-loads the connector immediately so new tools are available without restarting
Ultra hot-loads the connector with no restart of its own, and most agents pick up the new tools automatically. Some agents (for example, Codex CLI) only refresh their tool list on reconnect — if the new tools don’t appear, use ultra_tools and ultra_call to reach them without restarting, or refresh that agent and start a new conversation.

​
ultra_migrate

Discover MCP connectors already configured in your AI agents and import them into Ultra. Example prompts:
  • “Migrate my existing MCP connectors to Ultra”
  • “What MCP connectors do I have that aren’t going through Ultra yet?”
Parameters: What happens:
  1. Ultra scans your AI agents (Claude Desktop, Cursor, Codex, etc.) for configured MCP connectors
  2. Shows you what it found, including command and connection details
  3. On execute, imports selected connectors into Ultra’s config and hot-reloads them
  4. Duplicate connectors configured across multiple agents are merged automatically
After migration, restart your MCP agent(s) so they route through Ultra instead of connecting directly.

​
ultra_configure

Set settings on a connector you have already added. Use it when a connector needs credentials or configuration before it will work, for example a Slack client_id or a private app access token. Adding a connector is still ultra_add; this updates one that already exists. Example prompts:
  • “Set the Slack client_id and client_secret on the slack connector”
  • “Put my HubSpot private app access token on the hubspot connector”
Parameters: Each entry in values takes a type: An empty value clears that setting. What happens: Ultra reloads the connector’s configuration from disk before writing, so edits you made by hand are not overwritten. Settings are saved, and an enabled connector hot-loads them without restarting Ultra. If the connector still needs browser sign-in afterwards, use ultra_reconnect. If the hot reload cannot connect, Ultra says so and keeps the saved settings. Results name only the settings that were applied. Values are never echoed back, so secrets do not appear in your agent’s transcript.
Available on local devices only. Configuring connectors is not supported on a hosted device yet — see Where each tool runs.

​
ultra_reconnect

Re-authenticate a connector whose sign-in has expired, in place. Used automatically by the Reconnect button in the MCP App. Example prompts:
  • “Reconnect the Notion connector”
  • “Which connectors need me to sign in again?”
Parameters: What happens: For OAuth connectors, Ultra returns a sign-in link (and opens your browser when it can); once you finish, the connector’s tools come back automatically. It applies to local devices only, and only to connectors that use browser sign-in — token or API-key connectors are recovered with ultra config set-token <connector-name> instead. From a terminal, ultra reconnect <connector> is the CLI equivalent for a single OAuth connector. It saves the new token but can’t refresh a running agent, so restart your MCP agent afterward.

​
ultra_enable and ultra_disable

Turn a connector off without losing it, and turn it back on. ultra_disable disconnects a connector right away. Its tools stop working immediately, but its configuration and its stored sign-in are kept, so ultra_enable brings it back without re-adding it. If that sign-in expired or was revoked while the connector was off, ultra_enable returns a fresh sign-in link — so you may still be asked to sign in, but you never have to set the connector up again. Example prompts:
  • “Disable the filesystem connector for now”
  • “Turn the Linear connector back on”
Parameters: Use ultra_disable when you want a connector out of the way temporarily. To delete one for good, use ultra_remove.

​
ultra_remove

Permanently delete a connector: its configuration entry and any stored sign-in credentials are removed, and it disconnects right away. Re-adding it later means running ultra_add and signing in again. Example prompts:
  • “Remove the filesystem connector”
  • “Delete the old Jira connector and its credentials”
Parameters:
This is irreversible, so it takes two steps. Called without confirm, ultra_remove only reports exactly what would be deleted. Call it again with confirm: true to apply. If you meant to keep the connector and just stop using it, use ultra_disable instead.

​
ultra_tools and ultra_call

Some MCP agents do not refresh their tool list mid-conversation. When you add a connector or finish signing in to one, Ultra hot-loads it and announces the new tools, but an agent that ignores that announcement will not see them until it reconnects. ultra_tools and ultra_call are the way through. Because they are present from the start of the session, your agent can always call them, and they read Ultra’s live catalog on every call. So you list what is actually available now, then invoke the one you want, without restarting anything.
If you have just added a connector and your agent insists its tools don’t exist, this is the pair to reach for.

​
ultra_tools

Lists the upstream tools available through Ultra right now. Example prompts:
  • “List the tools Ultra has available”
  • “What GitHub tools can you reach through Ultra?”
Parameters: Returns: each tool’s namespaced name, title, description, and input schema, plus how many tools matched in total. When more remain, the response carries a nextOffset to pass back as offset. Narrowing with query or server is usually faster than paging.

​
ultra_call

Invokes one tool returned by ultra_tools. Example prompts:
  • “Use Ultra to search my GitHub repos for the deploy script”
  • “Call the Linear tool to list my open issues”
Parameters: The call runs through Ultra exactly as a direct call would, so governance, guardrails, and tracing all apply. The tool you select is a real upstream tool and may change external systems or data.

​
Where each tool runs

Ultra runs either on your own machine (a local device) or as enforcement Ultra operates for you (a hosted device). Most of these tools work in both places, but connector management that writes to local configuration does not yet. ultra_migrate is local by nature: it reads the MCP configuration of agents installed on a machine and writes back to that machine’s files. A hosted device has no view of your laptop, so there is nothing for it to discover. ultra_add on a hosted device covers remote connectors only. Adding one by URL works: Ultra discovers the connector’s OAuth metadata, registers a client, and returns a sign-in link to finish in your browser. Adding by package name or registry identifier — the @modelcontextprotocol/server-filesystem form shown above — installs a connector that runs as a local process, so it applies to local devices only. Where a tool isn’t available on a hosted device, it says so when you call it rather than failing quietly.

​
Upstream Tool Aggregation

Beyond its built-in tools, Ultra aggregates every tool, resource, and prompt from all your connected upstream connectors into a single MCP connection. Your AI agent sees one server (Ultra) with all tools available. Tools are automatically namespaced by connector name, so two connectors offering a similarly named tool never collide. Your agent sees the namespaced names in its own tool list, and ultra_tools reports the same names — use whichever your agent shows you rather than assembling one by hand. This means you can add a new upstream connector and its tools appear alongside everything else. No agent reconfiguration needed.

Upstream Connectors

Add and configure MCP connectors manually via CLI or config file

Migrate Connectors

Import existing connectors using the CLI wizard