Tool Selection and Endpoints
Filter tools at the workspace level and choose the right endpoint to expose
Tool Selection and Endpoints
The real value of a workspace is not just "putting services together," but "filtering tools by scenario before exposing them."
Screenshot placeholder: workspace tools panel, showing search, the tool list, disable toggles, and the logs tab switch.
Video placeholder: walkthrough of disabling some tools in a workspace, then copying the workspace JSON configuration to connect an external client.
Where Workspace Tools Come From
Workspace tools come from the MCP services you selected, but the tool set ultimately exposed to external clients is also affected by two layers:
- Service-level tool toggles
- Workspace-level tool toggles
In other words, a tool must remain enabled at both the service level and the workspace level before external clients can actually see it.
Why Filter at the Workspace Level Too
Workspace-level filtering suits these situations:
- The same service exposes only some of its tools in different workspaces
- You want a leaner tool set for a specific project
- You want to reduce the tool noise external clients see
This is far less work than duplicating multiple nearly identical MCP service configurations.
Common Actions on the Workspace Tools Page
On a workspace's tools page, you can typically:
- Search for tools
- See which MCP service a tool belongs to
- Enable or disable a specific tool
- Check the current number of available tools
If you already know a tool carries higher risk, it's a good idea to proactively disable it at the workspace level as well.
What a Workspace Endpoint Does
Every workspace generates its own gateway endpoint. This endpoint means:
When an external AI application connects through this address, it can only see the tool set currently exposed by this workspace.
This makes workspaces naturally well suited for scenario isolation.
Skills Generated from a Workspace Also Use the Workspace Endpoint
A workspace doesn't just affect the gateway configuration you copy directly to external clients; it also affects Skills exported or installed from the workspace.
- With
Aggregated Skill Generationoff, MCP2Skill generates an independent Skill for each member MCP service, but the invocation scripts of these Skills still point to the workspace endpoint - With
Aggregated Skill Generationon, MCP2Skill generates a single Skill representing the entire workspace, which likewise calls the workspace endpoint
So even though the output in non-aggregated mode looks like multiple single-MCP Skills, the tools actually callable are still constrained by the workspace's tool filtering.
The system workspace ALL uses the /all endpoint, while regular workspaces use their own /workspace/{name} endpoints.
Copy the Endpoint or Copy the JSON
The copy menu on the workspace detail page typically supports two usages:
Copy the Endpoint URL
Suitable when:
- You already know how to manually configure an MCP connection in the target AI application
- You only need the URL, or plan to assemble the configuration yourself elsewhere
Copy the JSON Configuration
Suitable when:
- You want to quickly connect a Claude Code compatible client
- You don't want to hand-write the configuration structure
- You want the required request headers included as well
If you have already enabled an API Key, this approach is especially convenient.
When to Use a Single MCP Service Endpoint
Better suited for:
- Exposing only one specific service
- Debugging a single service
- Cases where you don't need tool combination or filtering
When to Use a Workspace Endpoint
Better suited for:
- Bundling multiple services for the same client
- Controlling the range of tools visible externally
- Isolating tools by project or task
When to Use the ALL Endpoint
Better suited for:
- Verifying end-to-end connectivity for the first time
- Temporarily testing all enabled tools
- Quickly checking "whether the problem is caused by workspace configuration"
But if you want clarity and control in production use, a workspace endpoint you created yourself is usually the better choice.
What the Logs Page in a Workspace Is For
Besides the tools page, the workspace detail page also has a logs page. It helps answer questions like:
- Whether a workspace has been called recently
- Whether call failures occur only in this workspace
- Whether the currently filtered tool set matches your expectations
If you just changed the tool toggles, make an actual call and then come back here to confirm the result.
Related Chapters
- To learn about creating and editing workspaces: see Workspace Basics
- To generate Skills from a workspace: see Generate and Install Skills
- To connect the endpoint to clients: see Connect External AI Clients
- To view workspace call results: see Logs and Diagnostics