Skip to main content
Glama

route_set_attachments

Задаёт, что делать с вложениями маршрута по видам (фото, видео, аудио, голосовое, файл, стикер и другие): пересылать как есть, снять вложение (остальное сообщение уходит) или не пересылать сообщение с таким вложением вовсе. Вид, не названный в списке, пересылается как есть. Прежние правила вложений заменяются переданным списком; стоп-слова, замены и остальные правила остаются как есть, поэтому сначала прочитайте нынешние правила (route.show) и передайте их вместе с изменениями. Пустой список пересылает вложения всех видов.

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": {
      "routeId": "<routeId>",
      "attachments": "<attachments>"
    },
    "name": "route_set_attachments"
  }
}

Input Schema

NameRequiredDescriptionDefault
routeIdYesНомер маршрута — из списка маршрутов человека (действие routes.list).
attachmentsYesЧто делать с каждым видом вложения; не названный вид пересылается как есть. Прежние правила вложений заменяются этим списком; пустой список пересылает вложения всех видов.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

With only readOnlyHint=false and openWorldHint=false supplied, the description carries real weight: it discloses that previous attachment rules are replaced, that unnamed media kinds default to forward, that an empty list forwards everything, and that stop-words/replacements are untouched. It stops short of describing permissions or what happens on invalid media kinds, which keeps it from a 5.

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?

Front-loaded with the action and the three behaviors, then defaults, then the replacement caveat, then the empty-list edge case. It is somewhat dense in a single paragraph and repeats the replacement/empty-list facts that also appear in the schema, but no sentence is wasted.

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 two-parameter mutation tool with no output schema, the description covers the action, the enum semantics, defaults, destructive replacement scope, and the required read-before-write step. Nothing an agent needs to invoke it safely is missing.

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 cross-parameter meaning not present in the schema: the interaction between the replacement list and the other rule sets (stop-words, replacements), plus the read-then-write workflow needed before calling it.

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 description states a specific verb and resource ('Задаёт, что делать с вложениями маршрута по видам') and enumerates the three possible behaviors (forward, strip, drop), which distinguishes it plainly from sibling route_set_* tools that configure words, replacements, delays or schedules.

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

Usage Guidelines5/5

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

It explicitly tells the agent to read current rules with route.show first and to resend them along with the changes, and it states the replace-all semantics of the attachments list. The alternative (route.show) and the precondition are named directly, not implied.

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.