Equipo de trabajadores (vigilancia constante)

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

The description discloses state-changing behavior: 'asignar (darle una tarea)', 'quitar', 'pausar', 'activar', 'frecuencia', 'correr (que trabajen ya)' and 'drive (conectar Google Drive)'. Annotations declare readOnlyHint=true, which directly conflicts with these mutating actions, leaving the agent with an unreliable safety profile.

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-loads what the team is and who does what, then compresses all ten actions into one dense clause. The worker roster with emoji is long but each entry carries a distinct domain; little is pure padding.

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?

With 14 parameters, 10 action branches and no output schema, the description covers intent, the workers' domains, action names and a fallback relationship to ml_vigilar. It stops short of mapping which parameters belong to which action and never says what 'informe'/'resultados' actually return, leaving some gaps for a tool this broad.

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 description coverage is 93%, so nearly every parameter is already documented (trabajador aliases, umbral per worker, cuenta, carpeta). The description mostly restates this at a high level ('frecuencia (minutos)', 'drive (conectar Google Drive)') and adds the alias convention already present in the schema, so it contributes little beyond baseline.

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 concrete resource (a 5-agent monitoring team) and names each worker with the domain it watches (Vera=precios, Tomás=ventas, Martina=ranking, Bruno=rivales, Sofía=tendencias). It then enumerates the full action set verb by verb (equipo, asignar, quitar, pausar, activar, frecuencia, correr, informe, resultados, drive), so an agent immediately knows the tool's surface area.

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?

Gives per-action context ('correr = que trabajen ya', 'informe = alertas nuevas') and a routing rule against a sibling: if a worker has no own tasks it watches your ml_vigilar follows of its type. It never states when NOT to use this versus alternatives like ml_vigilar, ml_novedades_competencia or ml_tendencias directly, so a competing-usage decision is left partly implicit.

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