Disable all tools within a named profile to deactivate its capabilities. The core profile stays locked, so read paths and profile loading remain available.
Disable every tool in profile name. core is locked
on -- unloading it would strip the read paths and the
load_profile tool itself.
Args: name: profile name to disable.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | profile name to disable. |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only destructiveHint=false in annotations, the description carries most of the disclosure burden and delivers: it explains the side effect (disabling all tools in the profile) and the core-locked constraint with its rationale. It does not state reversibility or whether the profile config is deleted, which is the main remaining gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, followed by a useful caveat; the Args restatement of the single param is redundant but small. Overall tight and well-ordered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description covers the action, the excluded case, and the rationale. For a one-parameter mutation tool it is nearly complete, though reversibility/return behavior is left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, so the schema already documents 'name'. The description's Args block merely repeats 'profile name to disable', adding no format or constraint detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (disable) and resource (every tool in a named profile), so the agent knows exactly what the tool does. It does not explicitly contrast with load_profile/list_profiles siblings, but the semantics are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear when-not rule: 'core' is locked on and cannot be unloaded because it would strip read paths and load_profile. It doesn't name an explicit alternative, but the exclusion plus the inverse sibling make the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.