Dplooy

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

The description discloses meaningful behavioral details beyond the annotations: the operation is reversible, submissions/rows/bookings persist with the object, and the response warns when deployed files do not reference the assigned object. It also gives operational guidance — fix the HTML rather than treating the assignment as successful.

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

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

The description is compact and front-loaded with the core purpose, then adds reversibility, data-preservation behavior, and a critical warning. Every sentence contributes useful information and there is no fluff.

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

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

For a mutating tool with no output schema, the description provides good context: effects, reversibility, data fate, and a warning behavior. It could go slightly further by mentioning whether the operation is idempotent or whether other prerequisites apply, but the essential information for correct invocation is present.

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 input schema already documents all four parameters effectively. The description adds nothing new about parameter formats or relationships, so the baseline score of 3 is appropriate.

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

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

The description specifies a concrete action — making forms, data collections, and booking pages LIVE on a deployed project or moving them from another project. It clearly names the involved resources and distinguishes itself from the sibling unassign_from_project by explicitly mentioning reversibility.

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

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

The description gives clear context for when to use the tool: when objects need to go live on a deployed project or be moved between projects. It references the inverse operation unassign_from_project, but it does not explicitly state negative cases or compare with other sibling tools like deploy_files or deploy_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?

With only minimal annotations, the description carries the full behavioral burden and does so impressively: it discloses that the widget is injected server-side, that the update is partial except that knowledge replaces the entire text, and that factual content must never be invented. These are non-obvious behaviors an agent cannot infer from the schema or 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?

The description is dense but every clause earns its place: it front-loads the most important sequencing context, then gives update semantics, safety constraints, and a specific URL guideline. There is no filler or repetition of schema-level detail.

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 10-parameter tool with no output schema and minimal annotations, the description covers the key context an agent needs to invoke it correctly: deployment state, Plus/Pro requirement, partial-update behavior, knowledge replacement risk, and the real-facts constraint. Nothing critical for correct selection or invocation appears 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 schema already documents all parameters at high coverage, so the baseline is 3. The description adds valuable semantics beyond the schema by clarifying that knowledge REPLACES the entire text rather than merging, and by directing contactFormUrl to the site's Dplooy Form URL. This additional operational meaning justifies a score above 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?

The description clearly identifies the action ('Enables/configures the chatbot') and the target resource ('on a deployed project'), then differentiates it from related operations by placing it as the 'LAST step after deploy + assignment' and by contrasting with get_chatbot for editing existing bots. This gives an agent a distinct, unambiguous purpose.

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

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

The description gives explicit sequencing ('LAST step after deploy + assignment'), identifies when an alternative is needed ('editing an existing bot? get_chatbot first'), and provides a concrete operational rule ('Point contactFormUrl at the site's Dplooy Form URL when one exists'). This is strong when-to-use guidance with clear 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important side effects and constraints: it returns an embed and a frozen styling contract that must be styled, requires owner approval, is unavailable until assignment, and is idempotent when retrying the same name while unassigned. This is exactly the kind of behavioral context an agent needs and that annotations cannot express.

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?

Every sentence carries operational weight: deployment timing, return value, styling mandate, approval prerequisite, dependency, retry behavior, naming convention, and services guidance. Critical constraints are front-loaded, and there is no filler or redundant repetition of schema details.

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 nested parameters, no output schema, and multiple operational dependencies. The description compensates by specifying the return payload (embed + styling contract), the owner-approval requirement, the assign_to_project dependency, idempotent retry behavior, and the services-picker use case. For a complex create operation, the agent has enough context to call it correctly and know what to expect.

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 adds business-level meaning for key parameters: it mandates `services` for priced-service businesses, requires the currency, explains the auto-detected Data collection, and supplies a naming convention for `name`. This goes beyond the schema's field-level descriptions, though the schema still carries most of the detailed parameter documentation.

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

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

The description opens with a specific action and resource: 'Create a booking page BEFORE deploying (Plus/Pro).' It further distinguishes the tool by describing its unique output—'two-line widget embed + the frozen .db-* styling contract'—and by warning against reimplementing booking logic. This is clearly a create operation, not a get/list/delete 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?

The description gives explicit temporal and dependency guidance: 'BEFORE deploying (Plus/Pro)' and 'Unavailable until assign_to_project', so an agent knows the prerequisite step and the correct ordering. It also tells when to pass `services` based on business type and requires owner approval. However, it does not explicitly name an alternative tool for non-booking flows, so it lacks a fully explicit when-not-to-use statement.

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 say the tool is neither read-only nor destructive, so the description carries the burden of behavioral context. It adds useful creation semantics: collections are server-prerendered, editable from the dashboard, unassigned collections serve [], and the call returns keys to embed. It does not discuss auth requirements or reversibility, but the core behavior is disclosed.

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

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

The description is information-dense and front-loads the core rule, but it is repetitive and visually noisy. The section list '(services, features, testimonials, FAQ, pricing, team …)' appears twice, and the all-caps phrases like 'NOT optional' and 'broken build' add emphasis more than information. It could be roughly half its length without losing value.

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 the absence of an output schema and the complexity of batching up to 16 collections, the description covers the essential workflow: planning the content model, batching, presets, naming, returned keys, and post-deploy assignment via assign_to_project. The only minor gap is that the return format for the generated collection keys is not explicitly specified, though 'embed each returned key' gives enough direction.

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 adds meaning beyond the schema by establishing the naming convention '<Business Name> — <Purpose>', the hard cap of 16 collections, and the strong preference for passing collections[] in one call. It also reinforces that presets seed the field schema and that image cells must use { mediaId, path } rather than URL strings.

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 clearly identifies the verb and resource: create data collections for every repeating content section. It distinguishes itself from related sibling tools by emphasizing that collections are mandatory, created before deployment, and batched in one call per site. This leaves no ambiguity about what the tool does.

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

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

The description gives explicit when-to-use guidance: create all collections before deploying, on all plans, and in a single call per site rather than one call per section. It also names the post-deploy alternative workflow by stating that unassigned collections must be assigned with assign_to_project after deploying.

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 discloses several behaviors beyond the annotations: the endpoint is inert until assignment, it is movable and un-assignable later, submissions stay with it, and retrying the same name while unassigned returns the existing endpoint instead of duplicating. It also explains the privacy-driven design that no tool reads submissions. No contradiction with readOnlyHint=false or destructiveHint=false.

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?

Every sentence earns its place: main output first, then lifecycle, idempotency, privacy, and naming convention. It is dense but not bloated, and the most actionable guidance is front-loaded.

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

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

With no output schema, the description still explains return values (URL + exact HTML snippet) and covers the full creation-to-deployment lifecycle. It includes the critical requirement to ask the user for notifyEmail and gives a clear naming format. The tool is fully callable based on the description alone.

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 name, slug, and notifyEmail in detail. The description adds a naming convention and idempotency context for repeated names, but does not need to compensate for missing schema information.

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

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

The description states a specific action ('Create a form endpoint'), the resource, and key outputs (URL + HTML snippet). It clearly distinguishes this tool from siblings like create_booking_page or create_data_collection by focusing on form endpoints and their deployment lifecycle.

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

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

It gives explicit timing context: create BEFORE deploying, and explains the tool is inert until assigned via assign_to_project. It also notes that submissions cannot be read by any tool, providing a clear when-not. It does not explicitly contrast with alternative create tools, 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?

The annotations already declare the operation destructive, and the description adds meaningful behavior beyond that: the exact precondition, the 409 refusal case, and the operational instruction to relay the reason to the owner and never retry. This gives an agent strong guidance on what will happen and how to respond.

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

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

The description is compact and front-loads the most important condition ('ONLY unassigned...') before explaining the refusal behavior and follow-up action. Every clause earns its place with 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?

For a one-parameter destructive tool with no output schema, the description covers eligibility, failure mode, error code, and next steps. It does not explicitly describe success behavior, but that is easily inferred from the tool name and destructive annotation, making the gap minor.

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

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

The input schema fully documents the single pageId parameter with 100% coverage, so the description does not need to explain it. Baseline 3 applies because the description adds no extra meaning to the parameter 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?

The name and title clearly identify the resource and action, and the description narrows the scope with 'ONLY unassigned + never received a request.' However, the description itself never explicitly states a verb like 'deletes,' so the core purpose relies on the title rather than being fully stated.

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

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

The description gives clear usage boundaries: success requires an unassigned page with no prior request, and pages that are attached or hold content will be refused with a 409. It also instructs never to retry, but it does not name an alternative tool, 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?

Beyond the destructiveHint annotation, the description reveals the 409 refusal behavior, the reason to relay to the owner, and the no-retry expectation. It also identifies the risky edge case of deleting preserved content.

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 dense sentences, each earning its place: the precondition, the alternative, and the refusal behavior. The key guardrail is front-loaded.

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

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

For a single-parameter destructive tool with no output schema, this description provides everything needed to decide and invoke correctly: preconditions, error handling, and fallback routing. No significant gap remains.

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 explains collectionId and its source. The description adds no parameter-specific meaning, which is acceptable given the baseline for full schema coverage.

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

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

The description clearly identifies the operation as deleting a data collection while adding the precise invariant (only unassigned and zero rows). It distinguishes this from assign_to_project by naming the alternative for collections that still hold rows.

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

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

It explicitly states when deletion is allowed, when it is refused, and the alternative action for unassigned collections with rows. The guidance 'never retry' also tells the agent not to loop on a 409.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, so the destructive nature is known. The description adds valuable behavioral context beyond the annotations: the exact precondition (unassigned + zero submissions), the 409 refusal error, the instruction to relay the reason to the owner, and the explicit 'never retry' warning. This significantly helps an agent handle failure 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?

The description is a single dense sentence that conveys the precondition, failure mode, user communication instruction, and retry prohibition. Every clause earns its place, and the most critical constraint is front-loaded with 'ONLY'.

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 destructive operation with annotations already indicating destructiveness and no output schema, the description is complete. It tells the agent when deletion is allowed, what happens when it isn't, and how to respond. Nothing essential 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?

The input schema already provides 100% coverage of the single parameter, formId, including its meaning and source (from list_forms). The tool description does not add parameter-specific syntax or formatting details, but none are needed because the schema is complete. 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 clearly communicates the tool's purpose: deleting a form, but only in a specific state (unassigned and zero submissions). The precondition and refusal behavior make the action clear even though the verb 'delete' is implied rather than stated directly. It is distinct from sibling tools like delete_booking_page or delete_media because it specifically addresses form deletion constraints.

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

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

The description gives explicit when-to-use guidance: only call this for unassigned forms with zero submissions. It also explains that attached or content-holding forms are refused with 409, and instructs the agent to relay the reason and never retry, which is strong operational guidance. It does not name alternative tools, but for a delete operation the condition itself is the key routing signal.

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 destructiveHint, the description discloses a concrete 409 refusal behavior when the media is attached or holding content, a bounded scan, and a clear operational rule (relay the reason to the owner, never retry). This materially changes how an agent should handle failures and is valuable beyond what annotations already say.

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

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

The description is compact and every clause earns its place, with the key precondition and failure behavior front-loaded. The phrasing is a bit telegraphic ('ONLY an image no collection row'), which slightly hurts readability, but there is no fluff.

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 deletion tool with annotations and a fully documented schema, the description covers preconditions, quota effect, failure mode, and owner communication. The only minor gap is defining terms like 'collection row' and 'bounded scan' precisely for an agent without background context.

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

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

The single parameter mediaId is already fully documented in the schema as coming from list_media or upload_media. The description reinforces that only image-type media should be targeted, but it does not need to add more because the schema coverage is 100%.

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

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

The description identifies a specific action (reclaiming image quota) and a strict scope (only an image with no collection row or project file reference), which makes clear what delete_media does and when it applies. It is not as direct as 'deletes the specified media item' and does not explicitly distinguish itself from sibling deletion tools, but the bounded precondition separates it from broader deletions.

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 context is implied: it is the tool for reclaiming quota from abandoned builds where the media is only an image. It also gives an explicit when-not instruction (anything attached is refused with 409; never retry), but it does not name an alternative tool or state a comparison with siblings.

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

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

The annotations already declare destructiveHint=true, but the description adds substantial behavioral context: exact deletion scope, the un-assignment behavior for attached resources, and irreversibility. This goes well beyond the schema and 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?

The warning is front-loaded, and the description is compact and information-dense. Minor redundancy exists between 'IRREVERSIBLE', 'Permanently deletes', and 'This action cannot be undone,' but it does not significantly hurt clarity.

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 destructive tool with clear annotations, the description provides everything an agent needs: confirmation requirement, exact deletion scope, exceptions, and irreversibility. No output schema is present, but return value details are not necessary 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?

The schema fully documents projectId with 100% coverage, so the schema carries the parameter meaning. The description does not need to add parameter detail, though it also does not provide extra context beyond naming the target resource.

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, irreversible delete operation on the project resource and enumerates exactly what is destroyed (files, analytics, subdomain). This clearly differentiates it from sibling delete tools like delete_form, delete_data_collection, and delete_booking_page.

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 instructs the agent to confirm with the user first and warns that the action is irreversible. It also clarifies that attached forms, data collections, and booking pages are un-assigned rather than deleted, which helps the agent decide between delete_project and the more targeted sibling delete tools.

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?

Even though annotations already flag destructiveHint=true, the description adds crucial behavioral detail: reusing a project name redeploys in-place, hardcoded list content produces a broken build, and deploying alone is not the deliverable. It also discloses that the tool returns a live URL and references upload_media URLs rather than bundling images.

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

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

The description is dense and front-loaded with the most important workflow warning. Some phrasing is conversational and lengthy, but every major clause contributes actionable information rather than 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?

Given the tool's complexity and the absence of an output schema, the description is remarkably complete: it covers prerequisites, deployment constraints, post-deploy steps, destructive redeploy behavior, required file structure, and the return value. An agent has enough guidance to call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful constraints beyond the schema: files must be HTML/CSS/JS, text-only, include index.html at the root, and reference images via upload_media URLs. It also reinforces the redeploy behavior of the name parameter.

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

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

The description clearly states that the tool deploys a multi-file website from inline file contents, with a specific resource and required index.html. It is distinguishable from the sibling deploy_website by the 'multi-file' qualifier, though it does not explicitly name that sibling or contrast itself with it.

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

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

The description gives explicit workflow context: run the build order first, then deploy, then assign_to_project and configure_chatbot. It also warns against filesystem staging and hardcoded list content, but it does not explicitly state when to choose this tool over deploy_website for single-file sites.

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 mark destructiveHint=true, and the description reinforces and elaborates: 'reusing a project name redeploys it in-place.' It also discloses auto-linking of CSS/JS, the constraint on hardcoded content, and that the live URL alone is not a complete deliverable.

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

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

The description is long and emphatic, but its structure is front-loaded with the most critical warning and then proceeds logically: prerequisites, deployment behavior, post-deployment steps, and output. Every sentence carries meaningful workflow or constraint information, though some could be trimmed.

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 no output schema, it states the return type (live URL), explains redeployment semantics, sets the expected deliverable, and points to a guide for full rules. Given the complexity of the surrounding workflow, this is complete enough for an agent to deploy correctly and know what to do afterward.

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 adds semantic value beyond the schema by explaining how name controls redeploy behavior, that css/js are optional and auto-linked, and that html is the complete site content.

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: 'Deploys ONE self-contained HTML file' with optional CSS/JS and returns a live URL. It clearly distinguishes from the deploy_files sibling by emphasizing single-file deployment.

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 build-order prerequisite, warns against deploying before the order is complete, and lists required post-deploy actions. It also references get_guide('workflow') for full rules, making usage guidance unusually 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 readOnlyHint=true, so the description does not need to restate read-only behavior. It adds valuable context by explaining that the tool exposes plan limits, remaining capacity per feature, and reusable unassigned resources, which goes beyond the annotation and makes the tool's purpose and output scope transparent.

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

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

The description is a single dense sentence that front-loads the most important instruction ('Call this FIRST') and packs only high-value information: what is returned and how to use it. Every clause earns its place, and the parenthetical list of features is compact but meaningful.

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 burden of explaining return values, and it does so thoroughly: plan, usage, limits, the features matrix, and unassigned leftovers. It gives the agent everything needed to know when and why to call this tool and what to expect back.

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

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

The input schema has zero parameters and schema description coverage is 100%, so there is nothing for the description to document. The description correctly implies the tool takes no arguments and returns a full account overview, matching the baseline for a zero-parameter tool.

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

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

The description uses a specific verb ('Call this FIRST'), names the resource (the account), and lists exactly what it returns: plan, usage, limits, features matrix, and unassigned leftovers. It clearly distinguishes this account-level overview from the many project/resource-specific siblings like get_project and get_form.

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

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

It gives explicit when-to-use guidance: 'Call this FIRST on every build' and instructs the agent to 'design only within it.' It also provides a concrete decision rule — reuse unassigned leftovers before creating new ones — which contrasts with sibling creation tools like create_form and create_data_collection.

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 readOnlyHint annotation already signals safety, but the description adds meaningful behavioral context: the tool cannot change availability, and the agent should instead tell the owner what to change and where. This goes beyond the annotation and prevents misuse.

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

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

The description is compact and front-loaded with the core purpose, followed by a useful field inventory and a clear behavioral directive. Every element earns its place; 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?

With no output schema, the field list provides a strong expectation of return contents. The single parameter is fully covered by the schema plus provenance, and the read-only guidance fills the behavioral gap. Nothing essential is missing for an agent to select and invoke this tool correctly.

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

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

Schema coverage is 100% for the single pageId parameter, so the description doesn't need to explain the parameter itself. However, it adds value by specifying where the pageId comes from ('from get_project or list_booking_pages'), which helps the agent obtain a valid value.

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 ('Read') and resource ('one booking page in full') and lists the exact contents returned. It clearly differentiates this from sibling list_booking_pages by emphasizing full detail for one page.

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

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

The description clearly conveys this is the tool to use when a complete booking page snapshot is needed, and explicitly instructs the agent not to attempt edits. It doesn't name an alternative sibling for comparison, but the 'one page in full' wording implies when list_booking_pages would be more appropriate.

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, so the read-only safety profile is known. The description adds value beyond that by disclosing the return payload (settings plus full knowledge text) and by explaining the editing workflow this tool is meant to support. It doesn't need to restate the annotation, and it doesn't contradict it.

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 high-value. The purpose is front-loaded in the first sentence, and the critical workflow caveat about configure_chatbot is in the second. 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?

For a simple one-parameter read tool with a readOnly annotation, this description is complete. It tells the agent what the tool returns, when to call it, and how it relates to the sibling configure_chatbot. There is no output schema, but the description sufficiently covers the essential return information.

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 schema covers 100% of parameter documentation: projectId is described as 'The project's ID.' The description adds no further parameter-specific detail, but with complete schema coverage the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: 'returns the settings AND the full knowledge text.' It also explicitly names the sibling tool configure_chatbot, making the distinction clear. An agent can tell this is the read/precursor tool, not the mutation 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?

The opening 'EDITING A BOT? Call this FIRST' gives an explicit, conditional usage rule. It also explains why: configure_chatbot REPLACES the knowledge string with no merge, so the returned text must be edited and sent back in full. This is strong when-to-use and alternative-selection 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?

The readOnlyHint annotation already covers the safety profile, and the description adds useful behavior by listing exactly what the response contains: field schema, rows, public URL, and fetch snippet. This is especially valuable because there is no 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?

The description is a single front-loaded sentence with no filler. The main purpose is stated first, and the colon efficiently introduces the enumerated return contents.

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 the low complexity, single parameter, and readOnly annotations, the description is complete enough for an agent to select and invoke the tool. It explains what will be returned despite the lack of an 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 the description does not need to compensate for undocumented parameters. The description adds contextual meaning by framing collectionId as identifying 'one Dplooy Data collection,' but it adds no format or syntax details.

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 type, and scope: 'Get one Dplooy Data collection.' It also enumerates the returned content (field schema, rows, public URL, fetch snippet), which clearly distinguishes it from sibling tools like list_data_collections.

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 singular 'one' implies this tool is for retrieving a single collection by ID, while sibling list_data_collections is for multiple collections. However, there is no explicit when-to-use guidance, exclusions, or mention of alternatives.

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

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

Annotations declare readOnlyHint=true, and the description adds meaningful behavioral context beyond that: it states the tool never returns submissions because they contain visitor PII. This privacy boundary is useful and goes beyond the annotation's simple read-only signal, though it does not discuss error cases or authentication.

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 no wasted words. The first sentence front-loads the action and resource, lists the returned fields compactly, and the second sentence draws an important boundary about PII. Every clause earns its place.

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

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

For a single-parameter read-only tool with no output schema, the description is complete: it identifies the resource, enumerates the return contents, and states what is intentionally excluded. An agent has enough information to select and invoke this tool correctly.

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

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

The input schema already documents formId with full coverage (100%) and explains it comes from list_forms or get_project. The description does not add significant parameter-level detail beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Read') and resource ('one form endpoint'), then enumerates the exact fields returned: URL, assignment, active/paused, submission count, notification email, confirmation message, origin rule, and embed snippet. This clearly distinguishes it from list_forms and other get_* 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?

The description makes clear this is for reading a single form's configuration/metadata, not for retrieving submissions — it explicitly states submissions are dashboard-only and never returned. It does not explicitly name an alternative like list_forms, but the exclusion of submissions gives clear context on when not to use it.

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

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

The readOnlyHint annotation already communicates that this is a safe, non-mutating operation. The description adds scope and content context but does not describe response format or any other behavioral details. Since there is no output schema, a bit more about what the agent should expect as a return value would strengthen transparency.

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

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

The description is compact and well-ordered: it states the core function first, adds usage timing second, and finishes with a tidy topic list. No filler or redundant restatement of the schema.

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

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

For a single-parameter, read-only guide-fetching tool, the description covers what the tool does, when to use it, and all valid topics. The main gap is the lack of an explicit output format, but the term 'guide' and the listed content categories make the outcome reasonably predictable.

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 adds value by enumerating the valid topics and enriching the 'workflow' option with '(the full build order)', clarifying the guide's content categories beyond the schema's terse 'Which guide to fetch'.

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 uses a specific verb and resource: 'Get the full canonical guide' and explains what the guide contains (rules, schemas, plan limits, embed contracts). It clearly distinguishes this from sibling getters like get_project or get_form by framing it as a meta-guide for how Dplooy features work.

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

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

The description explicitly states when to use the tool: 'Call this BEFORE using a feature for the first time.' It does not discuss exclusions or alternative tools, but no sibling appears to offer the same guide functionality, so the when-to-use guidance is sufficient.

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 readOnlyHint annotation, the description discloses what the call returns: all attachments with IDs and keys, the prerendered vs client-only distinction, and an SEO warning when Data is fetched by browser fetch() only. It also communicates the behavioral rule that this is the authoritative source for attachments.

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

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

The description is tight and front-loaded: it opens with the usage trigger, lists the valuable return contents in one compact sentence, and closes with a one-line caution. No sentence is wasted.

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

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

For a one-parameter read-only tool with no output schema, the description provides enough about the response content and a key warning, so an agent knows exactly what to expect and why to call it. It also sets the broader editing workflow context, making the tool's role clear.

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 only parameter, projectId, is already fully described in the schema as 'The project ID to retrieve' (100% coverage). The tool description adds no extra parameter semantics beyond the context that the project is a site being edited, so the schema carries the load and 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?

The description names a specific action and object: calling this first gets 'the inventory of everything attached' to a site — forms, Data collections, booking pages, chatbot — with IDs and keys. This clearly differentiates it from siblings like get_project_files or get_form by focusing on the aggregate attachment inventory rather than a single resource.

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 explicitly gives the trigger: 'EDITING A SITE? Call this FIRST', and warns not to infer attachments from HTML or the live URL. It doesn't name specific alternative tools for when NOT to use this one, but the directive is clear enough for an agent to decide when to invoke it.

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

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

Beyond the readOnlyHint annotation, the description explains what the tool returns (full file inventory plus text contents), why served pages are not acceptable substitutes (injected runtime), and that stored files are the sole source of truth. This gives the agent a clear, safe behavioral model of the read operation.

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

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

The description is long but front-loaded with the most critical instruction and nearly every sentence carries operational value. It loses slight points because the closing point about forms/data/bookings surviving edits is more relevant to update_project_files than to this read tool.

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?

There is no output schema, so the description carries the burden of explaining return behavior, which it does: full inventory plus text contents, or just inventory with listOnly. Combined with complete parameter schema coverage and a clear read-only safety profile, the agent has everything needed 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 coverage is 100%, so the baseline applies. The description adds meaningful parameter guidance by recommending listOnly first on large sites and then fetching specific paths, and by clarifying that paths select files while omitting paths retrieves all text files. This goes beyond the schema's basic descriptions.

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 action and resource: reading the current live source files of a deployed Dplooy project. It further distinguishes itself from scraping the site URL and from the update tool, so an agent can tell exactly what this tool is for.

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

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

The description explicitly states when to call this tool (before editing an existing site), how to approach large sites (listOnly first, then fetch specific paths), and what not to do instead (never scrape the site, never rely on memory). It also names the correct follow-up tool, update_project_files, and warns against full redeploys.

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 readOnlyHint annotation already covers the non-mutating behavior. The description adds useful context about what data is returned (usage, project assignment, pending counts), but does not disclose pagination, response format, or potential limits. This is adequate but not rich.

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

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

Two short sentences front-load the main action and resource, then add the key output details. There is no filler or redundant restatement of the tool name.

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

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

For a no-input, read-only listing tool, the description is complete: it names the resource, the output highlights, and the safety profile is covered by annotations. The agent has enough information 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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics because there are none to explain.

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 uses a specific verb ('List'), identifies the resource ('Dplooy Bookings pages'), and clarifies the output scope ('with usage', 'assigned to projects', 'pending request counts'). This clearly distinguishes it from sibling tools like list_projects, list_forms, and get_booking_page.

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

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

The description establishes clear context for when to use this tool: when you need an overview of booking pages along with usage, project assignment, and pending request counts. It does not explicitly name alternatives or exclusions, but the use case is clear enough for an agent to select it.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful behavioral context by stating it shows public URLs and project assignments. It accurately describes a read-only listing operation without contradicting the annotation.

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 short sentences carry the full meaning: the first names the action and resource, the second details what the output shows. There is no redundant wording or filler.

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

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

For a zero-parameter read-only listing tool, the description sufficiently conveys purpose and output contents. The only minor gap is that 'usage' is not precisely defined, but it does not prevent an agent from selecting or invoking 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?

The input schema has no parameters, so there is nothing to document. The description does not need to clarify parameter meaning; the schema already defines that no arguments are accepted.

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 uses a specific verb ('List') and resource ('your Dplooy Data collections'), and specifies what the listing includes: usage, public URLs, and project assignments. This clearly distinguishes it from sibling tools like list_projects, list_forms, and get_data_collection.

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 tool's context is clear: use it to view a collection of data collections with usage and assignment details. It does not explicitly name alternatives or exclusion conditions, but the resource focus and output description make the intended use obvious.

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 the description adds useful behavioral context beyond that: the tool reports usage, project assignments, and inert status. These details help the agent understand what the tool exposes, though it does not describe pagination or exact output structure.

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

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

The description is two short sentences with no filler. The main action and resource are front-loaded, and the additional sentence adds meaningful output semantics without unnecessary detail.

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 listing tool, the description is nearly complete. It explains what will be listed and what kinds of information the results provide, though it does not specify the exact return shape or whether pagination is involved. Given the simplicity of the operation, this is a minor gap.

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

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

The tool has zero parameters, so the description carries no parameter documentation burden. With no inputs to explain, the baseline of 4 applies; there is nothing missing from the description in this dimension.

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 ('List'), a specific resource ('Dplooy Forms endpoints'), and an additional scope ('with usage'). It also clarifies what information is shown: which endpoints are assigned to projects and which are inert. This clearly differentiates it from sibling tools like get_form or list_booking_pages.

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

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

The description clearly conveys that this tool is for listing Dplooy Forms endpoints and their assignment/usage status. It does not explicitly name alternatives or state when not to use it, but the resource-specific scope makes the intended context obvious among the sibling tools.

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 readOnlyHint annotation already covers the safety profile, so the description's addition of concrete output details (public URLs and quota) is useful. However, it does not mention pagination, ordering, error behavior, or whether the quota is returned as usage/limit. With no output schema, this is a partial but adequate disclosure for a simple zero-parameter list.

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

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

The description is a single, tight sentence with the action and resource front-loaded. It contains no filler and every phrase adds useful 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 zero-parameter, read-only listing tool with a readOnlyHint annotation, the description is nearly complete: it states the purpose, the scope, and the key output elements. It does not describe the exact response shape or pagination, but given the low complexity this is a minor gap rather than a critical omission.

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 has zero parameters, so there is no parameter documentation burden. The baseline of 4 applies, and the description appropriately focuses on what the tool returns rather than parameter details.

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 uses a specific verb and resource: it states the tool will 'List images in the Dplooy Media Library' and clarifies the output includes public URLs and the account's image quota. This clearly distinguishes it from sibling tools like upload_media, delete_media, and other list_* operations without requiring schema inspection.

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

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

The description gives clear context for when to use the tool: when an agent needs to retrieve image URLs or check quota from the media library. It does not explicitly name alternatives or exclusions, but the read-only listing intent is obvious and the sibling list implies upload_media and delete_media handle mutations.

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 readOnlyHint annotation already indicates a safe read operation. The description adds meaningful behavior by specifying the 'deployed' scope and the exact fields returned (name, URL, type, size, views, status). Minor omissions like pagination behavior and default ordering are not disclosed, but the schema covers pagination parameters and defaults.

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

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

The description is two short sentences with no filler. The action and scope are front-loaded, and the second sentence efficiently lists what will be shown.

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 read-only list tool with fully documented parameters, the description is largely complete: it states scope and output fields. It could be slightly stronger by noting pagination behavior or directing users to get_project for detailed information, but these are minor gaps.

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 page and limit are already documented in the input schema. The description does not add additional parameter semantics, 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?

The description states a specific action ('List') on a specific resource ('all your deployed projects') and enumerates the returned fields. This clearly differentiates it from singular get_project and other list_* siblings by resource and scope.

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

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

The description implies the tool is used to get an overview of deployed projects, but it does not explicitly state when to choose this over get_project or other project-related tools. No exclusions or alternative routing are provided.

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 signal mutability and destructiveness, but the description adds substantial behavioral detail: objects go INERT, specific behavior for forms/data/booking pages, retained data, and reversibility via assign_to_project. This goes well beyond the annotations and gives the agent a full mental model of side effects.

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 dense sentences pack essential behavioral, contextual, and usage information with zero filler. The most critical insight ('nothing is deleted') is front-loaded, and the rationale is stated compactly.

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 the annotations and full schema coverage, the description covers what happens, what does not happen, the inert state consequences, data preservation, re-attachment path, and recommended usage scenarios. It is complete enough for an agent to decide when to invoke the tool and what to expect afterward.

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 schema already covers all three parameters with descriptions (100% coverage), so the description does not need to re-explain them. The description's grouping of 'forms, collections or booking pages' loosely maps to the parameter names but adds no new semantic detail beyond the schema.

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

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

States a specific verb ('Detaches') and the exact resources (forms, collections, booking pages) from their project, and explicitly contrasts itself with deletion ('nothing is deleted'). It clearly differentiates from delete_* siblings and names the complementary assign_to_project 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?

Gives explicit usage guidance: use before delete_* on something empty or to move an object between sites. It also names assign_to_project as the re-attachment mechanism, making the relationship to the key sibling 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?

The description goes far beyond the annotations by disclosing the ~1-minute republish delay, the atomic rejection of invalid rowIds/field ids with nothing changed, the untouched-state of unnamed rows, and the full-replace semantics of the rows parameter. These are behavioral traits an agent needs to predict side effects, and they complement the destructiveHint annotation consistently.

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

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

The description is dense and every sentence earns its place, but it is a long single paragraph with heavy use of capitalization and semicolons. This reduces scannability slightly, though the content is well-organized and front-loaded with the core purpose.

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

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

For a destructive, multi-mode mutation tool with no output schema, the description is remarkably complete. It covers all five parameters' operational semantics, failure behavior, id sourcing, image cell formatting, and publication timing. An agent has enough information to invoke the tool correctly and predict the main side effects.

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?

Although the schema already covers all parameters, the description adds critical semantic detail not present in the schema: image cells require { mediaId, path } from upload_media, row ids must come exactly from get_data_collection, unknown ids reject the whole patch, and rows only works for complete rewrites. This materially improves the agent's ability to construct correct calls.

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 clearly states a specific action and resource: updating a Dplooy Data collection's rows. It distinguishes between row-level operations and whole-set replacement, and it references get_data_collection and upload_media, helping an agent separate it from sibling tools. Even without reading the schema, an agent knows exactly what the tool does and its main operational modes.

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 guidance is explicit: rowEdits/addRows/deleteRowIds are marked PREFERRED, while rows is reserved for full rewrites. It also explains that deletion only happens through deleteRowIds and tells the agent where to obtain row ids and image media payloads. This leaves no ambiguity about when to use each mode.

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 indicate mutation (readOnlyHint=false, destructiveHint=true), but the description adds crucial behavioral detail: oldString is verified against the actual live file, exactly one match is required, the operation is all-or-nothing, untouched files are guaranteed unmodified, and only text files are supported. No contradiction with annotations.

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

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

The description is dense but every sentence earns its place. It front-loads the main purpose, then the prerequisite, then preferred mode, then alternatives and edge cases. Despite its length, it is well organized and scannable, with no filler.

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

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

For a destructive mutation tool with no output schema, the description is remarkably complete. It covers preparation, mode selection, failure semantics, atomicity guarantees, file-type limitations, and project-type restrictions. An agent has everything needed to invoke it safely and 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 each parameter well. The description adds meaningful extra semantics: preference for targeted edits over full rewrites, the single-file path '/' case, and multi-file-only restrictions for adding/deleting files. This goes beyond the schema without duplicating it.

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

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

The description opens with 'EDIT a deployed site', giving a specific verb and resource, and clearly distinguishes this from read-only tools like get_project_files. It also separates its modes (edits, files, deletePaths) internally, so an agent immediately understands what each mode does.

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

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

The description explicitly tells the agent to call get_project_files first and never edit from memory. It gives clear instructions on when to use targeted edits, full-file replacement, and deletePaths, and redirects images to the Media Library. This is model guidance for when and how to use the tool versus alternatives.

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

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

Beyond the annotations, the description adds valuable behavioral detail: the server downloads URLs directly, items succeed or fail independently, each image returns a stable public URL plus mediaId/path, and limits are stated (images only, max 5MB each). No contradiction with annotations exists.

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

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

The description is front-loaded with the primary instruction and every sentence carries operational weight. It is somewhat long and partially repeats schema-level details, but the added workflow and fallback rules justify the length.

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?

There is no output schema, yet the description discloses the return values (public URL plus mediaId/path), batching behavior, independent failure mode, and correct sequencing relative to site HTML generation. This is enough for an agent to invoke 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% and the schema already documents url/base64/filename thoroughly, including 'ALWAYS FIRST' and 'STRICT FALLBACK'. The top-level description restates this guidance but adds little new parameter-level meaning beyond a clear prose summary.

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

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

The description opens with a specific action and scope: 'Adds up to 16 images to the Media Library in ONE call.' It clearly distinguishes this from siblings like list_media and delete_media by framing it as the creation/upload operation.

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 guidance is explicit: use public URLs for web images, base64 only for self-generated images with no URL, never re-encode a URL image, batch all images into one call, and upload before writing HTML. It even points to list_media as an alternative when images already exist.

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