portal-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PORTAL_MCP_HOME | No | Use another base directory for portal-mcp data. By default data is kept outside the plugin in the OS user data directory under portal-mcp/. | |
| PORTAL_MCP_APPROVAL | No | Set to browser to always use the local confirmation page for write actions, even if the client supports MCP elicitation. | |
| PORTAL_MCP_DOWNLOADS | No | Directory where downloaded files go. By default files go to your Downloads folder. | |
| PORTAL_MCP_NO_NOTIFY | No | Set to 1 to turn off desktop notifications for waiting logins, completed logins, and confirmation pages. |
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 | {
"listChanged": true
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_servicesA | List loaded services, their profiles, session status, tools and load errors. |
| forget_sessionA | Delete the local session for a service without contacting the service. With browser_profile, also delete the browser profile (cookies and device memory) so the next login starts clean; the service may then ask to recognize the device again. |
| logoutA | Log out of a service (calls its logout endpoint if configured) and delete the local session. Without a profile, all profiles of the service are logged out. |
| self_testB | Run the read tools of a service and compare the structure of each answer with the structure saved when the tool was verified. Saves a baseline for tools that have none. Write and file tools are not run. Set update_baseline to accept the current structure as the new baseline. |
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 targets a distinct action: listing state, deleting a local session, logging out remotely plus clearing local state, and verifying tool output structures. forget_session and logout are the closest pair, but the descriptions explicitly contrast them (local-only vs. contacting the service's logout endpoint), so misselection risk is low.
All names are snake_case and mostly follow a verb_noun pattern (list_services, forget_session, self_test). 'logout' is a bare verb and 'self_test' is a noun-like compound, but the style is uniform enough to be predictable.
Four tools is a small but well-scoped surface for a session/service-management server, with no redundant members. It leans slightly thin, since a handful of related operations (login, reload, profile inspection) could plausibly belong here, but nothing feels padded.
The surface covers observing services, tearing down sessions, and validating tool contracts, but there is no operation to authenticate/start a session, reload a service after config or load errors, or inspect individual tool results beyond the self_test summary. Agents will often need to work around these gaps indirectly through the service's own tools.