continue_decisionAfter poll_decision returns status changes_requested, regenerate, then call this to reopen the same decision as pending_review for the next human round.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| tenantId | Yes | ||
| decisionId | Yes | ||
| agentOutput | No | Summary of the revised output for the conversation transcript. | |
| sessionToken | No | ||
| timeoutSeconds | No | Optional new timeout for this review round. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write/non-idempotent nature is known. The description adds that the tool transitions the decision from changes_requested to pending_review, which is useful state-change context. It does not disclose additional behavioral traits beyond that.
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?
One sentence, front-loaded with the condition, and every word contributes. Excellent structure for quick scanning.
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?
The description covers the essential workflow but omits important details such as required parameters (tenantId, sessionToken), return behavior, and any error conditions. With no output schema, some of this burden falls on the description, leaving it incomplete for a 6-parameter tool.
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 descriptions cover only 33% of parameters (agentOutput and timeoutSeconds). The description implicitly identifies decisionId as 'the same decision' and hints at agentOutput through 'regenerate,' but leaves tenantId, sessionToken, and title unexplained. This doesn't fully compensate for the low schema coverage.
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?
Description states exactly what the tool does: after poll_decision returns changes_requested, it reopens the decision as pending_review. Uses specific verb 'reopen' and resource 'same decision', and distinguishes it from sibling poll_decision by referencing that tool's status.
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?
Explicitly specifies the precondition ('After poll_decision returns status changes_requested') and the required action ('regenerate, then call this'). This clearly indicates when to use the tool. However, it does not discuss alternatives or exclusions, but it's enough for the intended flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Core actions like hatch, convert, upload, and lookup are generally distinct, but the polling family (poll_approval, poll_decision, poll_pairing) is easy to confuse, and await_decision misleadingly sounds like a wait operation rather than the creation of a review. Descriptions clarify boundaries, but the names alone leave room for misselection.
Most tools use an imperative verb style, but the pattern is inconsistent: some are bare verbs (hatch, convert, deploy, list, lookup, share, upload), some are verb_noun (poll_decision, refresh_session, get_pairing_code), and auth is a bare noun. The names are readable but do not follow one predictable convention.
16 tools sits at the heavy end of the comfortable range, inflated by three polling tools plus pairing/session management that are only tangentially related to the core task of creating and updating roosts. Each tool has a purpose, but the surface feels larger than the core domain requires.
The set covers create, read/list, update via convert/upload/deploy, sharing, and auth, but there is no delete/destroy or teardown tool, and custom domain/state management is only passively visible through lookup. Agents can complete common workflows but will hit dead ends on teardown or lifecycle management.