Skip to main content
Glama

oto_disable_tool

Disable a tool for the current user — persistent across sessions.

The tool disappears from the visible list immediately (the server notifies the client via tools/list_changed). Re-enable with oto_enable_tool.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>"
    },
    "name": "oto_disable_tool"
  }
}

Input Schema

NameRequiredDescriptionDefault
_orgNo
nameYesExact tool name (e.g. `attio_create_deal`, `linkedin_unipile_search`).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does substantially well: it discloses persistence across sessions, immediate visibility change, and the tools/list_changed client notification. It omits permission requirements, reversibility confirmation beyond the pointer to oto_enable_tool, and error behavior for unknown tool names.

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?

Three short sentences, each earning its place: the action and scope first, then the immediate behavioral consequence, then the recovery path. No redundant restatement of the tool name or title.

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

Completeness4/5

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

For a simple two-parameter state toggle with no output schema, the description covers effect, persistence, and reversal. The only shortfall is the silent '_org' parameter and lack of failure-mode detail.

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?

Only the required 'name' parameter is documented in the schema (with concrete examples), while the optional '_org' parameter is undocumented in both schema and description. The phrase 'for the current user' hints at scoping but adds no real semantics for '_org', so the description does not compensate for the 50% coverage gap.

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

Purpose5/5

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

A specific verb plus resource (disable a tool) with explicit scope ('for the current user'), which cleanly separates it from the inverse sibling oto_enable_tool and from the many per-integration tools in the list.

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

Usage Guidelines4/5

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

The description makes the use case clear and names the counterpart tool ('Re-enable with oto_enable_tool'), giving a direct alternative for the opposite operation. It stops short of explicit when-not guidance such as what happens for tools the user never had access to.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources