Client setup
Cursor and JSON-based clients
Use an mcpServers entry and check runtime, token forwarding and tool approval.
Cursor accepts a command-based MCP server entry using mcpServers. The same conceptual entry applies to clients that document that schema. Client file locations and secret handling differ; verify the destination in the client’s own documentation.
Create the server entry
{
"mcpServers": {
"toolport": {
"command": "npx",
"args": ["-y", "@toolport/mcp"],
"env": { "TOOLPORT_TOKEN": "REPLACE_WITH_LOCAL_SECRET" }
}
}
}REPLACE_WITH_LOCAL_SECRET is a marker, not a usable token. Use the client’s supported secret mechanism where available. A literal env value belongs only in private local configuration; never commit the example with a real credential.
Choose project or user scope
A project entry travels with that workspace. A user entry applies to your local account. Prefer project configuration for the non-secret command definition and user/local storage for credentials. Keep one toolport entry so the client does not discover duplicate names.
Check the connection
Validate JSON: quoted keys, commas between members, no comments or trailing comma.
Reload the MCP server after saving.
Confirm the process can resolve npx from the client environment.
Enable the tools through the client’s documented controls, then review a test call.
Antigravity and other clients
The homepage includes an Antigravity example using this command shape. That illustrates the template’s configuration concept; it is not verified compatibility. Use the client’s current MCP documentation for schema, file location, transport and environment behavior before adapting this block.
When tools appear but calls fail
Discovery proves the client can read the server’s tool definitions. It does not prove the token can read acme/sdk. Check repository access with a small list_labels call before widening your prompt.