Xenition

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

Annotations already declare the mutation/non-idempotent/safe-write profile, and the description adds genuinely new context beyond them: the side effect that it returns the upcoming schedule, and the limitation that it cannot send invitations. It does not cover edge behaviors such as duplicate handling, timezone assumptions, or required calendar setup, keeping it short of a 5.

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?

Three tight sentences, front-loaded with the usage trigger, followed by the return behavior and then the exclusions. No filler and every clause carries routing or behavioral information.

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 values need not be spelled out, and annotations carry the safety profile; the description still covers purpose, routing, and key limits. Minor gaps remain around date/time semantics and what happens on duplicate or conflicting events.

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 coverage is 60%, and the description only reinforces that a start time is needed ('with a start time') without adding format or semantics. The undocumented 'notes' and 'location' fields are left unexplained in both schema and description, so the description does not compensate for the coverage gap.

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 specific verb and resource ('put a new event on their Xenition calendar') and enumerates the concrete event types (meeting, call, deadline, reminder). It explicitly distinguishes itself from reschedule_event, so an agent can route without opening either schema.

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 the trigger condition ('when the user wants to put a new event...'), an explicit exclusion ('Do not use to change an existing event'), the named alternative (reschedule_event), and a hard capability limit (no invitations). This is the full when/when-not/alternative triad.

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

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

Annotations already declare the full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description's marginal burden is low. It still adds real context beyond the annotations: the capability boundary that Xenition has no payment or messaging channel, which prevents an agent from attempting a send. It does not address duplicate-entry behavior on repeat calls, though idempotentHint=false already signals 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?

Two sentences, zero waste. The positive trigger and the field summary come first, and the exclusion is placed last where it functions as a guard rather than burying the primary purpose.

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 mutation tool with full annotation coverage, a rich schema and an output schema, the description supplies what structured data cannot: the use trigger and the capability boundary. The only unaddressed point is duplicate handling on repeated calls, which is a minor omission given idempotentHint=false.

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 86%, so the schema already documents kind, amount, vendor, dueDate, currency, markPaid and invoiceNumber. The description's 'optionally already paid' is a useful gloss on markPaid, but it adds no syntax, format, or default details beyond what the schema states. Baseline 3 is appropriate when the schema carries the load.

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 specific verb (record) plus the resource (invoice/bill/receipt in the Xenition ledger) and enumerates the key fields (vendor, amount, due date, paid state). It also explicitly carves out the adjacent-but-different operations (pay, send, email), which lets an agent separate this from siblings like mark_paid without opening either schema.

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 trigger is explicit ('Use this when the user wants to record an invoice, bill or receipt'), and it adds a genuine exclusion ('Do not use to pay, send or email an invoice'). What it lacks is a named alternative — mark_paid and query_ledger are never referenced by name, so the routing is implied rather than spelled out.

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

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

Annotations already declare the full safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description need not restate it. It adds that the call returns the saved note and that tags/notebook are optional, but says nothing about permissions, duplicate-content behavior, or whether the note is immediately searchable.

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?

Three tight sentences, front-loaded with the use case and alternative routing. 'Returns the saved note' is mildly redundant given an output schema exists, but it costs little and does not bloat the definition.

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 simple four-parameter, one-required creation tool with an output schema, the description covers purpose, trigger, and the key alternative. The remaining gap is behavioral detail around tags/notebook semantics rather than anything that would block a correct 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?

Schema description coverage is 50%: title and content are documented, but tags and notebook have no schema descriptions. The description only flags that tags and notebook are 'optional', without explaining tag format, whether tags are created on the fly, or whether notebook must already exist. Baseline 3 for a half-documented schema 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?

States a specific verb+resource ('save something as a note'), enumerates concrete content types (idea, snippet, meeting jottings), and explicitly distinguishes itself from the sibling create_document for long structured pieces. An agent can route correctly without opening either schema.

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 an explicit trigger ('when the user wants to save something as a note') and names one alternative (create_document) with the condition that selects it. It does not address other note-adjacent siblings such as meeting_notes or search_notes, so the routing picture is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false and idempotentHint=false, so the safety profile is covered structurally. The description adds that it operates on an existing sheet and returns the updated sheet, but given idempotentHint=false it omits the practically important consequence that retrying appends duplicate rows. Useful but not rich disclosure beyond the annotations.

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?

Three short sentences, front-loaded with the primary use case and followed by the exclusion routing. Every sentence carries distinct information; no filler or restatement of the title.

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 an output schema present, the description need not explain return values, and the description does note that the updated sheet comes back. Use-case coverage and sibling routing are complete; the only material omission is a warning about duplicate rows on retry for a non-idempotent append.

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% and both parameters (rows, sheet) are documented in the schema, so the baseline is 3. The description adds only that the sheet must already exist and that rows are being appended; it contributes no additional format or defaulting detail beyond the schema.

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 ('append rows of data to one of their existing Xenition spreadsheets') and explicitly contrasts itself with the two nearest siblings, create_spreadsheet and query_spreadsheet. An agent can distinguish this from every other add_* sibling by the target artifact (spreadsheet rows).

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?

It gives explicit when-to-use ('user wants to append rows of data to an existing spreadsheet') plus two named when-not cases with the alternative tool to use instead. This is exactly the routing guidance an agent needs and leaves nothing to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds that the call 'Returns the updated board' and that it targets one of the user's boards, but says nothing about permissions, duplicate handling, or what happens if the named board/column doesn't exist.

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?

Two sentences, zero waste, and the usage condition is front-loaded before the sibling alternative. Nothing is repeated from the schema or annotations.

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 explaining return values is optional and the brief 'Returns the updated board' suffices. For a 6-parameter mutation tool the definition covers purpose, trigger, and the named alternative, but omits semantics for the remaining undocumented parameters, which keeps it short of complete.

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 coverage is 67%, so most parameters are documented in the schema itself. The description reinforces column and due-date behavior ('optionally in a named column with a due date') but never addresses assignToMe or the description parameter, leaving two of six fields without any added meaning.

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+resource ('add a task or card'), names the target container (Xenition boards), and distinguishes itself from create_board, which handles whole-board creation. An agent can pick this over siblings like create_board or move_task without opening a schema.

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?

It gives an explicit trigger ('Use this when the user wants to add a task or card') and names the alternative create_board with the condition that selects it. It does not mention related siblings such as move_task, complete_task, or list_tasks, so the routing guidance is good but not exhaustive.

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

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

Annotations already declare this as a non-read-only, non-idempotent write with open-world access, so the base bar is lower. The description still adds real context beyond them: storage is private, saved material later surfaces through ask_workspace and agents with sources, and only text or public web pages are accepted (PDFs/Word go through the upload path). It does not contradict the annotations, though it omits anything about limits or re-save behavior.

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 well-organized paragraph that leads with the usage condition before the mechanics and closes with exclusions, so the important routing information is front-loaded. It is dense and slightly long for three parameters, but no sentence is filler.

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 an output schema present, return values need no explanation, and the annotations carry the safety profile. The description covers triggers, format limits, exclusions, and downstream consumers (ask_workspace and agents answering with sources), leaving nothing an agent needs to invoke it correctly.

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 coverage is 100%, so the baseline is 3. The description nevertheless adds semantics the schema does not: the accepted formats are text or a public web page only, and PDFs/Word files are out of scope, which directly steers the url-vs-text choice. The text-or-url exclusivity is partly restated from the schema, so it is not a full 5.

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 names a specific verb (save/remember) and resource (material in Xenition's knowledge) and explicitly contrasts itself with the document tools and ask_workspace. An agent can tell it apart from add_note, create_document, and ask_workspace without opening any schema.

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?

It gives explicit trigger conditions ('when the user wants Xenition to remember material'), concrete examples (pasted notes, policy, article, URL), and explicit exclusions with named alternatives: do not use to create a document (document tools) or to answer a question now (ask_workspace). Nothing is left to inference.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the risk profile is largely carried by structured data. The description adds the precondition that the target must be a pending action, but says nothing about what approving actually triggers or whether it is reversible.

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 tight sentence with the action verb and target front-loaded and no filler. The parenthetical provenance hint is useful, though it duplicates wording already present in the schema.

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 values need not be explained, and annotations cover the safety profile. What remains unstated for a destructive one-param mutation is the consequence of approval and the explicit relationship to deny_action, leaving it only minimally adequate.

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?

There is a single parameter with 100% schema description coverage, and the schema already states it is "the pending action id (from list_pending_approvals)". The description adds no format, source, or validation detail beyond that, so the baseline of 3 applies.

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 specific verb ("Approve") and resource ("a pending action") and ties it to the originating tool list_pending_approvals. The approve/deny distinction from the sibling deny_action is implicit in the verb rather than called out, so it falls just short of full sibling differentiation.

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 parenthetical "(from list_pending_approvals)" implies the workflow: list pending approvals first, then approve one. But there is no explicit when-not guidance and no mention of deny_action as the alternative for rejecting the same item, leaving the choice to inference.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=false. The description adds useful behavioral detail by explaining the state-dependent return values: build phase and file count while building, the finished app when built, and live URLs once deployed. It also notes the build_app id dependency, though it does not cover polling or error states.

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 tight sentences and front-loads the usage trigger before explaining returns and the prerequisite. Every sentence contributes directly to selecting and invoking the tool, with no filler.

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 tool is simple, fully documented by schema and annotations, and has an output schema for return values. The description still supplies the key when-to-use context, the artifactId dependency, and a concise overview of state-dependent returns. Nothing essential for correct invocation is missing.

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?

The single artifactId parameter has 100% schema description coverage, including that it comes from build_app or search_artifacts. The description repeats the build_app source requirement but adds no syntax, format, or edge-case meaning beyond the schema. This matches the baseline of 3 when schema coverage is high.

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: checking the status of an app build or deploy. It distinguishes this from sibling action tools like build_app and deploy_app by describing the status-checking role and the artifactId prerequisite. An agent can tell what this tool does without opening the schema.

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?

It gives a clear trigger: 'Use this when the user asks how their app build or deploy is going, or whether it is live.' This is strong contextual guidance, but it does not explicitly state when not to use the tool or name a competing sibling to prefer instead.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavior beyond that: answers are grounded strictly in the user's content and come with cited sources, which tells the agent what to expect. No contradiction with annotations.

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?

Two tight sentences: the usage trigger and scope first, the grounding/citation behavior second, the exclusion third. Every clause earns its place and the critical routing information is front-loaded.

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?

Because an output schema exists, the description needn't explain return values, and it correctly conveys grounding, citation, and scope. It covers essentially everything an agent needs to call the tool, with only the sibling-retrieval distinction left unaddressed.

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% for the single `question` parameter, so the schema already documents it. The description's phrase "their documents, notes, files or saved knowledge" restates the same scoping the schema provides and adds no new syntax or format guidance. Baseline 3 applies.

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 specific verb (answers questions) and resource (the user's own Xenition content — documents, notes, files, saved knowledge), and explicitly scopes it against general knowledge. It does not, however, distinguish itself from sibling retrieval tools like query_document, search_notes, or search_artifacts, which overlap heavily.

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 clear when-to-use ("when the user asks a question about their own Xenition content") and explicit when-not-to-use ("Do not use for general knowledge or anything outside their workspace"). It stops short of routing to the specific alternative tools for retrieval, which is the main remaining gap for sibling selection.

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

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

Goes well beyond the annotations: it discloses the operation is asynchronous and slow ('takes a few minutes'), that it returns an id immediately, that progress is tracked via app_status, that publish is a separate step via deploy_app, and that the user can watch the build through a link. Annotations only cover safety/open-world hints; this adds the latency and workflow behavior an agent needs.

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 the trigger and scope, then packs the async workflow and the sibling exclusion into a compact set of sentences. No filler; every clause adds actionable information.

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?

Despite an async, multi-step operation, the description fully covers initiation, immediate return, progress polling, and publishing, and an output schema already exists for return shape. Nothing an agent needs to call it correctly is missing.

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% and all three parameters are documented in the schema, so the description adds little parameter-level meaning beyond echoing the 'idea' concept. Baseline 3 is appropriate when the schema carries the parameter detail.

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 specific verb+resource ('build a working web (or mobile) app') with concrete example domains, and explicitly distinguishes itself from the sibling open_app_builder. An agent can tell what this does and what it is not without reading the schema.

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 the trigger condition ('when the user wants a working app built'), names the alternative tool and the condition that selects it ('to only open the builder with an idea, use open_app_builder'), and lays out the follow-on flow (app_status, then deploy_app). Explicit when/when-not/alternatives.

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

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

Annotations cover mutation/idempotency flags. Description adds real behavioral context: copies full template, publishes to a live URL, and publishing takes a few minutes with app_status reporting links. Does not explicitly state async/polling flow or permissions, but the timing and status-pointer are meaningful beyond annotations.

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?

Two sentences, front-loaded with the trigger condition and alternative routing. No filler; every clause earns its place.

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?

Output schema exists, so return values need not be explained. Description covers trigger, effect, timing, status-check path, and the sibling alternative — complete for this tool's complexity.

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 coverage is 100%, so both parameters are documented in schema. Description references templateId source (find_app_templates) and implied name default, but adds no syntax or format detail beyond schema 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?

Specific verb+resource (copies template into workspace, publishes to live URL) with explicit prerequisite referencing find_app_templates. Clearly distinguishes from build_app by naming the alternative and the condition that selects it.

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?

States exactly when to use (user picked a template from find_app_templates and wants their own copy) and when not to (to generate from description, use build_app). Explicit alternative named.

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

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

Annotations are thin and somewhat noisy (readOnlyHint=false, idempotentHint=false on what reads as a status probe), so the description carries real weight: it enumerates the three terminal states (still generating, completed with the model, failed) and discloses that an inline preview already calls it. It does not explain polling cadence, retry behavior, or how long a job typically takes, which keeps it from a 5.

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?

Three short sentences, front-loaded with the core action, then the return states, then the calling context. No filler or restatement of the title.

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 an output schema present, the description need not detail return fields, and it still usefully summarizes the outcome states plus the prerequisite create_3d_model call. The only gap is not telling the agent which of the two identifiers to pass or what to do on a "still generating" result.

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% and both parameters already state they come "from create_3d_model," so the description adds no syntax or format detail beyond that. It also does not clarify that artifactId is the required identifier while jobId is optional, leaving the schema to do all the work.

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 specific verb+resource ("Check the status of a 3D model") and explicitly ties it to the create_3d_model job it monitors. An agent can distinguish this polling tool from create_3d_model and from other status tools like video_status without opening any schema.

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 a clear trigger ("you can also call it if the user asks whether their model is ready") and notes that the inline preview invokes it automatically, which implies the agent usually does not need to poll. It does not name the sibling alternative for other media types or state an explicit when-not, so it falls short of a 5.

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

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

Annotations already cover the safety profile (readOnly, non-destructive), so the description's real contribution is the error semantics: an unknown id reports as not found rather than still-working, which prevents an agent from polling forever. It does not describe polling cadence or what status values look like, leaving a small gap.

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?

Three short sentences, front-loaded with the usage trigger, then returns, then the edge case. Every sentence carries information an agent needs and none is wasted.

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 an output schema present, the description needn't detail return values and correctly limits itself to a summary plus the not-found edge case. It omits guidance on whether/how often to re-check a still-running job, which is the only material gap for a status-polling 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?

Only one parameter exists and schema coverage is 100%, with the schema itself stating 'the job id returned by run_agent'. The description's reference to a run 'started by run_agent' duplicates rather than extends that, so the baseline 3 applies.

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 specific verb (check) and resource (a background agent run), ties it to the originating sibling run_agent, and enumerates what comes back (status, final answer, view link). An agent can distinguish this from get_mission or list_missions without opening a schema.

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 an explicit trigger: use when the user asks whether the run is done or what it found, and names run_agent as the prerequisite. No explicit when-not or alternative tool is offered, so it stops short of full routing guidance.

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

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

Annotations already declare destructiveHint=true and non-idempotent, so the safety profile is covered. The description adds real value beyond that: it names the target state (done column), discloses the return value (updated board), and specifies the ambiguity-handling policy of asking the user first, which is behavioral guidance not present in annotations.

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?

Two tight sentences with zero filler; the trigger condition is front-loaded and the edge-case handling follows. Every clause carries information an agent needs.

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 the description needn't explain return values (though it does briefly). For a destructive mutation tool with annotations covering safety, the description covers when to invoke, the state change, and the ambiguous-match policy; only the board parameter's semantics remain unaddressed.

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 coverage is 50%: title is documented in the schema as 'matched by title', and the description reinforces that matching is by name. The board parameter has no description in either place, though 'the board's done column' implies board scoping. This is the baseline-3 situation where the schema does most of the work.

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 specific verb and resource ('Moves it to the board's done column and returns the updated board'), which is far more than a restatement of the name. It does not explicitly differentiate itself from the sibling move_task, which handles arbitrary column moves, so an agent must infer the distinction from 'done column'.

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 an explicit triggering condition ('when the user says a specific task is done and names it') plus fallback behavior when several or no tasks match. It does not name the alternative tool (move_task) for cases where the destination isn't 'done', so the routing guidance is clear but not exhaustive.

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

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

Goes well beyond the annotations by disclosing the async contract ('starts generation and returns immediately'), render timing (~30-60s, longer for 'realistic'), an inline preview that fills in progressively, and a follow-up link for open/edit/export. None of this is available from the readOnly/destructive/openWorld hints, and it materially changes how an agent should sequence the call.

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-loaded with the core action and scoped well; every sentence carries information. The second sentence is somewhat dense, packing async behavior, timing, preview, and export link into one clause chain, but nothing is truly wasteful.

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 an output schema present, return values need not be described, and the description covers purpose, async lifecycle, timing, and usage context. It could be slightly more complete by noting whether/how to poll via the sibling check_3d_model, but overall it is sufficient to invoke correctly.

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%, so the schema already documents prompt, imageUrl, quality, and title with examples. The description only restates the prompt/imageUrl relationship ('from a text prompt or a reference image') and the 'single object' guidance, adding little over structured fields, so the baseline of 3 applies.

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 specific verb and resource ('Generate a 3D model (glTF/GLB)') from a text prompt or reference image, and names output formats (GLB/STL/OBJ). This clearly distinguishes it from sibling media tools like create_image, create_video, or create_diagram without needing to open the schema.

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?

Provides explicit when-to-use triggers ('when the user asks for a 3D model, mesh, or asset') and a scoping hint ('Best for a single object'). It gives clear context but stops short of naming alternatives or exclusions, e.g. when 2D output (create_image) would be preferred.

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

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

Annotations declare a non-destructive write, but the description adds real runtime behavior the annotations cannot convey: the automation runs unattended even when nobody is in the chat, results surface in Xenition, and connected-app actions are gated behind user approval.

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 the trigger condition, then the effect, then the exclusion — three sentences with no wasted wording. The example is embedded efficiently rather than listed separately.

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 an output schema present, return values need not be described. For an 8-parameter creation tool the description still covers the essential who/when/where and the approval-safety model, so an agent has enough to call it correctly.

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% and each field is documented inline, so the schema carries the parameter semantics. The description only implies scheduling inputs indirectly through its example ('every Monday at 9'), adding little beyond the structured fields, making the baseline 3 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?

States a specific verb ('Creates a Xenition automation') with a clear resource and scope (scheduled, recurring). It also distinguishes itself from the sibling run_agent without the agent needing to open a schema.

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?

Opens with an explicit trigger condition ('when the user wants something done on a schedule') and includes a concrete example. It also names the exclusion and the alternative: 'Do not use for a one-off task now (use run_agent).'

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

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

Annotations already declare the safety profile (write, non-idempotent, non-destructive, closed-world), so the lower bar applies. The description adds the artifact structure (columns and task cards) and the fact that it returns a management link, but says nothing about permissions, limits, or how the brief is interpreted — modest added value over the annotations.

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?

Three short sentences with no filler; the usage trigger is front-loaded, the return note is brief, and the sibling routing comes last. Every sentence carries information an agent needs.

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 two-parameter creation tool with full schema coverage and an output schema that already describes the returned board and link, the description is nearly complete — purpose, trigger, and alternative all present. The only gap is the near-total silence on behavioral constraints, which the annotations largely cover.

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%, so both parameters are already documented and the baseline of 3 applies. The example ('a board to plan our product launch') illustrates the kind of brief expected, but adds no detail about format or length beyond the schema's own 'topic, brief, or outline'.

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 specific verb (create/build) and a well-defined resource — a Kanban board with columns and task cards built from a brief — and gives a concrete example. It explicitly distinguishes itself from add_task, so an agent can route without opening either schema.

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?

Begins with an explicit trigger ('Use this when the user wants a new Kanban board... built from a brief') and resolves the most likely confusion with a named alternative ('To add a single task to an existing board, use add_task'). The when-to-use condition and the when-not condition are both stated.

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

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

Annotations already declare this is a non-readonly, non-idempotent, non-destructive write, so the safety profile is covered. The description adds that it returns the diagram plus a link to open and edit it in Xenition, which is useful context but largely restates what an existing output schema already conveys. No mention of permissions, quotas, or overwrite behavior.

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?

Two tight sentences with the usage trigger front-loaded and the concrete diagram types packed into the first clause. Every sentence earns its place, with no filler.

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 annotations covering the safety profile and an output schema present, the description needs only to establish purpose, trigger, and return shape — all of which it does. It stops short of noting sibling alternatives or constraints, but nothing essential for correct invocation is missing.

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%, so both 'brief' and 'title' are already documented in the schema. The phrase 'created from a description' loosely maps to the brief parameter but adds no format, length, or syntax guidance beyond the schema. Baseline 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?

States a specific verb (create) and resource (diagram), and enumerates the concrete diagram kinds it covers — flowchart, sequence, architecture, ER, mind map. That enumeration distinguishes it cleanly from siblings like create_image, create_slides, or create_board.

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 opening 'Use this when the user wants a diagram... created from a description' gives a clear positive trigger. It does not name excluded cases or point to alternative sibling tools, but for a creation tool the trigger condition is unambiguous.

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

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

Annotations already declare this as a non-readonly, non-idempotent, non-destructive, closed-world write. The description adds that it returns the document plus a link for opening/editing. It does not warn that repeated calls create separate artifacts (relevant given idempotentHint=false), but the annotation set carries the safety profile, so 3 is appropriate.

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?

Two sentences, zero padding, front-loading the usage trigger before the sibling routing. Every clause earns its place.

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 annotations, a full output schema, and 100% parameter coverage, the description only needs to supply the trigger, the alternative routing, and a return summary — all present. Minor gap: no note on what the 'brief' argument should contain at minimum or whether repeated invocations duplicate the artifact.

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% with both parameters documented ('brief' and optional 'title'), so the schema does the heavy lifting. The description adds no syntax, format, or length guidance for 'brief' beyond what the schema states; baseline 3 applies.

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 specific verb and resource ('create a document') scoped to the user's Xenition workspace, and immediately differentiates from the two nearest siblings (create_slides, find_forms). An agent can tell what this produces without opening any schema.

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 an explicit trigger ('when the user asks for a written piece — a report, article, letter, brief, essay or plan') and routes excluded cases to alternatives: create_slides for slides, find_forms for fill-in templates. When-not and alternatives are both covered.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the result is persisted to the user's Xenition library and a link is returned. It stops short of mentioning cost, rate limits, or generation latency, which would be the remaining useful disclosure for an open-world generative call.

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?

Two sentences, zero filler. The trigger condition is front-loaded, the side effect and return value follow, and the disambiguation to edit_image closes it out.

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 values need no elaboration, yet the description still flags that a link comes back. Combined with the annotations covering the safety profile and a 100%-covered schema, an agent has everything needed to select and invoke this tool correctly.

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%, so prompt, title and reference are all already documented with examples in the schema. The description only alludes to the prompt ('made from a description') and says nothing about title or the reference-image parameter. Baseline 3 applies when the schema carries the parameter burden.

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 specific verb+resource ('an image made from a description') and enumerates the concrete outputs an agent might be asked for (illustration, photo-style picture, logo idea, background). It also explicitly names the sibling it is not, edit_image, so the boundary is unambiguous.

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 an explicit trigger ('when the user wants an image made from a description') and an explicit alternative with its own condition ('To change an existing image, use edit_image'). The agent does not need to infer which of the two image tools to call.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the form is public-link accessible, responses collect in Xenition, and the tool returns the shareable link. It stops short of warning that repeated calls create separate forms (idempotency behavior).

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?

Three tight sentences with the core capability front-loaded, followed by use cases and the return value. No filler; every clause adds information.

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 creation tool with an output schema, full parameter coverage, and clear annotations, the description supplies everything an agent needs: what is created, who can access it, where responses go, and what is returned. No gaps remain.

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%, so the schema already documents title, fields (including field type enum values), and collectEmail. The description adds no parameter-level detail beyond what the schema provides, which is the expected baseline when the schema does the heavy lifting.

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 specific verb+resource (create a fillable form with a public link) and distinguishes it from siblings like find_forms, form_responses, and submit_form by describing the authoring action. The 'like a Google Form' analogy and example use cases make the capability unambiguous.

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 says 'Use when the user wants to gather input from other people' and lists concrete scenarios (surveys, sign-ups, feedback, RSVPs). It does not name the alternative siblings (e.g., find_forms for locating existing forms), so the routing is clear but not exhaustive.

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

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

Annotations already declare this is a non-read-only, non-idempotent write with no destruction or open-world access. The description adds useful context beyond that: the deck is persisted in the user's workspace, and the result is the slides as an inline preview plus an editable link. It doesn't mention permission or rate-limit considerations, keeping it below a 5.

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?

Three tight sentences with no filler, and the core action is front-loaded before the return behavior and the usage trigger. Every sentence carries distinct information.

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?

Covers what the tool does, where the artifact lands, what comes back (preview + edit link), and when to invoke it. With an output schema present it needn't enumerate return fields, and nothing essential for correct invocation is missing.

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%, so both parameters are fully documented in the schema. The description only echoes 'from a brief or topic' and never clarifies the optional title behavior beyond what the schema already states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb (Create) and resource (a polished, designed presentation deck) plus the scope (the user's Xenition workspace). It clearly separates this from sibling creators like create_diagram, create_document, create_spreadsheet, and create_video by naming the concrete artifact type.

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 gives trigger conditions: 'Use when the user asks for slides, a deck, a presentation, or a pitch deck.' This tells the agent exactly when to reach for this tool. It stops short of naming when NOT to use it or pointing to alternatives (e.g., create_diagram) for adjacent requests.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the mutation profile is known. The description adds genuinely useful context beyond that: the return artifact is an MP3 link and the audio is persisted to the user's library, making the side effect explicit. It doesn't note that repeat calls yield new assets despite non-idempotency, which would have earned a 5.

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?

Two sentences, zero filler: the first front-loads the triggering condition, the second the output and persistence behavior. Nothing redundant with the title, which it does not merely restate.

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 detail is not required, and annotations cover the safety/mutation profile. The description completes the picture with triggering context and the library-save side effect. Only the undocumented 'title' parameter and any voice/language caveats remain unaddressed, a minor gap.

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 coverage is 75% (text, voice, language documented; title undocumented), and the description contributes no parameter meaning at all — no voice selection, language behavior, or title usage. With the schema doing most of the work, the baseline 3 applies.

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 concrete verb+resource outcome ('text read aloud as an audio file', 'Returns an MP3 link'), which clearly distinguishes it from image/video/slides siblings. It stops short of naming or contrasting with the closest sibling, transcribe_audio (the inverse operation), so it doesn't reach the sibling-differentiation bar of a 5.

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?

'Use this when the user wants text read aloud as an audio file — a voiceover, narration or spoken message' gives an explicit, concrete triggering context with exemplar use cases. It offers no when-not guidance or named alternative (e.g. transcribe_audio for the reverse), so it is clear but not exhaustive.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write scoped to the workspace (openWorldHint=false). The description adds the workspace scope and return content, but nothing beyond structured data about permissions, duplicate creation on repeat calls, or limits. With annotations covering the safety profile, this is adequate but not rich.

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?

Three short sentences, front-loaded with the primary trigger and closed with the sibling redirect. Every sentence carries a distinct piece of information with no filler.

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 the description need not detail return values, and annotations cover the safety profile. The description supplies the trigger, scope, and the key routing decision, leaving nothing an agent needs missing.

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%, so both parameters are already documented by the schema. The description hints at content type via its examples and mentions 'formulas where useful', but adds no format or syntax detail beyond what the schema provides. Baseline 3 applies.

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 specific verb (create) and resource (spreadsheet / data table) with concrete examples (budget, tracker, schedule, list). It also names the sibling it is not, add_rows, so an agent can distinguish it without opening another schema.

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 an explicit trigger ('when the user wants a new spreadsheet or data table') and an explicit alternative plus condition ('To add rows to an existing sheet, use add_rows'). Both the when-to-use and when-to-use-something-else cases are covered.

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

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

Annotations only declare the generic write/open-world/idempotent profile; the description adds the genuinely important behavioral facts: the call is asynchronous and returns an id immediately, generation takes minutes, video_status is the readiness signal with the file link, and the artifact persists in the user's Xenition library. That is exactly the async/latency/persistence context annotations cannot convey.

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?

Three sentences, front-loaded with the trigger condition, then the async contract, then persistence. No redundancy and every sentence carries distinct information.

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 detail is unnecessary; the description still supplies what matters for correct invocation — immediate return of the id, the multi-minute latency expectation, and the status-check path. Nothing an agent needs to call this correctly is missing.

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 coverage is 75%, with prompt, aspect and duration already documented in the schema, so the description's "made from a description" adds little syntax or format meaning. The undocumented title parameter is not clarified either, leaving the baseline 3 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?

States a specific verb (create) plus resource (short AI video clip) and scopes it to generation from a text description, which implicitly separates it from edit_video and from video_status. The mention of video_status as the follow-up step lets an agent place this tool in the workflow without opening sibling schemas.

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?

"Use this when the user wants a short AI video clip made from a description" gives a clear triggering condition, and the second sentence tells the agent to poll video_status afterwards. It stops short of an explicit contrast with edit_video (editing an existing clip) or guidance about prompt quality, so it is clear context rather than full when/when-not coverage.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds the useful precondition that only actions awaiting a decision can be denied, but says nothing about reversibility or what happens to the action after denial.

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?

A single sentence with zero filler, front-loading the verb and resource before the parenthetical source hint. Nothing is padded or redundant.

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 and annotations fully cover the destructive/non-idempotent profile, so the description need not explain returns or safety. It is nearly complete, with only the missing alternative-tool guidance as a small gap for a destructive one-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 description coverage is 100% with a single well-documented id parameter, so the schema carries the meaning. The description only restates the id's provenance, which the schema already specifies, adding no new syntax or format guidance.

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 specific verb ('Deny') and resource ('a pending action'), plus the precondition state ('awaiting the user's decision') and the source tool that produces the id. This cleanly distinguishes it from the antonym sibling approve_action without the agent needing to open either schema.

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?

It implies when to use the tool by tying it to list_pending_approvals, which tells the agent where the id comes from. However, it never names approve_action as the alternative or states the conditions under which denying is appropriate versus approving, leaving the routing to inference.

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

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

Annotations cover the safety profile (not read-only, open-world, not idempotent, not destructive), and the description adds substantial context beyond them: the call returns immediately while deployment takes minutes, app_status is where live URLs appear, and publishing exposes the app to anyone with the link. That is exactly the kind of non-obvious behavioral detail annotations cannot convey.

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?

Three sentences, front-loaded with the trigger condition, then prerequisite, then async/visibility caveat. Every sentence carries distinct, load-bearing information with no filler.

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, and the description helpfully points to app_status for the resulting live URLs rather than duplicating return values. Prerequisites, async behavior, and visibility implications are all covered, leaving no material gap for correct 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?

There is a single parameter with 100% schema description coverage, which already states artifactId comes from build_app or search_artifacts. The description adds no format or syntax detail 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?

States a specific verb (published/deploys) and resource (built Xenition app) with a concrete outcome (live URL). It is clearly distinguishable from siblings like publish_artifact, build_app, and app_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 states when to use it ('when the user wants their built app published'), the prerequisite (build_app must have finished — check app_status), and a when-not/guardrail ('only do it when the user asks'). Nothing is left to inference.

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

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

Annotations already declare readOnly, openWorld and destructive=false, so the safety profile is covered. The description adds genuinely new behavior: sources are read live at query time (which explains and reinforces idempotentHint=false), the returned field set (`phone`, `website`, `lat`/`lng`, `detail`), and a hard input requirement that place types need `near`.

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?

Purpose and the `near` requirement are front-loaded, and most sentences carry operational instructions that affect call correctness. It is on the long side, with the last two sentences (don't re-search, state absent fields) restating the same 'use what you got' idea twice, and the all-caps emphasis is heavier than needed.

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 an open-world search tool with an output schema present, the description covers the important gaps: live-vs-cached semantics, required location for place types, and how to report results. It omits result limits/pagination behavior and any relationship to the similarly-named `discover_sources` sibling.

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 coverage is 100%, so the schema already documents each parameter and the baseline is 3. The description adds real cross-parameter semantics the schema cannot express — that place-type values require `near`, and that lat/lng should be used instead of guessing a place name for 'near me'. The `type` value list largely duplicates the schema description.

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 specific verb and resource — 'look up real, current information from open public sources' — plus an explicit enumeration of the catalogues it covers (jobs, hospitals, banks, schools, etc.), which is far beyond a restatement of the name. It does not, however, differentiate itself from the sibling `discover_sources`, whose name is close enough that an agent could confuse the two.

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 concrete usage constraints: place types REQUIRE `near`, results must be attributed with sources and timing, and details already returned should not be re-searched. It lacks any explicit routing to an alternative tool (e.g. `discover_sources` or `find_tools`), so the agent gets context but not exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety and open-world profile is covered. The description adds the licensing/source-attribution angle, which is useful context, but it doesn't describe output shape or any other behavioral traits beyond what annotations provide. With annotations doing most of the work, a 3 is appropriate.

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?

Two tight sentences: the first defines the behavior, the second gives the usage trigger. No filler, front-loaded with the core action.

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 tool is simple (one required param, output schema present), and the description covers what the tool does and when to call it. Since an output schema exists, it need not explain return values. Minor gap: no explicit mention of the discover_search sibling relationship.

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%, so the single parameter ('type', described as 'which catalogue') is already documented in the schema. The description mentions 'a data type' which loosely maps to the parameter but adds no syntax, format, or enumeration detail. Baseline 3 when the schema carries the load.

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 action: it reveals which public sources underlie a Discover answer and under what licence. That is a clear verb+resource. It doesn't explicitly differentiate itself from the closest sibling, discover_search, but the focus on sourcing/licensing is distinct enough.

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?

It gives clear usage context: 'Use when the user asks how we know something, or whether the information can be trusted.' That is a solid when-to-use condition, though it does not state when-not-to-use or name discover_search as the alternative.

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

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

Annotations already flag destructiveHint=true and idempotentHint=false; the description goes further by explaining that affected files are rewritten, a new version is saved, and changes are not published until deploy_app is called again. It does not cover recoverability of prior versions or permission requirements, so it stops short of fully fleshing out a destructive mutation.

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?

Three tight sentences, front-loaded with the trigger condition, then side effects, then prerequisites. Every sentence carries information an agent needs and there is no filler.

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 two-parameter mutating tool with an output schema present, the description covers the trigger, the write behavior, the versioning side effect, the deploy coupling, and the build-state precondition. Nothing essential to correct invocation is missing.

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%, with both parameters documented and example instructions given in the schema itself. The description restates that the change is expressed "in plain words" but adds no syntax, format, or constraint beyond that, so the baseline 3 applies.

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 specific verb (change/edit) and resource (an app built in Xenition), with concrete change categories (feature, screen, restyle, fix). It does not explicitly differentiate itself from the nearby edit_artifact sibling, so an agent must infer that this is the app-specific path.

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?

"Use this when the user wants to change an app they built" gives clear triggering context, and the closing sentence adds a precondition (app must have finished building; check app_status). No explicit when-not or named alternative (e.g. edit_artifact) is given.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, so the mutation profile is covered. The description adds genuinely new context: the edit produces a saved new version and returns it, which clarifies the effect on the original beyond what the hints say. It stops short of describing rate limits, permissions, or what happens to the prior version.

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-loaded trigger sentence, then a compact enumeration of edit types, then the versioning fact and the alternative tool. No filler sentences; every clause earns its place.

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 format need not be explained, and the description still notes that a new version is returned. With annotations covering safety and the schema covering params, the definition gives everything needed to select and call this tool correctly.

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% with only two params (artifactId, instruction), and the schema already gives usage examples for both. The description adds no parameter-level detail, so the baseline 3 applies — the schema carries the load.

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 specific verb and resource ('edit a saved Xenition item') and enumerates the concrete operations covered (rewrite, shorten, expand, tone, grammar, translate). It also names the sibling it is not (review_artifact), so an agent can separate them without opening a schema.

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?

Opens with an explicit trigger ('when the user wants one of their existing items changed in place') and closes with an explicit exclusion plus alternative ('To only suggest changes without editing, use review_artifact'). Both when-to-use and when-not-to-use are given.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds real behavioral context beyond them: the result is saved as a new image in the Xenition library and the original is retained. It does not mention prompt requirements per operation or async/latency behavior.

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?

Two tight sentences, front-loaded with the trigger condition and followed by the side effect. No filler and no repetition of the schema.

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 mutation tool with an output schema, the description covers the key facts an agent needs: when to use it, what operations exist, and that the original is preserved. Minor gaps remain around which operations require a prompt and any processing latency.

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 coverage is 75%, so the schema already documents image, prompt and operation. The description still adds value by mapping user intent ('upscale', 'remove the background', 'make a variation') onto the operation values, helping the agent pick the right operation string. It says nothing about the undocumented 'title' parameter.

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 concrete verb and resource ('edit an existing image') and then enumerates the supported operations, which cleanly separates it from create_image (new images) and edit_video (video). An agent can route here without opening any schema.

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 opening clause gives an explicit trigger: 'when the user wants an existing image changed', which implicitly excludes generation of new images. It never names a sibling alternative (e.g. create_image) or states exclusions explicitly, so it stops short of a 5.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the bar is lower, yet the description adds genuinely useful behavior: it is asynchronous ('starts the edit and returns an id right away'), the original is preserved, and output lands in the Xenition library. It does not mention cost, rate limits, or failure modes.

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?

Three tight sentences: trigger first, then async behavior and polling target, then the non-destructive guarantee. No filler and every clause carries information.

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 mutating, open-world tool with an output schema present, the description covers everything an agent needs: when to call it, that it returns an id immediately, how to learn when the result is ready, and that the source video survives. Return-value detail is rightly left to the output schema.

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 coverage is 75%, so the schema carries most of the load, but the description restates the operation vocabulary in user-intent terms (captions, enhance, matte, jumpcut), which helps map a natural-language request onto the enum-less operation string. It adds nothing for title or language beyond the schema.

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 opens with a precise trigger and resource ('an existing video improved') and enumerates the four concrete capabilities: burned-in captions, enhanced picture/sound, background removal, and jumpcut silence removal. That set of operations cleanly distinguishes it from create_video (new video) and edit_image (still image) among the siblings.

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?

It gives an explicit when-to-use condition ('when the user wants an existing video improved') and routes the agent to video_status for readiness checking. It stops short of an explicit exclusion ('do not use for new videos – use create_video'), which is the only gap.

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

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

Annotations carry the safety profile (destructiveHint=false, idempotentHint=false, readOnlyHint=false), and the description adds the artifact-type scope and the fact that a link is returned. It does not explain that the call produces a new PDF artifact (implied by readOnlyHint=false) or whether re-exporting regenerates content, which is the main behavioral question for this tool.

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?

Two tight sentences: purpose and trigger first, returned value second, scope exclusion last. No filler and nothing buried.

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, and the description still flags the return ('a link to the PDF'), plus the supported artifact types. For a single-parameter export tool, an agent has everything needed to call it correctly.

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?

Only one parameter, and schema description coverage is 100% — the schema already tells the agent artifactId comes from search_artifacts or create_document. The description adds no syntax or format detail beyond that, so the baseline 3 applies.

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?

Specific verb ('export') plus resource and format ('one of their Xenition documents as a PDF file'), with the output named ('a link to the PDF'). This separates it cleanly from create_document, get_artifact and extract_from_artifact without opening any schema.

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?

Explicit triggering context ('when the user wants ... to download, print or attach') and an explicit scope exclusion ('for slides, sheets or notes, open them in Xenition to export'). When-to-use and when-not-to-use are both stated.

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

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

Annotations already declare that this is read-only, non-destructive, and not open-world, so the safety profile is covered structurally. The description adds meaningful behavioral context beyond that: it answers only from the referenced document (scoping/grounding) and returns a list. It does not discuss limits, rate limits, or handling of ambiguous requests, so it falls short of a 5.

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?

Three compact sentences, front-loaded with the primary use case and ending with the sibling redirect. No filler, no repetition of title or annotations.

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 annotations covering safety profile, an output schema covering return structure, and full schema descriptions for both parameters, the description only needs to state purpose, usage, and grounding scope — all of which it does. Nothing an agent needs to invoke it correctly is missing.

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 coverage is 100% and both parameters already carry precise descriptions, so the schema does the heavy lifting. The description adds a bit of flavor by listing extractable kinds (names, dates, figures, action items), but it does not embellish parameter syntax or format beyond what the schema provides. Baseline 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 states a specific verb ('extract') and resource ('one of their Xenition documents'), and it enumerates concrete extraction types (names, dates, figures, action items, tasks). It also explicitly distinguishes itself from the sibling query_document by contrasting list-style extraction with free questions.

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?

It gives an explicit usage condition ('when the user wants a specific kind of information pulled out ... as a list') and names the exact alternative for the other case ('To ask a free question about it, use query_document'). This is a textbook when-to-use/when-to-use-sibling routing rule.

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

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

Annotations already cover the safety profile (readOnly, non-destructive). The description adds valuable context the annotations do not: catalog size (~200 templates), content of each template (web app, API, database, live demo), and that results include demo links. It does not mention result capping beyond the schema's limit parameter, but the added operational context is strong.

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?

Two sentences, front-loaded with the usage trigger, followed by the catalog description and the handoff instruction. No filler.

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?

Complete for a read-only search tool with an output schema already present. The description supplies the catalog context and the critical follow-up call (build_app_from_template with a template id), which is exactly what an agent needs to complete the workflow.

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 coverage is 100%, so the schema already documents query, limit, and category with examples. The description restates the query concept with examples that mirror the schema, adding little beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb (find) and resource (app templates) and enumerates concrete example domains (dance school, restaurant, clinic, store, CRM). This clearly distinguishes it from the sibling search_marketplace and find_forms by naming the exact catalog and scope.

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?

Opens with an explicit when-to-use trigger ('when the user wants a ready-made app for a kind of business') and closes by routing to the follow-up tool build_app_from_template with the required argument. The alternative/next step is named with the condition that selects it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds real behavioral value beyond that: it explains the result is a set of matching forms 'with their fields, shown as a fillable form the user can complete right here to generate a document' — disclosing the output shape and the follow-on interaction. It does not mention pagination or limit behavior, keeping it from a 5.

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 purpose is front-loaded in the first clause and each clause carries information (library, examples, return format, when-to-use). It is slightly verbose with three sequential purposes, but nothing is wasted 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 an output schema present, return values need not be re-explained, and annotations carry the safety profile. The description covers purpose, examples, output format, and invocation context; only the limit/pagination behavior is unaddressed, which the schema handles.

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%, so both query and limit are already documented in the schema, and the query examples in the description duplicate what the schema already provides. The description adds no syntax or format detail beyond structured data, so the baseline 3 applies.

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 specific verb ('Search') and resource ('library of ready-made forms') with concrete examples, and the title confirms it is a document generator finder. An agent can distinguish it from create_document, create_shared_form, and submit_form without opening any schema.

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?

'Use when the user wants to create a specific kind of document or fill out a form' gives clear positive context for invocation. It does not name an alternative (e.g., blank create_document) or state when-not-to-use, so it falls short of the explicit routing that a 5 requires.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond that: results are ordered newest first, each entry carries answers plus a timestamp, and the call is restricted to forms the user owns (an authorization/ownership constraint not present in the schema).

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 triggering condition is front-loaded in the first sentence, followed by argument shape, return behavior, and the ownership constraint. No sentence is redundant and none could be dropped without losing routing or behavioral information.

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, yet the description still briefly characterizes the return (newest first, answers and time), which is more than required. Combined with the ownership restriction and the pointer to its sibling, an agent has everything needed to select and call this tool correctly.

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% for the single 'form' parameter, so the baseline is 3. The description adds meaning the schema does not: the parameter must be a form the user owns, and it restates the acceptable value shape (link or token) in user-facing terms.

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 names a specific verb and resource (read responses submitted to a shareable form) and grounds it in concrete examples — sign-ups, survey answers, RSVPs, feedback. It also explicitly links the tool to the sibling that creates the resource (create_shared_form), so an agent can place it in a workflow without opening the schema.

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?

It gives a clear triggering condition ("Use this when the user wants to see what people submitted…") and names the originating sibling, create_shared_form. It stops short of naming an alternative or exclusion other than the ownership constraint, so it is strong but not a full when/when-not routing rule.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond them: it returns content, and very long items are truncated to the first part, with query_document/summarize_artifact as the workaround. It does not mention any auth/permission requirement, which is the only remaining gap.

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?

Three sentences, each load-bearing: eligibility, return behavior plus truncation escape hatch, and the negative routing. The triggering condition is front-loaded and nothing is repeated from the structured fields.

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 values need not be spelled out, and the description still flags the truncation caveat. Combined with a fully documented single parameter and full annotation coverage, an agent has everything needed to call this correctly.

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?

Only one parameter and schema description coverage is 100%, so the baseline is 3; the description adds value by stating the provenance of the id (from search_artifacts or an earlier result), which helps the agent know when it is even eligible to call the tool.

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 specific verb+resource (open/read one specific artifact by id) and enumerates the artifact kinds covered. It also explicitly contrasts itself with search_artifacts, query_document and summarize_artifact, so an agent can pick it out of a large sibling list without reading the schema.

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 when to use it (user wants to read/open one specific item and you already have the id), where the id comes from (search_artifacts or an earlier result), and an explicit 'Do not use to find items' exclusion routing to search_artifacts. Alternatives for oversized content are named too.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description's only added behavioral content is 'Returns its status and results', which is redundant with the existing output schema. It adds no information about latency, mission lifecycle states, or what happens for an unknown/incomplete id.

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?

Three short sentences, zero filler. The usage condition is front-loaded, the return summary follows, and the alternative-tool routing is last — a clean information hierarchy.

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 single-parameter, read-only lookup with an output schema, the description covers trigger, scope, and alternative routing. Return values are already specified by the output schema, so no further disclosure is needed for correct 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?

Schema description coverage is 100% and there is only one parameter, whose schema text ('the mission id (from list_missions)') already documents format and provenance. The description's 'by id' adds nothing beyond the schema, so the baseline 3 applies.

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 specific verb and resource ('get one specific Xenition mission by id') and even defines the term ('a long-running multi-agent job'), which resolves the ambiguity between the title 'Get an agent run' and the name get_mission. It also names the sibling it is not (list_missions), so an agent can route without opening either schema.

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 states the triggering condition ('when the user asks about one specific mission by id') and names the alternative tool plus the condition that selects it ('To see all missions, use list_missions'). Both when-to-use and when-not-to-use are covered.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavior beyond that: the artifact becomes an editable document that summarize_artifact, query_document, ask_workspace and edit_artifact can operate on, and it names the supported formats. It does not warn that repeated calls are non-idempotent (duplicate documents), which is the one behavioral gap.

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 trigger condition is front-loaded, followed by parameter mechanics, then the sibling redirect — a sensible order. The prose is dense with em-dashes and clauses but nearly every clause carries information (trigger, encoding choice, MIME type, downstream consumers, formats, alternative), so little is wasted.

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 an output schema present, return values need not be described, and the description still covers the trigger, the parameter encoding choice, the MIME type requirement, supported formats, downstream tool compatibility, and the sibling alternative. For a 4-parameter tool with one required field, nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3; the description earns above that by mapping content types to parameters — UTF-8 text via textContent, other content base64-encoded via base64Content — and by naming which formats fall in each bucket (text, Markdown, CSV, JSON, HTML vs. PDF). That is real guidance the schema only partially conveys through per-field hints.

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 ('bring a file's content into their Xenition workspace') and immediately clarifies the outcome ('saves it as an editable document'). It also distinguishes itself from the closest sibling by explicitly routing web-page imports to add_to_knowledge, so an agent can separate import_file from that alternative without reading either schema.

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?

It gives an explicit trigger ('when the user wants to bring a file's content into their workspace — e.g. they attached or pasted a document') and an explicit alternative with its condition ('To bring in a page from the web instead, use add_to_knowledge with its URL'). The when-to-use, when-to-use-something-else, and the format-selection rule are all stated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's remaining burden is light. Its only added behavioral content is the return shape (name and what it does), which the existing output schema already documents, so it adds little beyond structured data.

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?

Two sentences, zero filler, with the primary use case (user asks about their agents) front-loaded ahead of the secondary run_agent prerequisite case.

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 no-parameter, read-only list tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what it lists, when to call it, and the sibling it pairs with.

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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no filtering or selection arguments are required.

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 specific verb (list) and resource (agents), and defines the domain term inline as 'Xenition agents (named AI workers)' so an agent unfamiliar with the product still knows what is being listed. It also distinguishes itself from the run_agent sibling by name.

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 two explicit, concrete triggers: when the user asks what agents they have, and before calling run_agent to pick the right one. The second trigger doubles as routing guidance against the closest alternative tool.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the returned fields (schedule, on/off state, last run, id), giving the agent a sense of the payload without opening the output schema.

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?

Two sentences, no filler. The usage trigger is front-loaded and the return summary follows immediately, so every clause earns its place.

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 zero-parameter, read-only list tool with a full output schema, the description is complete: it says when to call it and roughly what comes back. The only marginal gap is the absence of any note about ordering or volume (e.g., pagination) for a list 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?

This tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate. Schema coverage is 100% and the schema is an empty object with additionalProperties false, so no parameter gaps remain.

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 specific verb and resource ('list automations') and enumerates what the user-facing intent looks like ('what automations they have, when they run, or whether one is paused'), which cleanly separates it from create_automation and set_automation_enabled. It stops short of explicitly naming those siblings, so it lands just under the top mark.

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 concrete trigger conditions tied to user questions (asking what automations exist, their run times, or paused state). That is clear context for when to reach for this tool, but it offers no exclusions or explicit alternative-routing (e.g., 'use set_automation_enabled to toggle'), so it is not a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered; the description adds value by explicitly ruling out side effects (cannot connect new apps or act in them), which prevents the agent from over-anticipating capabilities. It adds a little beyond annotations without going very deep.

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?

Two sentences, zero waste, with the usage trigger front-loaded before the capability caveat. Every clause earns its place.

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 zero parameters, a full output schema covering return values, and annotations covering the safety profile, the description provides everything an agent needs to select and call the tool correctly. Nothing material is missing.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. No parameter-level guidance is needed or expected.

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 names a specific verb and resource ('list connected apps') and scopes it to third-party apps connected to the Xenition account, with concrete examples (Gmail, Slack, Notion). It stops short of differentiating itself from ambiguous siblings such as app_status or find_tools, so it is clear but not fully disambiguating.

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?

It gives an explicit trigger ('Use this when the user asks which third-party apps are connected') and an explicit negative constraint ('it cannot connect new apps or act in them'), steering the agent away from misuse. Both the when-to-use and when-not are stated outright.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only 'Returns the events with times and links', which duplicate what the existing output schema already conveys, and says nothing about ordering, paging, or the idempotentHint=false implication.

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?

Two sentences, zero filler, with the usage trigger front-loaded and the sibling routing placed last where it matters. Every clause earns its place.

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 single optional-parameter, read-only list tool, the description supplies the trigger, the scope of results, and the disambiguation to the alternative; return values are already covered by the output schema and safety by annotations. Nothing an agent needs to invoke it correctly is missing.

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% and the single parameter is fully documented in the schema ('today | week | month | a YYYY-MM-DD date; default upcoming'). The description's list of ranges restates the same options without adding format or default semantics beyond the schema, so the baseline 3 applies.

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 specific verb and resource (list calendar events) plus the accepted range scope, and explicitly names the sibling it is not ('For a combined view ... use my_agenda'). An agent can distinguish it from my_agenda, reschedule_event and add_event without opening any schema.

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 an explicit trigger ('Use this when the user asks what is on their Xenition calendar for a range — today, this week, a date, or upcoming') and routes the combined-view case to the named alternative my_agenda. Both when-to-use and when-not-to-use are stated.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds that each mission is returned with its status and id, but since an output schema exists this is largely restated structured data, and it says nothing about ordering, limits, or how 'how they are going' is quantified.

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?

Two sentences, the invocation trigger front-loaded, followed immediately by the return shape and chaining hint. No filler or 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?

With zero parameters, full annotation coverage of the safety profile, and an output schema handling return values, there is nothing further an agent needs. Return contents and the get_mission hand-off are stated explicitly.

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?

The input schema is an empty object with zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies for a no-parameter tool.

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 specific verb (list) and resource, and even disambiguates the domain term: 'missions (long-running multi-agent jobs)'. It routes to get_mission for detail, but doesn't explicitly distinguish itself from near-neighbours such as list_agents, check_agent_run, or list_automations.

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?

'Use this when the user asks what missions they have in Xenition and how they are going' gives a concrete invocation trigger, and naming get_mission supplies the natural follow-up. No when-not guidance or exclusions are offered, so it stops short of a 5.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds meaningful context beyond that: these are pending approvals blocking assistant/agent progress, and the ids are actionable handles rather than opaque references. It does not mention ordering, pagination, or empty-state behavior.

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?

Two sentences, zero waste, with the purpose front-loaded and the actionable follow-up second. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.