Xenition

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

Annotations already declare readOnlyHint=false and idempotentHint=false, so the write/non-idempotent profile is covered. The description adds genuine behavioral context beyond that: no invitation delivery, and that the call returns the upcoming schedule. It stops short of stating permissions or duplicate-handling 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?

A single dense sentence with three clauses, each earning its place: scope, exclusion, limitation. The use condition is front-loaded ahead of the negative guidance.

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 'Returns the upcoming schedule' phrase is redundant but harmless, and annotations cover the safety profile. What an agent needs to call this correctly is present; only ambiguity in the undocumented notes/location params keeps it from a 5.

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 60% and the description adds only minor hints (an event needs a 'start time'). The start/end format details live in the schema, and notes/location are undocumented in both places, so the description does not compensate for the coverage gap. Baseline 3.

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 ('put a new event on their Xenition calendar') and enumerates the concrete event kinds it covers (meeting, call, deadline, reminder). It also names the sibling it is not, reschedule_event, so 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?

Explicit when-to-use ('when the user wants to put a new event...'), explicit when-not ('Do not use to change an existing event'), and it names the alternative tool (reschedule_event). It also states a hard limitation (cannot send invitations), leaving 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 the write/non-destructive/non-idempotent profile, so the bar is lower. The description still adds real context: the ledger has no payment or messaging channel (scope boundary) and that the call returns the ledger's invoices. It does not mention duplicate-entry risk despite idempotentHint=false, which is the one notable omission.

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 trigger is front-loaded before the return note and the exclusions. Nothing is repeated from the title or 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?

With annotations covering the safety profile, an output schema covering returns, and 86% schema description coverage, the description only needs to establish purpose, trigger and scope boundary — all of which it does. 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 86%, so the schema already documents all seven parameters including kind, currency defaults and date format. The description only echoes vendor, amount, due date and the optional paid flag, adding no syntax or format detail beyond the schema — the baseline 3 for high coverage 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+resource ('record an invoice, bill or receipt in their Xenition ledger') with the key fields named (vendor, amount, due date, paid state). It is clearly distinguishable from ledger siblings such as query_ledger and mark_paid, which the 'do not use to pay' clause implicitly separates it from.

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 trigger ('use this when the user wants to record an invoice...') plus explicit exclusions ('Do not use to pay, send or email an invoice'). It stops short of naming the alternative tool (mark_paid) that should be used instead, leaving that 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 already declare the safety profile (readOnlyHint=false write, destructiveHint=false, idempotentHint=false), so the bar is lower. The description adds that it returns the saved note and that tags/notebook are optional, but discloses nothing about permissions, side effects, or how notes are stored. 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?

Two sentences with zero waste: the use case is front-loaded, then the alternative 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?

An output schema exists so return values need no explanation, and annotations carry the safety profile. The description supplies the trigger, the scope (idea/snippet/jottings), and the sibling routing, which is everything an agent needs to call this simple create 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 50% (only title and content are documented). The description says 'optional tags and notebook', which confirms optionality for the two undocumented parameters, but that is largely implied by the required list and it adds no detail on tag format or how a notebook is chosen. Thin compensation 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 ('save something as a note'), enumerates the content kinds (idea, snippet, meeting jottings), and explicitly names the sibling it is not (create_document) for long structured pieces. An agent can distinguish it from add_to_knowledge, meeting_notes, and search_notes without opening 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?

Gives an explicit trigger ('Use this when the user wants to save something as a note') plus a named alternative and the condition that selects it ('For a long structured piece, use create_document instead'). This is the when/when-not/alternative pattern done fully.

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 (not read-only, not destructive, not idempotent). The description adds that it targets an existing sheet and returns the updated sheet, but does not disclose the non-idempotent append semantics, duplicate handling, or value-type constraints that would help an agent predict behavior. Adequate but modest value over 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 with zero filler; the usage condition is front-loaded and the exclusions follow immediately. 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 simple two-parameter append tool with an output schema already covering return values, the description supplies the routing information (when and when-not) an agent needs. Nothing essential 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 (rows, sheet) are fully documented in the schema itself. The description only loosely gestures at the 'existing spreadsheet' target and adds no syntax or format detail 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 (append rows of data to an existing Xenition spreadsheet) and explicitly distinguishes itself from create_spreadsheet and query_spreadsheet. An agent can identify the tool's job 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?

Gives an explicit when-to-use condition ('when the user wants to append rows of data to one of their existing spreadsheets') plus two named exclusions with the alternative tool for each case. 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 readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the agent knows this is a local, non-idempotent write. The description adds only 'Returns the updated board', which is mildly useful output context, but says nothing about required board permissions 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 tight sentences with the trigger condition and scope front-loaded, followed immediately by the sibling escape hatch. No filler or redundant 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, return values need not be explained, and annotations carry the safety profile. The remaining gap is the two undocumented parameters (assignToMe, description), which the description never mentions; otherwise the definition 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 coverage is 67%, and the description echoes optionality for column and due ('optionally in a named column with a due date'), which the schema already documents with defaults. It adds nothing for assignToMe or the description parameter, which remain undocumented in both places, so it 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 (add) and resource (task/card) scoped to Xenition boards, and explicitly names create_board as the tool for a different outcome. An agent can distinguish this from add_note, add_event, and create_board 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 wants to add a task or card to one of their Xenition boards') and routes the new-board case to create_board. It does not cover when-not-to-use (e.g., versus move_task or list_tasks), but the context is clear enough to act on.

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, non-idempotent write, and the description adds real context beyond that: the material is saved privately, and downstream asks (ask_workspace and agents) answer from it with sources. It does not address duplicate saves or what the stored item looks like, but the privacy and downstream-consumption behavior is valuable disclosure the annotations do not carry.

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 phrase, then the behavioral payoff, then the content limits and exclusions. Every sentence earns its place and the routing instructions are last, where they are easy to find.

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 covers return values, so the description needn't explain them. For a 3-optional-parameter write tool it supplies the trigger, the content boundaries, the privacy/downstream behavior, and the sibling routing — 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?

Schema coverage is 100%, so the schema already documents url, text and title. The description restates the mutual exclusivity ('Give text OR url, not both') rather than adding new format constraints or syntax detail. Baseline 3 applies 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?

"Use this when the user wants Xenition to remember material so it can answer from it later" states a specific action and the exact resource (pasted notes, policies, articles, web links). It distinguishes itself from add_note, create_document and ask_workspace by naming the ones it must not be confused with.

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 positive case ('user wants Xenition to remember material'), explicit content constraints ('Text or a web page only; PDFs and Word files are uploaded in Xenition'), and explicit exclusions that route to named alternatives ('Do not use to create a document (use the document tools) or to answer a question now (use 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, readOnlyHint=false and openWorldHint=true, so the agent knows this is an irreversible, non-idempotent write. The description adds nothing beyond that: it does not say what approving actually triggers, whether the decision can be reversed, or what the side effects are on the underlying action.

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 tight sentence with the action front-loaded and the identifier provenance appended efficiently. There is no filler, though it is arguably too terse for a destructive operation.

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 the annotations cover the safety profile. Still, for a destructive, non-idempotent approval the description should convey more about consequences or follow-up (e.g. that the action proceeds immediately), which is left entirely to the annotations.

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 'id' parameter is fully documented in the schema, so the baseline is 3. The description only repeats the provenance of the id, adding no format or constraint detail beyond what the schema already provides.

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 ('Approve a pending action') and scopes it to items 'awaiting the user's decision', which cleanly separates it from the deny_action sibling and from list_pending_approvals. It stops short of explicitly naming deny_action as the counterpart, so it is clear but not maximally differentiated.

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 correct workflow — list first, then approve an item from that list — which is useful context. However, there is no explicit when-to-use guidance, no statement of what to do instead if the user wants to reject (deny_action), and no preconditions such as required permissions.

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 goes beyond them by disclosing the progressive return states (build phase + file count, finished app, live URLs), which tells the agent what to expect at each stage.

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 earning its place, with the trigger front-loaded before the return-value summary and the parameter note. No redundant 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 has an output schema, so detailed return-value documentation isn't required, yet the description still summarizes the staged outputs. Combined with annotations covering the safety profile and a fully-documented single parameter, nothing needed 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% for the single artifactId parameter, so the schema already documents it fully. The description adds only minor reinforcement that the id comes from build_app, which the schema also states. 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+resource (check an app build/deploy status) and distinguishes it from siblings like build_app and deploy_app by scoping it to polling progress and liveness. An agent can tell what it does and when it applies 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 concrete trigger ('when the user asks how their app build or deploy is going, or whether it is live') and notes the id comes from build_app. It doesn't explicitly name alternatives (e.g., video_status for videos or deploy_app to initiate a deploy), 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description is free to add behavioral context — and it does: answers are restricted to workspace content only, and responses cite sources. That grounding constraint and citation guarantee are real information an agent cannot infer from the annotations, though retrieval/pagination behavior is left unstated (the output schema covers the return shape).

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 trigger condition, followed by scope and then the exclusion. Every sentence carries a distinct instruction and none restates the tool name or 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 single-parameter retrieval tool with full schema coverage, complete annotations, and an output schema handling return values, the description covers the essentials: what it answers from, how it cites, and what it refuses. The only gap is explicit disambiguation from the other content-querying siblings.

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 required parameter at 100% schema description coverage, so the schema already documents "question" fully. The description reinforces that the question must concern the user's own content, which slightly narrows intended input, but adds no syntax, length, or format guidance beyond the schema — 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 specific verb and resource — answering a question from the user's own Xenition documents, notes, files and saved knowledge — with the added qualifier that answers are grounded and cited. It clearly separates itself from general-knowledge answering, but it never names the adjacent siblings (query_document, search_notes, discover_search) that an agent might otherwise pick, so sibling differentiation is implicit rather than explicit.

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 a question about their own Xenition content" gives a clear positive trigger, and "Do not use for general knowledge or anything outside their workspace" gives an explicit negative condition. What is missing is routing among alternatives — nothing tells the agent when to prefer this over query_document or search_notes for the same content.

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 this is a non-read-only, non-destructive, non-idempotent write. The description adds behavior annotations cannot convey: the operation is asynchronous and takes minutes, it returns an id immediately rather than the finished app, progress is checked via app_status, and the user can watch the build via a link. That is exactly the async/lifecycle context 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?

Four sentences, each carrying distinct load: trigger, scope of generation, async lifecycle, and the sibling routing rule. Front-loaded with the use case before the mechanics.

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 return-value shape need not be described, and the description instead supplies the workflow the agent must orchestrate (id now, poll via app_status, then deploy_app). For a multi-step async build tool this is 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 description coverage is 100%, so the schema already documents idea, name, and mobile fully. The description mentions mobile implicitly ('web (or mobile) app') but adds no format, constraint, or interaction detail beyond the schema. 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 concrete verb and resource ('Generates the full app (screens, API and database)') and gives examples of what counts (booking site, CRM, internal tool). It also distinguishes itself from the similarly named create_app and build_app_from_template siblings by naming the alternative explicitly.

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 names the trigger ('when the user wants a working web (or mobile) app built for them'), the exclusion ('To only open the builder with an idea, use create_app'), and the follow-up path (app_status then deploy_app). 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 cover safety (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true), so the burden is lower. The description adds real context beyond them: publishing is asynchronous and 'takes a few minutes,' and app_status reports the resulting links, telling the agent how to close the loop.

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 tightly written sentences: trigger first, behavior second, alternative last. Every sentence carries distinct information with no 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?

An output schema exists, so return values need not be explained, yet the description helpfully points to app_status for the publish links. Between description, annotations and schema, 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?

Schema description coverage is 100%, so both parameters are already documented, including the default behavior of name and the template id example. The description reinforces the templateId source (find_app_templates) but adds no syntax or format detail beyond the schema, so 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+resource: copies a chosen template into the user's Xenition workspace and publishes it to a live URL. It also explicitly distinguishes itself from build_app, so an agent can differentiate it from siblings 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 (the user picks a template from find_app_templates) and names the alternative with its own condition (build_app generates from a description). 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?

The description usefully enumerates the three terminal states (generating / completed with the model / failed) and discloses that the preview polls it automatically, which is real context beyond the schema. However, the annotations declare readOnlyHint=false and idempotentHint=false for what reads as a pure status poll, and the description does not reconcile that or state polling/rate expectations, so the behavioral picture stays incomplete.

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 purpose and state outcomes before the auto-invocation note. No filler, no 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 spell out return payloads, and it covers purpose, outcomes, and invocation triggers adequately. The remaining gap is the required-vs-optional identifier choice, which neither the description nor the schema explains.

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 params (jobId, artifactId) are already documented as coming from create_3d_model, which the description merely echoes. It adds nothing about why artifactId is required while jobId is optional or when each identifier should be supplied, so 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 gives a specific verb+resource ("Check the status of a 3D model") and anchors it to the sibling that creates it (create_3d_model), which cleanly separates it from create_3d_model and from the analogous video_status sibling.

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 states clear usage context: the inline preview calls it automatically, and the agent should call it when the user asks whether their model is ready. It does not name a when-not condition or an alternative status tool (e.g. video_status for videos), so it stops short of the top score.

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 safety is covered. The description adds non-obvious behavioral detail beyond them: it discloses that an unknown id is reported as 'not found' rather than 'still working', which prevents a polling loop. It stops short of rate/polling guidance, so 4 rather than 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 primary use case, followed by return shape and then the edge-case rule. Every sentence earns its place with no repetition.

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 in the description; the description still covers purpose, trigger, and the ambiguous-id edge case. 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% and the single missionId param is fully documented in the schema as 'the job id returned by run_agent'. The description adds no syntax or format details beyond it, so the 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+resource ('check a background agent run') and anchors it to the sibling that creates it ('started by run_agent'), so an agent can distinguish it from run_agent 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 explicit trigger conditions ('when the user asks whether it is done or what it found') and names the related tool run_agent that starts the run, leaving 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 destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the destination (done column) and the return value (updated board). It does not address repeat invocation, which matters given idempotentHint=false, or any permission requirements.

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 trigger condition front-loaded, then the effect, then the disambiguation rule. Nothing is redundant and every sentence 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?

The output schema means return values need no explanation, and annotations carry the mutation/destructive profile, so the description only needs trigger and effect – both present. The remaining hole is the undocumented 'board' parameter, which leaves an agent unsure how to scope the operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: 'title' is documented in the schema (matched by title), while 'board' has no description anywhere. The description weakly implies the board context ("the board's done column") but never explains which board is used, whether it is required, or how it defaults when omitted. Partial compensation only.

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 the specific verb and resource (complete a task), names the target state (the board's done column), and describes the return value (the updated board). An agent can distinguish this from siblings like move_task, add_task, and list_tasks 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 trigger condition ("when the user says a specific task is done and names it") plus an explicit when-not rule ("if several tasks match or none is named, ask which one first"). This is exactly the when/when-not guidance the dimension asks for.

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 (readOnly=false, destructive=false, non-idempotent), and the description adds genuinely new behavior: it returns immediately, rendering takes ~30-60s (longer for 'realistic'), a preview fills in inline, and a link allows open/edit/export. It does not mention rate limits, cost, or how to poll status, which keeps 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?

Front-loaded with the core action and output format, followed by async behavior, then usage guidance — a sensible ordering with no filler. It is dense at four clauses in the second sentence, but each clause carries distinct information (latency, preview, edit link, export formats).

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 async generation tool with a full output schema and annotations, the description covers the essentials an agent needs: input modes, latency expectations, the deferred preview, and downstream edit/export options. The only omission is how the agent should later check on the render, which the sibling check_3d_model presumably 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 the schema already documents all four parameters, including the draft/realistic quality modes and the imageUrl image-to-3D path. The description restates the prompt/image duality and adds only the rough timing for 'realistic', 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+resource ('Generate a 3D model (glTF/GLB)'), names the destination workspace, and enumerates both input modes (text prompt or reference image). This clearly separates it from siblings like create_image, create_video, and create_diagram without needing to name them.

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 asks for a 3D model, mesh, or asset' gives explicit triggering context, and 'Best for a single object' sets a scoping limit. However, it never names an alternative (e.g. create_image for 2D, or check_3d_model for polling status), so the routing guidance is contextual rather than exclusionary.

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 agent knows this has no mutating side effects. The description adds that the result is a link ('Returns the link'), but with an output schema present this is largely redundant and it discloses nothing further about auth, session state, or limits.

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 tightly written sentences with the primary use case front-loaded and the alternative routed second. Every sentence earns its place and nothing is padded.

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 tool with a complete schema, an output schema (covering return values), and annotations covering the safety profile, the description supplies the remaining decision-relevant context: the intent and the sibling route. 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%, so the schema fully documents idea, name, and mobile, including examples. The description only hints at 'pre-filled with their idea' and adds no format or syntax guidance 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: opening Xenition's no-code app builder pre-filled with the user's idea so they can shape it by hand. It explicitly distinguishes itself from build_app, so an agent can tell the two apart 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 open ... the builder themselves') and names the alternative with its own condition ('to have the app built for them ... use build_app instead'). The routing decision is fully determined.

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 non-readonly, non-destructive, non-idempotent and closed-world. The description adds genuinely new behavior: autonomous execution without a user in the chat, results surfacing in Xenition, and approval gating before anything acts in a connected app. It does not cover what happens on repeated scheduling conflicts or how the automation is later modified, which is minor.

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 use case, then the concrete example, then behavioral facts, then the exclusion — a sensible order. It is one dense paragraph and slightly long, but each sentence carries distinct information; nothing is 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, the description need not explain return values, and it instead covers what an agent actually needs: the scheduling intent, autonomous execution, approval gating, and the run_agent alternative. Nothing material is missing 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%, so the schema already documents all eight parameters including the frequency/time/days/every breakdown. The description reinforces the scheduling vocabulary ('every day, on certain weekdays, or every few hours') and gives a natural-language example, but adds no format or constraint detail beyond the schema. Baseline 3 is correct.

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 ('Creates a Xenition automation') plus the defining scope ('runs on its own at those times, even when nobody is in this chat'). It also explicitly contrasts itself with run_agent, so an agent can route between the two 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 the triggering condition with concrete examples ('every Monday at 9, summarise my sales sheet') and an explicit exclusion with the alternative named ('Do not use for a one-off task now (use run_agent)'). 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, covering the safety profile. The description adds that content is generated from a brief and that a management link is returned, but says nothing about permissions, cost, or what happens when the brief is ambiguous. Useful but modest value 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?

Two sentences, front-loaded with the usage condition, then the routing exclusion. No filler or restated boilerplate.

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 safety; the trigger and the sibling routing are present. It could still say more about what a good brief looks like, but nothing required 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 are already documented in the schema, so baseline 3 applies. The description only implies that 'brief' drives the generated content and adds no format or length guidance beyond the schema's '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+resource+scope: creating a new Kanban board with columns and task cards from a brief. It explicitly distinguishes itself from the sibling 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?

Gives an explicit trigger condition ('when the user wants a new Kanban board') plus a concrete example utterance, and names the alternative (add_task) with the condition that selects it ('to add a single task to an existing board').

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. The description adds one piece of context beyond the structured fields: the call yields a persistent artifact plus an edit link in Xenition. It does not explain that a new artifact is produced per call despite idempotentHint=false, which would have earned a higher score.

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, and the trigger condition is front-loaded ahead of the output note. Every clause carries information an agent can act on.

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 only two parameters at full schema coverage, an output schema present, and clear annotations, the description is sufficient to invoke the tool correctly. The remaining gap is minor: no guidance on how rich the brief should be or what happens to previously created diagrams.

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 both parameters, so 'brief' and 'title' are already fully documented in the schema. The description's phrase 'created from a description' only loosely gestures at the brief parameter and adds no format, length, or content 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 and resource ('diagram ... created from a description') and enumerates the sub-types it covers (flowchart, sequence, architecture, ER, mind map), which separates it from generic artifact creators like create_document or create_image. It stops short of explicitly naming a sibling it replaces, so it lands just below 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?

The opening clause 'Use this when the user wants a diagram ... created from a description' is an explicit usage trigger, and the enumeration of diagram kinds further narrows the case. There is no when-not guidance or named alternative (e.g., whether to prefer create_document for prose or create_slides for decks).

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 write/side-effect profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the safety burden is partly lifted. The description adds value by stating the return ('the document and a link to open and edit it'), though it omits that repeated calls are non-idempotent (duplicates) and says nothing about permissions or workspace scoping.

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 earning its place: the trigger first, then the return value, then sibling disambiguation. The enumeration of artifact types is compact and directly aids selection rather than 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?

For a two-parameter creation tool with an output schema and full annotations, this is complete — the output schema carries return structure, annotations carry safety, and the description covers the trigger, the outcome, and the sibling routing. 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%, so both `brief` and `title` are already documented, and the description does not add syntax or format guidance beyond what the schema provides. The mention of 'topic, brief, or outline' loosely echoes the schema's own wording. 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 (document) within the 'Xenition workspace', and enumerates the concrete artifact types it produces (report, article, letter, brief, essay, plan). It explicitly names the siblings it is not (create_slides, find_forms), so an agent can route 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?

Provides an explicit when-to-use trigger ('when the user asks for a written piece') and two named alternatives with the conditions that select them ('For slides use create_slides; for a fill-in template such as an invoice or resume, use find_forms'). Nothing about the routing decision 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 the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds real context beyond them: the image is persisted to the user's Xenition library and a link is returned, which discloses a side effect the annotations don't capture.

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 and closed with the sibling routing. Every clause earns its place, with no filler or repetition of schema content.

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, and annotations cover the safety profile. Purpose, usage trigger, alternative routing and the persistence side effect are all present, leaving no gap for an agent 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?

Schema description coverage is 100%, so the schema already documents prompt, title and reference with examples. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the 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+resource (create an image) and enumerates concrete output types — illustration, photo-style picture, logo idea, background. It also names the sibling it is not (edit_image), so the agent can distinguish it 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 when to use it ('when the user wants an image made from a description') and provides the exclusion plus alternative ('To change an existing image, use edit_image'). Both the trigger and the hand-off are 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 write (readOnlyHint=false), non-idempotent, non-destructive, openWorld. The description adds genuinely new context beyond those: the output is a public link anyone can use, and submitted responses are collected in Xenition rather than returned to the caller. That public-exposure and response-routing detail is valuable for a mutation tool. It stops short of 5 because it says nothing about permissions, limits on field count, or editing/deleting the form afterward.

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 first front-loads what the tool creates, the public link, the return value, and where responses go; the second delivers the usage trigger. There is no filler, and the example use cases cost almost no tokens while sharpening the intent.

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 a full output schema present, the description needn't explain return values, yet it still flags that a shareable link comes back. Combined with 100% schema coverage, safety annotations, and listed use cases, an agent has enough to call this correctly. It is not a 5 because it omits any steering away from related tools (form_responses, submit_form) and gives no lifecycle context for the created form.

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 title, fields, and collectEmail are all already documented with meanings, and field type/options/required are described inline. The description adds no parameter-level syntax or constraints beyond the schema and merely repeats the general idea of collecting input. 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 fillable, shareable form) and reinforces it with a concrete analogy ('like a Google Form') plus example uses (surveys, sign-ups, feedback, RSVPs). It also says what the tool returns and where responses land, which implicitly separates it from view-side siblings like form_responses. It never names the closest siblings (find_forms, form_responses) explicitly, so it falls just short 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?

The final sentence gives an explicit usage trigger: 'Use when the user wants to gather input from other people.' That is clear context for selection. However, there is no guidance on when NOT to use it (e.g., internal/local forms vs. public forms) and no named alternative such as find_forms or form_responses, so it stops at a 4.

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 it is a non-readonly, non-destructive, non-idempotent, closed-world creation. The description adds that it returns slides as an inline preview plus an edit link, but since an output schema exists return format is partly redundant, and it says nothing about cost, latency, or that repeated calls create duplicate decks.

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 core action is front-loaded, followed by the return behavior and trigger conditions. No filler or repetition.

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 covering returns, the description supplies what an agent needs to select and call it. Minor gaps remain around limits (e.g., deck size) and duplication behavior on repeated calls.

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 baseline is 3. The phrase 'from a brief or topic' loosely echoes the required 'brief' parameter, but adds no format, length, or example guidance beyond what the schema already documents.

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 ... presentation deck') plus scope ('in the user's Xenition workspace from a brief or topic'), which cleanly separates it from siblings like create_document, create_spreadsheet, or create_diagram. An agent can identify it 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?

The final sentence gives explicit trigger conditions ('when the user asks for slides, a deck, a presentation, or a pitch deck'), which is strong routing guidance. It does not name alternatives or state when-not-to-use, 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), so the bar is lower. The description still adds real value by disclosing the side effect that output is persisted to the user's Xenition library and returned as an MP3 link — a lasting artifact an agent should know about.

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 tight sentence with the trigger front-loaded and the return/persistence behavior trailing. Every clause earns its place; nothing is redundant with the title or 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-value detail is not required, yet the description still summarizes it as an MP3 link. For a non-destructive creation tool with full annotations, the trigger plus persistence note is sufficient, though it omits any hint about voice/language options or generation 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 description coverage is 75% (text, voice, and language are documented; title is not). The description adds no parameter-level meaning at all — nothing about voice selection, language codes, or what title does — so it neither compensates for the gap nor improves on the schema. Baseline 3 for high coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a concrete verb and resource — turning text into an audio file — and illustrates it with use cases (voiceover, narration, spoken message). It is clearly distinguishable from the inverse sibling transcribe_audio, though it never names any sibling explicitly.

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" gives an explicit triggering condition. There is no statement of when not to use it and no alternative tool is named, 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 readOnly=false, destructive=false, idempotent=false and openWorld=false, so the safety profile is covered. The description adds the return hint ('Returns the sheet and a link to open it') and the workspace scope, but says nothing about permissions, side effects, or whether creating is reversible in this tool's own terms.

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 purposeful clauses: trigger, output, and routing alternative. Front-loaded with the trigger and zero 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 elaboration, and annotations carry the safety profile; the description covers purpose, trigger, and the nearest alternative. Only marginally thin on creation-time behavior, but complete 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 coverage is 100%, so both parameters (brief, title) are already documented in the schema. The phrase 'with formulas where useful' mildly informs what the brief should contain, but adds little beyond structured data, so 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 (create) plus resource (spreadsheet/data table) with concrete examples (budget, tracker, schedule, list). It also explicitly distinguishes itself from the add_rows sibling, 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?

The opener gives an explicit trigger ('when the user wants a new spreadsheet...') and the closing sentence names the alternative and the condition that selects it ('To add rows to an existing sheet, use add_rows'). 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 only carry the safety profile (readOnly=false, idempotent=false, destructive=false); the description supplies the genuinely important behavioral trait: this is asynchronous, returning an id immediately while generation runs for minutes, and video_status is the way to learn when the file link is ready. That is exactly the context an agent cannot get from annotations or 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?

Three sentences, front-loaded with the usage trigger, then the async lifecycle, then the storage side effect. No filler and nothing 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?

With an output schema present, return values need not be described, and the async lifecycle plus library persistence are covered. It omits any note on cost/credits or generation failure handling, which would be the only remaining gap for a long-running generation 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 75%, near the 80% baseline where the schema already documents aspect, prompt, and duration; only title is undocumented. The description adds no parameter-level detail beyond the generic "from a description" phrasing, so it neither compensates nor detracts.

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 (create) and resource (short AI video clip) plus the trigger input (a description), so the purpose is unambiguous. It does not, however, explicitly distinguish itself from the closest sibling edit_video, leaving that differentiation to inference.

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 activation condition and an implied scope limit (short clips). There is no explicit when-not or named alternative such as edit_video for modifying an existing clip, 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, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the useful precondition that the action must be awaiting a user decision, but says nothing about whether a denial is reversible or what happens downstream to the denied request.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, verb first, no filler. The precondition and the source tool are packed in without a wasted clause.

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 described, and annotations carry the destructive/non-idempotent profile. For a one-parameter tool the description is nearly sufficient; only the post-denial effect on the request is 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?

With a single parameter and 100% schema description coverage, the schema already documents id fully. The description only echoes the provenance ("from list_pending_approvals"), adding no format or syntax detail beyond the schema, 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 ("Deny") and resource ("a pending action awaiting the user's decision"), and ties it to the source tool list_pending_approvals. It does not explicitly name the sibling approve_action as the counterpart, so differentiation is left to the reader's inference from the verb.

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 deny one. However, there is no explicit statement of when to use this over approve_action, nor any exclusion or prerequisite beyond the pending state.

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?

Beyond the annotations, it discloses the async contract ('returns right away; deploying takes a few minutes, and app_status reports the live URLs') and a meaningful side effect not covered by any annotation: publishing makes the app reachable by anyone with the link. It doesn't restate idempotency or read-only status, which the annotations already carry.

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 earning its place: trigger, prerequisite plus async behavior, and the exposure caveat. The trigger is front-loaded 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?

The output schema exists, so return values need no explanation, yet the description still usefully points to app_status for live URLs. For a one-parameter async action with full annotation coverage, 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% for the single artifactId parameter, so the schema already documents it fully. The description only adds that the id originates from build_app (with app_status as a status check), which is marginal additional meaning beyond the schema's own 'from build_app (or search_artifacts)' note.

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 ('published to a live URL', 'Deploys the app from build_app') and differentiates from siblings by tying the artifact to build_app/app_status and separating deployment from the publish_artifact family. An agent can distinguish it from edit_app, create_app, and app_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?

It gives an explicit trigger ('when the user wants their built Xenition app published'), a precondition ('it must have finished building — check app_status'), and an explicit restriction ('only do it when the user asks'). The when/when-not conditions are spelled out rather than implied.

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 readOnly/openWorld/idempotent=false, but the description adds behavior the annotations cannot: retrieval is live at the moment of asking rather than from a stored copy, results must be attributed with sources and timestamps, and result fields must be quoted verbatim. These are non-obvious output and process expectations that materially change how an agent behaves.

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 freshness are front-loaded, and the operational warnings are grouped at the end. It is a bit long and the caps-emphasized 'QUOTE THEM' sentence restates an already clear point, but each sentence does carry actionable content.

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 and 100% schema description coverage, the description only needed to cover freshness semantics, the `near` prerequisite, and output-usage rules — all present. Minor gaps remain around limits/rate behavior and empty-result handling, but 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 exceeds it by stating a cross-parameter constraint not expressible in the schema (place types require `near`) and by explaining that lat/lng are the right choice when the conversation states the user's location instead of inferring a place name.

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 (look up) and resource (real, current info from open public sources) and enumerates the catalogues covered (jobs, hospitals, banks, schools, etc.), which clearly separates it from siblings like search_marketplace or query_document. The live-read scope (current, not stored copy) further pins down what this tool uniquely is.

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 operational guidance: place types REQUIRE `near`, use lat/lng instead of guessing 'near me', and do not web-search for a detail already present in results. It stops short of naming a sibling alternative or stating when *not* to use this tool (e.g., versus discover_sources), so it is strong but not exhaustively routing.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds that output concerns source provenance and licensing, which is modestly useful context, but it doesn't disclose pagination, lookup granularity, or failure 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, front-loaded with the purpose before the usage trigger. Most words earn their place, though 'Say where a Discover answer comes from' is slightly roundabout phrasing.

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 needn't be explained, and annotations cover safety. The description supplies purpose and usage context; the only soft spot is the ambiguous 'type'/'catalogue' parameter, which neither description nor schema fully clarifies.

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, so the schema carries the burden. The description loosely ties the lookup to 'a data type', hinting at the 'type' param, but adds no syntax, examples, or accepted values 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?

States a specific purpose — surfacing which public sources back a Discover answer and their licence. It doesn't explicitly name the sibling discover_search, but it references 'a Discover answer' which ties it to the Discover family, so an agent can distinguish it reasonably well.

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 when-to-use trigger: 'when the user asks how we know something, or whether the information can be trusted.' There is no when-not condition or named alternative, but the invocation context is clear.

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 that affected files are rewritten and a new version is saved (explaining the non-idempotent, mutating nature), that live changes are gated behind a subsequent deploy_app call, and that the app must have finished building first. The annotations only carry destructiveHint/readOnlyHint/idempotentHint flags; the description supplies the versioning, deploy-state, and precondition semantics the agent actually 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-loaded with the triggering scenario, then each subsequent sentence adds a distinct, non-redundant fact (what it rewrites, the deploy gate, the build prerequisite). No filler or repetition.

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 explained, and the description already covers the mutation behavior, versioning, deploy gating, and the build prerequisite. An agent has everything needed 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 description coverage is 100%, so both parameters (artifactId, instruction) are already fully documented in the schema, including the source of artifactId and the plain-words nature of instruction. The description echoes 'described in plain words' but adds no syntax or format detail 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 (change/edit) and resource (an app built in Xenition), with concrete examples of what 'change' means (add a feature, change a screen, restyle, fix). It clearly distinguishes itself from the generic edit_artifact and from build/create_app siblings by scoping to modifying an existing built app.

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 when-to-use ('when the user wants to change an app they built'), plus a named prerequisite (app must have finished building; check app_status) and the deploy relationship (change not published until deploy_app is called again). It stops short of naming an explicit alternative to use instead in any scenario, so it is strong but not a full when/when-not/alternative matrix.

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, readOnlyHint=false, so the mutation profile is covered. The description adds real behavioral value beyond them: 'Saves a new version and returns it' discloses versioning/recoverability and that the result is returned, which the hints alone do not convey. It stops short of mentioning permissions or undo semantics.

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 with zero waste; the usage trigger is front-loaded, followed by scope, versioning behavior, and the routing alternative. Every sentence 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 two-parameter edit tool with rich annotations and an existing output schema, the description supplies everything an agent needs: trigger, scope, supported operations, versioning behavior, and the alternative tool. Return-value detail is correctly 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 description coverage is 100%, so both parameters (artifactId, instruction) are fully documented in the schema itself. The description adds no syntax, format, or constraint 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?

States a specific verb (edit) and resource (artifact/item) and enumerates the exact operation types supported (rewrite, shorten, expand, tone, grammar, translate). It is clearly distinguishable from sibling editors like edit_app/edit_image and from review_artifact.

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 ('Use this when the user wants one of their existing Xenition items changed in place'), scopes applicability ('Best for documents and notes'), and names the alternative with its selecting condition ('To only suggest changes without editing, use review_artifact'). 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=false and readOnlyHint=false, and the description usefully adds that the result is saved as a new image while the original is kept – reinforcing non-destructiveness and clarifying output location. It doesn't cover permissions or rate limits, but it earns real credit 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?

Two sentences, front-loaded with the trigger and operations, then the output behavior. No filler; every clause carries weight.

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 description still confirms the saved-result location. The only real gap is prerequisites (auth or library context), but for a mutation tool with annotations this is largely 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 75%, so the schema already documents image, prompt, and operation values. The description's operation list loosely mirrors the enum but adds no syntax or format detail 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?

Specific verb (edit) plus resource (image), with a full enumeration of operations that mirrors the operation param and distinguishes it from the sibling create_image by scoping to an 'existing image'. An agent can tell what this 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?

The opening clause 'Use this when the user wants an existing image changed' gives clear triggering context, and the operation list clarifies the breadth of edits. It stops short of naming alternatives (e.g., create_image) or stating when-not-to-use, so it's clear but not complete.

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 it is a non-read-only, non-destructive, non-idempotent write. The description adds genuinely useful context beyond that: it is asynchronous ('returns an id right away'), the original is preserved, and the result lands in the Xenition library. It does not mention failure modes or credit/permission requirements.

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 usage trigger front-loaded, followed by async behavior and data-safety notes. No filler, though the final sentence could be trimmed slightly.

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

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a simple 4-parameter tool, an output schema, and full annotations, the description covers the trigger, the operation set, async behavior, and result location. 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 75%, and the description independently explains the operation vocabulary (captions/enhance/matte/jumpcut) and ties language to captions. It adds meaning over the schema, though the title parameter and the URL source distinction are left to 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?

Names a specific verb (edit) and resource (an existing video) and enumerates the concrete operations supported: captions, enhance, matte, jumpcut. This clearly separates it from siblings like edit_image, edit_app, and create_video.

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 ('Use this when the user wants an existing video improved') and names video_status as the follow-up for readiness. It does not explicitly name when NOT to use it (e.g. to create a new video, use create_video), so the routing is implied rather than fully closed.

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 it is not read-only, not idempotent and not destructive, so the safety profile is partly covered. The description adds that the result is a link to the PDF, which is useful, but it never explains the side effect implied by readOnlyHint=false (e.g. whether a PDF file is persisted, whether repeated calls produce different links given idempotentHint=false) or any permission requirements. Additional behavioral context beyond the annotations is thin.

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, with the primary trigger stated first, the return value second, and the scope restriction last. 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 the description need not explain the return payload, and the artifact-type scope is fully covered. The only shortfall is the unexplained non-idempotent, non-read-only behavior of the export operation, which leaves a minor gap for an agent deciding whether re-invoking is safe.

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 at 100% schema description coverage, and the schema already tells the agent that artifactId comes from search_artifacts or create_document. The description adds no format or sourcing 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?

Names a specific verb (export) and resource (a Xenition document as PDF), and explicitly carves out the artifact types it does not cover (slides, sheets, notes). An agent can distinguish it from siblings like get_artifact or edit_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?

Front-loads the trigger condition (user wants a document as PDF to download, print or attach) and gives an explicit exclusion plus the alternative route for other artifact types (open them in Xenition to export). 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=true and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioral constraint beyond them: 'Answers only from that document,' which tells the agent output is grounded to the source and not generalized, consistent with openWorldHint=false. It does not describe behavior when the requested item is absent, keeping it just 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?

Two sentences, no filler, with the usage trigger front-loaded before the alternative-tool pointer. Every clause carries decision-relevant 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 two-parameter read tool with full annotation coverage and an output schema, the description supplies purpose, trigger, routing to the sibling, and the grounding constraint. Nothing an agent needs to select or 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 both parameters are documented in the schema, so the baseline is 3. The description's examples ('names, dates, figures, action items') loosely illustrate the 'what' parameter but add no syntax or format guidance beyond the schema's own examples.

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 (extract) plus resource (one of their Xenition documents) and names the output shape (as a list), with concrete examples of extractable kinds (names, dates, figures, action items). It also distinguishes itself from the sibling query_document explicitly.

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 when-to-use trigger ('when the user wants a specific kind of information pulled out... as a list') and an explicit alternative with its own condition ('To ask a free question about it, use query_document'). No inference required from the 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 readOnly=true, destructive=false, openWorld=false, so safety is covered. The description adds context the annotations cannot: the corpus size (~200 templates), the fact each template is full-stack with a live demo, and that results include demo links and reusable ids. It does not discuss pagination or ranking behavior, which keeps 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?

Two sentences, front-loaded with the trigger condition, then the search behavior and the follow-up action. No filler or restated boilerplate.

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, and annotations cover the safety profile. The description supplies the remaining essentials: when to use it, what it searches, and how to proceed afterward. All parameters are optional, so nothing blocks a correct call.

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 query, category and limit are already documented in the schema; the description's business-type examples largely echo the query description. It adds the concept that results carry template ids usable elsewhere, but no new syntax or constraint detail beyond the schema. 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 (finds/searches) and resource (Xenition's ~200 full-stack app templates), and explicitly differentiates from the sibling build_app_from_template by describing the handoff. An agent can tell this apart from create_app/build_app 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 ('when the user wants a ready-made app for a kind of business') with concrete examples, and names the follow-up action and the sibling to use for it ('pass a template id to build_app_from_template'). Both when-to-use and the alternative path are 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 readOnlyHint=true, openWorldHint=false and destructiveHint=false, and the description aligns with them by framing this as a search over Xenition's own library. The extra note that results expose form fields and can be completed in place to generate a document is useful behavioral context 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?

Two sentences, front-loaded with the resource and scope, then the usage trigger; no filler. The parenthetical example list is a touch long but earns its place by conveying coverage breadth.

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 only 2 parameters, full schema coverage, and an output schema handling the return shape, the description is nearly sufficient. Only the routing decision versus document-creation siblings is left implicit, which is a minor gap for this complexity level.

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 'query' and 'limit' are already documented in the schema. The description's inline examples ('invoice', 'resume', 'business proposal') loosely illustrate valid queries but largely duplicate what the schema's query description already provides, so 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), and concretely bounds the scope with examples and '~200 more'. It reads clearly against siblings like create_document, though it never names an adjacent tool to sharpen the distinction.

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 a clear triggering context. There is no when-not guidance and no named alternative (e.g. create_document for a blank doc), so the agent must infer the routing boundary itself.

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 establish readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the description only needs to add non-safety context. It does disclose catalog breadth (~200 tools) and that results are links/ids rather than answers, though the return shape is partly redundant with the existing 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?

Three short sentences, front-loaded with the trigger condition before the return behavior and the chaining advice. Every sentence carries routing information; nothing is 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, the description correctly avoids re-explaining the result structure and instead covers purpose, trigger, catalog scope, and the id-to-run_tool handoff. Nothing an agent needs to select and invoke this tool 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 query and limit are already documented with examples and a default in the schema. The description adds no syntax, matching behavior, or default semantics beyond what the schema provides, 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 (find) and resource (built-in tools for calculator/converter/generator) plus the concrete job it performs: resolving a tool name to its id. It explicitly distinguishes itself from run_tool, so an agent can differentiate it from the sibling that actually executes tools 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 ('when the user asks for a calculator, converter or generator... and you need the tool's id') and names the follow-up alternative with its condition ('to get an answer from the tool, pass its id to run_tool'). Use-vs-alternative routing is explicit and complete.

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 (readOnly, non-destructive, non-idempotent, closed-world), so the bar is lower. The description adds real context beyond that: ordering ('newest first'), per-response payload contents, and an ownership/authorization constraint ('only works for forms the user owns').

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 'Use this when...' trigger, followed by ownership and return-format notes. Every sentence carries information, though the parenthetical example list is slightly expendable.

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 needn't be detailed, yet the description still notes ordering and payload shape. Combined with annotations covering safety and the description's ownership constraint, 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?

Schema coverage is 100% and the schema already explains the form parameter accepts a link or token. The description's 'Takes the form's link' adds only marginal clarity over the schema, which is the expected baseline-3 outcome 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 (see/read) and resource (responses submitted to a shareable form) and explicitly ties itself to create_shared_form, making the relationship to siblings like create_shared_form, find_forms, and submit_form clear. The example list (sign-ups, survey answers, RSVPs, feedback) sharpens the domain.

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 ('when the user wants to see what people submitted') and a precondition ('forms the user owns'). It doesn't explicitly name a competing sibling (e.g. find_forms) or state when-not to use it, so it falls just 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 readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns content, and very long items are truncated to the first part — a critical operational detail an agent must know before deciding to 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?

Three short sentences, front-loaded with the trigger condition, then the truncation caveat, then the exclusion. No filler and nothing redundant with 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?

Output schema exists so return values need no explanation, yet the description still flags truncation for long items. For a single-param read tool with full annotation coverage, nothing an agent needs 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 the schema documents id with an example (art_abc123), so the baseline is 3. The description adds provenance value by telling the agent where the id comes from ('from search_artifacts or an earlier result'), which meaningfully helps parameter sourcing.

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 (read/open) and resource (a document, deck, spreadsheet, note or other artifact) and names the identifier needed. It is immediately distinguishable from siblings like search_artifacts or summarize_artifact.

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 when-to-use condition ('user wants to read or open one specific item ... and you have its id'), an explicit when-not ('Do not use to find items; use search_artifacts'), and routes long items to query_document or summarize_artifact.

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. The description adds the notion that it returns status and results and defines mission scope, but doesn't disclose anything beyond what annotations plus the output schema provide. With annotations carrying the behavioral load, 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?

Three short sentences, zero filler, with the purpose and the alternative routing front-loaded. Every sentence 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-parameter read tool with a full annotation set and an output schema, the description covers what the agent needs: what the tool fetches, what identifies the target, and how to route to the list variant. Nothing critical 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?

There is a single parameter at 100% schema coverage, and the schema already documents it as 'the mission id (from list_missions)'. The description adds no syntax, format, or sourcing 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?

Specific verb (get) plus resource (mission), with an inline definition of what a mission is ('a long-running multi-agent job') and its scope (by id). It explicitly names the sibling it is not, so an agent can distinguish it from list_missions 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?

States the triggering condition ('when the user asks about one specific Xenition mission by id') and names the alternative (list_missions) for the contrasting case. Nothing about when to prefer one over the other 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 declare non-readOnly, non-destructive, non-idempotent, so the safety profile is partly covered. The description adds real context beyond them: the result is an editable document, which downstream tools (summarize_artifact, query_document, ask_workspace, edit_artifact) can operate on, and which formats are accepted. It stops short of noting that repeated calls create duplicate documents (non-idempotent) or what permissions are needed.

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 front-loaded sentences: trigger first, encoding instructions second, downstream capabilities and the alternative last. Every sentence carries decision-relevant information and none repeats the tool name or 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?

An output schema exists, so return values need not be explained, and the annotations cover the mutation/safety profile. The description supplies formats, downstream consumers, and the sibling alternative, which is enough for correct invocation; only the non-idempotent duplicate-creating behavior is left undisclosed.

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 all four parameters and the either/or constraint are already documented in the schema. The description restates the textContent/base64Content choice and contentMimeType without adding syntax or format detail the schema lacks; the format list (text, Markdown, CSV, JSON, HTML, PDF) is only marginally beyond the schema's MIME examples. 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 ('bring a file's content into their Xenition workspace') and immediately disambiguates from the closest sibling by naming add_to_knowledge for web pages. An agent can distinguish this from add_note, create_document and add_to_knowledge 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 wants to bring a file's content into their workspace — e.g. they attached or pasted a document'), the encoding path to choose (UTF-8 vs base64), and a named alternative with its condition (add_to_knowledge with a URL for web pages). 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 readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered by structured data. The description's only behavioral addition is a one-line sketch of the return payload, which overlaps with the existing output schema and omits anything about ordering, empty-state behavior, or counts.

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, both front-loaded with actionable content: the usage trigger first, the return shape second. No filler, no 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?

For a zero-parameter read-only list tool with a full output schema and complete annotations, the description covers purpose, trigger conditions, and output shape. There is no meaningful gap an agent would need filled before invoking it.

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 clarify and no risk of misuse at the argument level. Baseline 4 for a parameterless 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 and resource ('list... Xenition agents') and immediately defines the resource parenthetically as 'named AI workers', which disambiguates it from other 'agent'-adjacent siblings like run_agent or check_agent_run. An agent can identify the tool's scope 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?

Gives two explicit triggering conditions: when the user asks what agents they have, and as a prerequisite step before run_agent to pick the right one. It names the sibling it pairs with, so the routing decision is fully specified.

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 the returned fields, but with an output schema present that disclosure is partly redundant, and it says nothing about ordering or rate limits beyond what annotations provide.

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 tightly written sentences: usage condition front-loaded, then return contents. 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?

Complete for a zero-parameter list tool with an output schema; the description needn't explain return format, and it correctly focuses on when to call it. Minor gap: no mention of ordering or empty-result behavior.

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?

Zero parameters, so the baseline is 4; there is no parameter semantics to clarify and nothing is missing.

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 (list automations) and enumerates the returned fields (schedule, on/off state, last run, id), clearly distinguishing it from the create_automation and set_automation_enabled 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?

Gives explicit triggering conditions ('when the user asks what automations they have, when they run, or whether one is paused'), which maps directly to real intents. It does not name alternative tools for the adjacent tasks (e.g. set_automation_enabled for pausing), so it stops short of full when-vs-alternatives 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 readOnlyHint=true and destructiveHint=false, so 'Read-only' largely restates structured data. The valuable addition is the capability boundary — it cannot connect new apps or act in them — which tells the agent what this tool will never do, beyond what the annotations state.

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 waste: the usage trigger is front-loaded and the safety/capability note follows. 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 an output schema present, return values need no explanation, and there are no parameters to document. Purpose, trigger, and the read-only/no-connect boundary together cover everything an agent needs 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool applies. The description correctly avoids inventing parameter-like filtering behavior.

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+resource ('which third-party apps ... are connected to their Xenition account') and illustrates it with concrete examples (Gmail, Slack, Notion). An agent can distinguish this read-only inventory call from neighboring tools like app_status or list_agents 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 an explicit trigger ('Use this when the user asks which third-party apps are connected') and an explicit exclusion ('cannot connect new apps or act in them'). It does not name an alternative sibling tool for the connection-management case, which keeps it just 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that it returns events with times and links, which is largely redundant with the output schema; it discloses nothing about ordering, pagination, or auth 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?

Two sentences, zero waste, with the primary use condition front-loaded before the sibling routing. Each sentence 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 one-parameter read tool with an output schema and full annotation coverage, nothing an agent needs to select or 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 the single range parameter is fully documented in the schema. The description echoes the natural-language range options ('today, this week, a date, or upcoming') but adds no syntax or default details beyond the schema, so 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 (list) plus resource (calendar events) with the Xenition calendar named. It explicitly distinguishes itself from my_agenda, so an agent can route between them 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?

States exactly when to use it ('when the user asks what is on their calendar for a range — today, this week, a date, or upcoming') and names the alternative (my_agenda) with the condition that selects it (combined view of events, tasks and approvals).

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 useful framing (long-running multi-agent jobs) and discloses the return shape (status and id), but says nothing about pagination, volume, or ordering of the list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste: the trigger condition is front-loaded and the follow-on pointer (id for get_mission) is packed into the second sentence. 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?

For a zero-parameter list tool with an output schema, the description covers what is needed: when to call it and that it returns status and id. Richness is limited, but 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There are no parameter semantics to add beyond what the empty schema already implies, and the description does not need to compensate for any 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?

The description gives a specific verb (list) and resource (missions), then defines the resource as 'long-running multi-agent jobs' and says it returns status and id. It also points to the get_mission sibling for detail, so an agent can tell it apart from the single-mission reader. The title says 'List agent runs' rather than missions, a minor mismatch, but the body 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?

It states an explicit trigger condition: 'Use this when the user asks what missions they have in Xenition and how they are going.' It also routes the agent to get_mission for per-mission detail. There is no statement of when NOT to use it (e.g. a single mission or agent-run check), which keeps it 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.