github_rerun_workflow_run

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

Annotations already provide readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the description does not need to restate those. It adds some useful context by noting that the operation routes only through the exact governed connector authority and that the claimed effect is verified by Spring. However, it does not disclose what destructive side effects rerunning a workflow may have or any approval/resumption behavior beyond the parameter list.

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 compact and front-loaded with the operation identity and routing constraint, followed by a terse argument list. It avoids filler and each line adds some information, though a more structured behavior sentence and richer argument guidance would improve it.

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?

An output schema exists, so return-value documentation is not required. Yet for a 7-parameter connector wrapper with 0% schema coverage, the description omits the actual shape of the `arguments` JSON, does not explain what workflow run inputs are needed, and offers no sibling differentiation or usage context. An agent would struggle to invoke this tool correctly without external knowledge of the underlying GitHub API.

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 0%, so the description must compensate for the absence of parameter documentation. It provides short labels for each wrapper parameter, e.g., idempotency_key as 'Stable business-action identity' and approval_ref as 'Approved platform task UUID when resuming a write.' However, the critical `arguments` parameter is only described as 'JSON string of arguments for the connector operation,' with no indication of what fields the GitHub rerun operation requires, leaving the agent unable to construct a valid call.

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 identifies the operation as a GitHub connector operation named `rerun_workflow_run`, which clearly implies re-running a GitHub workflow run. It is a specific verb+resource pairing, though it does not explicitly differentiate itself from siblings like `github_trigger_workflow` or `github_dispatch_workflow`.

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 gives no guidance on when to use this tool versus alternatives such as `github_dispatch_workflow`, `github_trigger_workflow`, or `github_cancel_workflow_run`. The only contextual note is the routing constraint, which is a governance detail rather than a usage criterion, so an agent cannot decide when this tool is the right choice.

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