test_trigger

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

The description explicitly warns that this tool executes the agent for real and is not a dry-run, which is essential behavioral context beyond the annotations. It also discloses that the execution uses a temporary session, giving the agent a clearer picture of side effects and scope. This is consistent with readOnlyHint=false, idempotentHint=false, and destructiveHint=false.

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 three sentences long, front-loaded with the core action, followed by the use case and the critical non-dry-run warning. Every sentence contributes essential information without redundancy.

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?

Given no output schema, the description covers the main invocation context: the payload, the executed agent, and the temporary session. It could be slightly more complete by describing the shape of the returned result, but the combination of schema detail and the warning makes it sufficient for correct selection and invocation.

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?

Parameter documentation is already complete in the schema (100% coverage), including trigger_id as the UUID and test_payload with webhook/schedule examples. The description adds little parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb and resource: it 'testa um trigger' by sending an example payload, executes the linked agent, and returns the result. This clearly separates it from sibling tools like test_connection or test_mcp_server, which do not execute a linked agent. The purpose is immediately actionable.

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 description states a clear use case: verifying whether webhook, schedule, or email triggers are configured correctly. It does not explicitly name alternatives or say when not to use this tool, but the context is specific enough for an agent to select it appropriately.

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