DOS AI

Never let the bot answer these numbers

dosai_add_never_bot_numbers

Add phone numbers where the bot must never reply (teachers, managers, staff), up to 100 per call, 500 per project. Works for numbers that have not written yet. The bot is switched off right away in their existing WhatsApp dialogs, the same way as the off button in the cabinet: nothing wakes it there (no auto-resume, no balance top-up, no ad campaign). Their messages are still saved and reach your webhook. WhatsApp groups are not affected. Numbers in international format, digits only is fine: 77011234567. 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_add_never_bot_numbers"
  }
}

Input Schema

Name	Required	Description
`note`	No	Who these people are, in the owner's words, e.g. "педагоги". Shown in the list.
`phones`	Yes	Phone numbers with country code, e.g. ["77011234567", "+7 702 765 43 21"].
`project_id`	Yes	Project id, as returned by dosai_list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations only give generic hints (readOnlyHint=false, destructiveHint=false); the description goes much further, disclosing that the bot is switched off immediately in existing dialogs, that nothing re-enables it (no auto-resume, balance top-up, or ad campaign), and that inbound messages are still saved and delivered to the webhook. It also states quota limits and the required role, which annotations cannot 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?

Purpose is front-loaded in the first sentence, and the remaining sentences each carry distinct information (limits, behavior, groups, format, role). The parenthetical asides are efficient, though the paragraph is dense enough that a small amount of structure could improve scanability.

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 mutating tool with no output schema, the description covers effect, scope, limits, and permissions thoroughly. The one remaining gap is what the call returns and how duplicates are handled (idempotentHint=false is not explained), which matters for an agent retrying or batching adds.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value on the phones parameter: international format, digits-only accepted, and a worked example (77011234567) plus the 100-per-call cap. The note parameter is left entirely to the schema, which is acceptable given its own description.

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?

The opening sentence names a precise verb and resource: 'Add phone numbers where the bot must never reply', scoped to teachers/managers/staff. It is unmistakably distinct from the sibling dosai_list_never_bot_numbers and dosai_remove_never_bot_numbers, and adds concrete scale limits (100 per call, 500 per project).

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 clarifies an important edge case for when this applies ('Works for numbers that have not written yet') and a clear exclusion ('WhatsApp groups are not affected'), plus a prerequisite ('Requires editor role'). It does not explicitly point to the remove/list siblings, but the when-to-use context is clear.

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?