Waspes

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and the description is consistent with a safe, repeatable setup call. It adds value beyond annotations by disclosing a prerequisite (a Waspes API key for the plugin) and the concrete outcome (MeshParts in the open place).

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 front-loaded sentence puts the return value first, then the outcome, then the follow-up route. It is dense but every clause carries information; the parenthetical purpose clause is slightly long but not wasteful.

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

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

For a zero-required-parameter setup tool, the description covers what is returned (instructions + link), the prerequisite (API key), the effect (MeshParts), and the next step (send_to_roblox). Nothing an agent needs in order to call it correctly is missing, and no output schema is required.

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

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

Only one optional parameter with 100% schema description coverage, so the schema already fully explains the text/markdown format choice. The description adds nothing about the format option, which is acceptable given the high coverage — 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 and resource: returns step-by-step connection instructions plus a plugin download link. It also names the downstream effect (models inserted as MeshParts) and explicitly differentiates itself from the sibling send_to_roblox, which is a separate operation once connected.

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?

Clearly frames this as the setup step, with 'Once connected you can send a model... with send_to_roblox' giving the agent the sequencing and the alternative. It stops short of explicitly saying 'do not call this if already connected', so no hard exclusion is 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 it as non-read-only, open-world, non-idempotent, and non-destructive. The description adds useful behavioral detail beyond that: scoped CSS, AJAX submit, double opt-in, return of the form HTML, and an API-key requirement. It stops short of explaining side effects or what happens to generated forms after creation.

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 compact sentences, front-loaded with the core outcome and then the return value and prerequisite. Every clause carries information and there is no repetition of 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 no output schema, the description appropriately states that the form HTML is returned. Parameters are fully schema-covered, and the API-key prerequisite is disclosed. Minor gaps remain around what 'double opt-in' entails operationally, but the definition is otherwise sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description does not add parameter-level meaning beyond the schema; 'to you' loosely hints at deliver_email but gives no syntax or constraint detail.

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

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

The description states a specific verb and resource: generate a standalone HTML contact form that emails submissions. It is clearly distinct from generic website-generation siblings, though it does not explicitly name or contrast with any alternative tool.

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?

Usage is implied by the phrase 'standalone, fully-wired HTML contact form' and the API-key prerequisite, but there is no explicit guidance on when to choose this over generate_website or other siblings, and no stated exclusions.

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

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

Annotations already declare read-only, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context an agent needs: an API key prerequisite and the fact that the output is long and directly pasteable rather than a short answer. It stops short of noting latency, cost, or output length 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?

One sentence with front-loaded verb and outcome, plus a short prerequisite clause. No filler and nothing buried.

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

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

For a one-parameter generation tool with no output schema, the description covers input expectation, auth requirement, and the general nature of the return value. It could say more about the output's shape or variation between target builders, but nothing essential to making the call 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% for the single parameter, so the baseline is 3. The description adds meaning the schema does not: 'one-line idea' tells the agent to pass a short seed rather than a full specification, which shapes how the parameter should be filled in.

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 transformation: takes a one-line idea and returns a long, ready-to-paste master prompt. The output artifact (a builder prompt, not a website or form) clearly separates it from siblings like generate_website and generate_form, and it even names the target builders.

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?

Usage is implied by the input shape ('a one-line idea') and the artifact produced, plus a hard prerequisite ('Requires a Waspes API key'). However, there is no explicit when-to-use/when-not-to-use guidance and no routing against nearby siblings such as generate_website.

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, openWorldHint=true), but the description adds critical non-obvious traits: the long runtime and client timeout risk, the async alternative, API-key plan/daily limits, and the capped anonymous demo. None of this contradicts the annotations; it meaningfully extends them.

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 doing distinct work: what it produces, what it returns, and how to call it safely. The timeout warning is front-loaded before the auth note, so the agent sees the critical constraint before deciding.

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?

No output schema exists, but the description states 'Returns the full HTML', closing that gap. For a non-destructive, open-world generation tool, the agent has everything needed: input nature, output form, runtime, timeout risk, and auth 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?

Schema description coverage is 100%, so brief, style, and deliver_email are already documented well. The description only restates that input is a 'plain-language brief' and doesn't add syntax, defaults, or constraints 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?

States a specific verb and artifact ('Generate a complete, responsive, single-page website (HTML)') plus the content it produces (real copy, inline-SVG, sections, contact form). This cleanly separates it from generate_form and generate_master_prompt without requiring the agent to open another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly warns that the synchronous call will time out and names the preferred alternative ('prefer the async pair start_website + get_website instead'), with the reason (~1–3 minutes) attached. The when-to-use-vs-when-to-avoid guidance is stated directly.

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 read-only/idempotent/non-destructive, so the bar is lower, and the description still adds substantial behavioral detail: the polymorphic return (full HTML on completion vs. {"status":"pending"}) and the recommended polling interval. That is exactly the runtime behavior an agent cannot infer from the annotations.

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

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

Three short sentences, front-loaded with the action, followed by return behavior and the polling instruction. No sentence is redundant.

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

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

With no output schema, the description carries the full burden of explaining return values and does so (HTML vs. pending status), plus the polling cadence needed to use the tool correctly. 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?

Only one parameter with 100% schema description coverage, so the schema already explains that jobId comes from start_website. The description reinforces the origin of the ID but adds no format or validation detail beyond that baseline.

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

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

States a specific verb and resource ('Fetch the result of a start_website job') and immediately ties it to the sibling that creates the job. The two possible return shapes (HTML vs. pending JSON) make the tool's contract unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operating instructions: poll again in ~20–30s and keep polling until HTML is returned, which tells the agent exactly how to drive the async loop. It implies the prerequisite (a start_website jobId) but never explicitly states what to do if the job failed or whether calling before start_website is invalid.

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 read-only, idempotent, non-destructive, closed-world behavior, so the description only needed to add context — and it does, disclosing the API-key authentication requirement and the JSON shape (taskId, taskType, title, thumbnail). It does not discuss throttling or what happens past the default result cap.

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

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

Two sentences, no filler: the first defines scope and return shape, the second gives the use case and the auth prerequisite. Front-loaded and 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 zero-required-param read tool, this covers everything an agent needs: what is returned, why to call it, and the API key requirement, with annotations handling the safety profile. No output schema exists, but the description lists the return fields itself.

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

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

Schema description coverage is 100%, so the single `limit` parameter (default 50) is already fully documented in the schema, and the description adds nothing about it. Baseline 3 applies when the schema does all the parameter work.

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

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

States a specific verb and resource ('List the 3D models on your Waspes account'), names the two sources (3D Studio and Waspex), and enumerates the returned fields. No sibling tool lists models, so the resource alone separates it from the generate_*/send_to_roblox tools.

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 it to see what can be imported into Roblox Studio or downloaded' gives a clear trigger for calling it. It stops short of naming an alternative or stating when-not to use it, but with no competing list tool in the sibling set there is little ambiguity left.

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

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

Annotations only declare the generic non-read-only, open-world, non-idempotent, non-destructive profile; the description adds genuinely new context — API key requirement, plugin must be in Live mode, insertion as textured MeshParts saved with the place, and a few-second latency. It omits what happens when the plugin is absent or whether the queued task is retried, which is the main remaining gap for a queue-based side-effecting tool.

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

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

Four short sentences, front-loaded with the action and outcome, then the required identifier and prerequisites. No filler sentences; every clause carries usable 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?

No output schema exists, and the description still conveys the observable effect, timing, and prerequisites, which is enough for an agent to invoke it confidently. It could say what the call returns (e.g. a queued job confirmation) and how to detect failure, but nothing essential to invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces taskId's source (list_3d_models) but says nothing about taskType (model vs image), so it adds little 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 verb and resource ('Queue one of your Waspes 3D models to appear in your open Roblox Studio place') with an explicit scope and outcome. It is clearly distinguishable from siblings like list_3d_models and connect_roblox, which are referenced rather than described as alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear entry conditions: get the taskId from list_3d_models, hold a Waspes API key, and have the Studio plugin running in Live mode. It doesn't state any when-not-to-use case or what to do if the preconditions fail, so it falls short of a 5.

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

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

Annotations only flag safety ('readOnlyHint': false, 'destructiveHint': false) and openness; the description adds what they cannot: this is asynchronous, returns a jobId immediately, takes roughly 1–3 minutes, and must be polled rather than awaited. That timeouts motivated the design is exactly the kind of behavioral context an agent needs to choose correctly.

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 action and the immediate return, then the routing rule, then the polling cadence. Every clause carries distinct operational information with no 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 an async job-starter with no output schema, the definition covers the trigger, the return value (jobId), the latency, and the terminal step (get_website yielding finished HTML). Nothing needed to call it correctly or complete the loop is absent.

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 brief/style/deliver_email documentation is already complete and enum-like style options are listed. The description's only addition is 'Same options as generate_website', a cross-reference that adds no syntax or format detail, 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?

The definition pairs a specific verb and resource ('Start generating a full website from a brief') with unusual scope detail: the immediate jobId return and the 1–3 minute background duration. It also explicitly names the sibling it replaces, so an agent can distinguish it from generate_website 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?

'USE THIS instead of generate_website for any real build — it avoids the client timeout' states the selection rule outright, including the reason. The follow-up path is spelled out too ('call get_website with the returned jobId every ~20–30s'), leaving nothing about the workflow to inference.

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