DOS AI

Remove numbers from the never-bot list

dosai_remove_never_bot_numbers

Take phone numbers off the never-bot list. This does NOT switch the bot back on in their existing dialogs: it stays off until someone turns it on (toggle_bot_in_conversation or the button in the cabinet). But a number that has no dialog yet will get bot replies from its first message. Two steps, like every removal: the first call returns what will happen and a confirm_token. Requires editor role.

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": {
      "project_id": "<project_id>",
      "phones": "<phones>"
    },
    "name": "dosai_remove_never_bot_numbers"
  }
}

Input Schema

Name	Required	Description
`phones`	Yes	Phone numbers to remove, same format as when adding.
`project_id`	Yes	Project id, as returned by dosai_list_projects.
`confirm_token`	No	Leave empty on the first call: it changes nothing and returns what will happen and a code. Ask the owner; only after their explicit "yes" call again with the same arguments and this code.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the real consequences: existing dialogs keep the bot off until someone turns it on, but numbers with no dialog will get bot replies from the first message, and the caller must hold the editor role. It also explains the dry-run first call and the confirmation gate, which the destructiveHint=false annotation alone would not convey.

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

Conciseness4/5

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

Short, front-loaded sentences: consequence first, then the two-step mechanics, then the role prerequisite. The two-step explanation partly duplicates the confirm_token schema description, which is the only redundancy.

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

Completeness5/5

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

For a 3-parameter mutation with no output schema, the description covers everything an agent needs: the effect on existing dialogs, the effect on new numbers, the confirmation flow, and the required role. Nothing material is left to guesswork.

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 documents phones, project_id and confirm_token, including the leave-empty-on-first-call rule. The description restates the two-step confirmation behavior but adds no format or constraint detail about the parameters themselves, so baseline 3 applies.

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?

"Take phone numbers off the never-bot list" gives a specific verb plus resource, and the description immediately contrasts the effect with the sibling toggle_bot_in_conversation. An agent can distinguish this removal from adding numbers (dosai_add_never_bot_numbers) without opening either schema.

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?

It clearly states the two-step procedure: first call changes nothing and returns a confirm_token, then the caller repeats with the same arguments and the code after an explicit "yes" from the owner. It also names the alternative for re-enabling bots (toggle_bot_in_conversation or the cabinet button). What's missing is a pointer to dosai_list_never_bot_numbers to verify membership before removing.

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

All DOS AI tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?