Skip to main content
Glama

mcp_profiles

Manage named server connection profiles to switch between presets like work or personal. Create, add servers, and activate profiles for different environments.

Instructions

Manage named connection profiles. Profiles are presets of server connections that can be switched between (e.g., 'work', 'personal').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlNoServer URL (for add_server with SSE/WS/HTTP)
argsNoCommand arguments (for add_server with stdio)
nameNoProfile name (required for create, delete, add_server, remove_server, switch, show)
slugNoServer slug to add/remove from a profile
actionYesAction: list (all profiles), create (new profile), delete, add_server (add a server to profile), remove_server, switch (activate profile), show (details of a profile)
commandNoExplicit command for the server (for add_server with stdio)
descriptionNoProfile description (optional, for create)
transportTypeNoTransport type (for add_server)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.3

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It mentions that profiles can be 'switched between' but does not disclose that actions like delete, remove_server, and switch have destructive or state-changing effects, nor does it describe persistence, permissions, or side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose and one clarifying definition. There is no filler, and the example parenthetical adds useful context without bloating the description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a complex multi-action tool (8 parameters, 7 enum actions, no annotations, no output schema), yet the description only gives a high-level summary. It omits action-specific behavior, destructive-action warnings, return information, and usage differentiation, which are necessary for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already defines all 8 parameters and the action enum. The description adds no additional meaning about parameter interactions or usage beyond what the schema provides. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Manage named connection profiles.' It further clarifies with the definition 'presets of server connections' and examples ('work', 'personal'). However, it does not distinguish this tool from possibly related siblings like mcp_groups or mcp_discover, leaving the agent to infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given for when to use this tool versus alternatives, when to prefer each action (e.g., create vs add_server), or what prerequisites exist. The description only says 'manage', which is too vague to guide selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.