Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
CONDUIT_PROFILENoScope this client to one profile's servers. Unset means the active profile.
CONDUIT_REGISTRYNoOverride the registry file location. Defaults to a stable per-user path.
CONDUIT_DISCOVERYNoPer-client override of the global lazy discovery setting. Values: 'lazy' or 'full'.

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

CapabilityDetails
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": true
}
resources
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
toolport_statusA

Report Toolport's status: the MCP servers enabled in the active profile, each server's tool count, and how many tokens (and dollars) lazy discovery has saved you so far.

toolport_search_toolsA

Your single gateway to every connected MCP server and ALL their tools. Try this FIRST for ANY external action or data the user asks for - sending or listing email, deployments, payments, databases, repos, issues, files, web search, etc. Do NOT reach for an unrelated tool or tell the user a capability is unavailable until you have searched here; if the service is connected, its tool is here. Returns matching tools with their exact name, description, and input schema; call one with toolport_call_tool. Once a result matches what you need, call it - do NOT keep searching for a better one (the first result includes its full schema and is ready to call). Pass server (a name/prefix like "resend") to scope to one server, and pass an EMPTY query with server to list ALL of that server's tools. If the result says more tools matched than were shown, narrow with server or raise limit before concluding a capability is missing - many servers expose a generic API bridge (a single write/create tool), so search by capability, not just an exact operation name. toolport_status lists every server prefix and its tool count. Large input schemas may be omitted from broad results (flagged schemaOmitted) to keep responses small - search a tool's exact name to get its full schema.

toolport_call_toolA

Invoke a tool discovered via toolport_search_tools. Pass the tool's exact name (as returned by the search) and put ALL of that tool's parameters INSIDE the arguments object (matching its input schema) - not at the top level next to name. Never invent or guess an identifier (teamId, accountId, projectId, etc.): if a required value isn't known, first call a list or get tool on the SAME server to obtain it, then call this with the real value.

toolport_fetch_resultA

Read more of a large tool result that Toolport truncated. When a result is too big for context, Toolport returns the head plus a cursor in a [Toolport shaped this result] marker; call this with that cursor and the offset shown in the marker to page through the rest. Nothing was lost.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct role: status reports server state, search_tools discovers tools, call_tool invokes them, and fetch_result pages through truncated results. There is no meaningful overlap between any two tools.

Naming Consistency4/5

All tools share the consistent toolport_ prefix and most follow a verb_noun pattern (search_tools, call_tool, fetch_result). toolport_status is slightly less consistent because it uses a noun without an explicit action verb, but the pattern remains predictable.

Tool Count5/5

Four tools is a well-scoped size for a gateway/meta-server: discovery, invocation, result pagination, and status reporting each earn their place. The set is neither bloated nor thin for its purpose.

Completeness5/5

The tool set covers the full lifecycle of using a unified MCP gateway: finding tools, invoking them, retrieving large results, and checking server status. There are no obvious dead ends or missing operations for the stated purpose.

Maintenance

ActivityActive
ResponsivenessResponsive