Skip to main content
The 2.0 release introduces a breaking change: the former orchestrate toolkits import command has been renamed to orchestrate toolkits add. Additionally, a new orchestrate toolkits import command has been added, which works on files in a way that is the inverse of the orchestrate toolkits export command.
Local MCP toolkits run MCP servers inside the watsonx Orchestrate runtime using the stdio transport. They support both Python and Node.js implementations and can be imported from npm, PyPI, or your local filesystem. When to use local MCP toolkits:
  • You have existing MCP servers you want to reuse
  • You need Node.js for tool development
  • You want MCP protocol features (resources, prompts, etc.)
  • You want to share tools across multiple AI platforms
Performance characteristics:
  • Similar to standalone Python tools with process-per-invocation model
  • Process startup overhead of approximately 100-300ms per call
  • Suitable for moderate-frequency tool calls
For help choosing between local MCP toolkits, remote MCP toolkits, Python toolkits, and standalone Python tools, see Choosing a tool type.

Adding directly from the CLI

Use the orchestrate toolkits add command to add a local MCP toolkit into your environment.
BASH
orchestrate toolkits add
Examples:
BASH
# Setup connection if not already set
orchestrate connections add -a tavily
for env in draft live; do
    orchestrate connections configure -a tavily --env $env --type team --kind key_value
    orchestrate connections set-credentials -a tavily --env $env -e "TAVILY_API_KEY=$TAVILY_API_KEY"
done

# Import the toolkit
# Note this is a third party mcp server for illustrative purposes only, use the npm variant for production use
orchestrate toolkits add --kind mcp \
  --name tavily \
  --description "Search the internet" \
  --command "pipx  -y mcp-tavily@0.1.10" \
  --tools "*"  \
  --app-id tavily

Importing from a file

It is also possible to import an MCP server configuration from a file. The file contains the same configuration options used by the add command, within a yaml file, but is easier to integrate with import scripts and CI/CD pipelines.
BASH
orchestrate connections add -a my_connection
for env in draft live; do
    orchestrate connections configure -a my_connection --env $env --type team --kind key_value
    orchestrate connections set-credentials -a my_connection --env $env -e "SECURE_ENVIRONMENT_VARIABLE=value"
done

orchestrate toolkits import -f toolkit_name.yaml -a my_connection
toolkit_name.yaml
spec_version: v1
kind: mcp
name: toolkit_name
command: uvx ibm-watsonx-orchestrate-mcp-server
env: []
tools:
  - *
connections:
  - my_connection
package_root: ./my_toolkit_folder # <-- This is the folder containing your mcp server. The path is relative to this file.

Supported connection types for local MCP servers

Local MCP servers can use multiple connection types, and each connection type exposes a specific set of environment variables to the server. These variables allow MCP tools to read the required credentials directly at runtime. The following environment variables are provided for each connection type:
  • username
  • password
  • url
  • token
  • url
  • api_key
  • url
  • access_token
  • url
  • access_token
Coming soon
  • url
  • access_token
  • url
  • access_token
  • url
  • key1
  • key2

Comparing local MCP toolkits with other options

Local MCP vs Python toolkits:
  • Use local MCP when you need Node.js or MCP-specific features
  • Use Python toolkits for better performance with frequently called Python tools (no process overhead)
Local MCP vs Remote MCP:
  • Use local MCP when tools run inside Orchestrate infrastructure
  • Use remote MCP when tools must run on external infrastructure or cloud services
Local MCP vs Standalone Python tools:
  • Use local MCP when you need Node.js or want to reuse existing MCP servers
  • Use standalone Python tools for simpler Python-only tools without MCP protocol needs
For detailed comparison and decision guidance, see Choosing a tool type.

Next steps