Add the transport you actually need
For a local stdio server, everything after -- is the child command. For a remote server, choose HTTP explicitly; OAuth-capable servers can trigger the authentication flow on first use.
Tool names are namespaced by server, but namespacing is not authorization. Review the server package or endpoint, filesystem roots, data access, and side effects before enabling its tools.
grok mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/dir
grok mcp add --transport http linear https://mcp.linear.app/mcpChoose scope and protect secrets
User-level servers live in ~/.grok/config.toml. Pass --scope project only when the integration should travel with the repository; that writes .grok/config.toml and makes review by every contributor essential.
Keep API tokens in environment variables. In the command below, single quotes preserve ${API_TOKEN} in config so Grok expands it only when loading the server; double quotes would expand and persist the secret immediately. A project server with the same name replaces the user server, so inspect precedence after adding one.
- Grant the smallest filesystem root.
- Prefer OAuth or environment expansion over literal tokens.
- Separate read-only research integrations from side-effecting systems.
grok mcp add --scope project filesystem -- npx -y @modelcontextprotocol/server-filesystem /path/to/dir
grok mcp add --transport http api "$MCP_SERVER_URL" --header 'Authorization: Bearer ${API_TOKEN}'Inspect and diagnose before delegating
List the effective servers and run doctor before trusting a tool in a real task. JSON output is available for machine checks, while grok inspect shows each origin and compatible configuration source.
Grok can also read documented compatible MCP configurations below native config priority. Treat that convenience as additional discovery surface: disable unused compatibility sources and resolve duplicate names deliberately.
grok mcp list
grok mcp doctor
grok inspect