treeflow_trigger_training

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it discloses almost nothing. It doesn't state whether training runs synchronously or asynchronously, whether the call returns immediately or blocks, what happens if a training job is already in progress, or what the caller receives in response. The existence of a get_training_status sibling strongly suggests an async polling workflow, but the description fails to mention it.

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?

The description is a single, front-loaded sentence with zero wasted words — the action verb 'Inicia' leads, followed by the resource and scope. It earns its place. However, the structure is minimal and could have compactly incorporated behavioral guidance (e.g., async behavior, status polling) without bloat.

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?

For a trigger/mutation tool with no annotations and no output schema, the description must explain what happens after the call, but it does not. The agent is left without knowing whether to expect a job ID, whether to poll treeflow_get_training_status, or how to handle a rejection if training is already running. This is a material gap for a non-trivial operation.

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 100%: the only parameter, tree_id, is already documented in the schema as 'ID del bot/árbol a entrenar'. The description adds no additional meaning about the parameter, so the baseline 3 applies. The mention of current intents and entities is behavioral context, not parameter semantics.

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?

The description states a specific verb and resource: 'Inicia el re-entrenamiento del modelo de Machine Learning y NLU de un bot' — it clearly tells the agent this tool triggers retraining of the bot's ML/NLU model. The scope qualifier 'con las intenciones y entidades actuales' further clarifies what data is used. This distinguishes it cleanly from read-only siblings like treeflow_get_training_status and treeflow_list_training_history.

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?

The phrase 'con las intenciones y entidades actuales' implicitly suggests the right moment to call it (after intent/entity changes), but the description never names alternatives or gives explicit when-to-use vs when-not-to-use guidance. It doesn't mention, for example, that treeflow_get_training_status should be used to monitor the resulting training, which would help route the agent.

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