nous-portal-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TOOL_GATEWAY_DOMAIN | No | Gateway domain | nousresearch.com |
| TOOL_GATEWAY_SCHEME | No | Gateway scheme | https |
| FIRECRAWL_GATEWAY_URL | No | Optional vendor-specific override | |
| NOUS_PORTAL_CLIENT_ID | Yes | Required Portal OAuth client ID | |
| NOUS_PORTAL_STATE_DIR | Yes | Required private local per-seat state directory | |
| NOUS_PORTAL_SPEND_LIMIT_USD | No | Future paid-call ceiling |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| nous_portal_statusB | Report whether the portable Nous Portal adapter is configured. Never reveals credentials. |
| nous_portal_routesA | List locally derived Nous Portal vendor gateway routes. Makes no external request and invokes no paid tool. |
| nous_portal_auth_startA | Start a Nous Portal device-code login. Makes one unmetered external request, stores the private device code locally, and never opens a browser or sends the code to another channel. |
| nous_portal_auth_pollA | Poll a previously started device-code login exactly once. Makes one unmetered external request and atomically stores authorized tokens without returning token values. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a clear, distinct purpose: checking configuration, listing routes, starting device-code login, and polling for authentication. No ambiguity or overlap exists.
All tool names follow a consistent snake_case pattern with 'nous_portal_' prefix, making them predictable and easy to understand.
With 4 tools covering status, routes, and the auth flow (start + poll), the count is well-scoped for the server's purpose without being too thin or excessive.
The tool surface covers essential operations for the adapter (status, routes, authentication start and poll). Minor gaps like logout or token refresh are missing, but the core workflow is complete.