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

With no annotations, the description carries the burden. It discloses the mutation action, required API key, and the paid-plan caveat with actionable output (upgrade message and upgrade_url). This goes beyond a simple 'configure' statement and helps the agent anticipate failures.

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 the main action front-loaded and no unnecessary words. Every clause adds value, from the operation to the authentication requirement to the plan limitation handling.

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

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

The description covers the main edge case (paid-plan restriction) and identifies the required input (form_id, enabled) via the schema. It doesn't detail the success return value, but for a configuration tool that's acceptable. The absence of an output schema is mitigated by the clear action and error case.

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 all parameters. The description does not add extra meaning beyond what parameters exist (enabled, subject, body_html, etc.), making the baseline of 3 appropriate.

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

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

The description clearly states 'Enable, disable, or configure the auto-response email sent to people who submit a form', providing a specific verb and resource. It distinguishes the tool from siblings like create_form and get_submissions by focusing on auto-response configuration.

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 usage context: requires FORMSLIST_API_KEY and notes that auto-responses are a paid-plan feature. It explains what happens on plan limitations (relay upgrade message and upgrade_url), though it doesn't explicitly mention alternative 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?

With no annotations, the description carries the full burden. It discloses the authentication requirement and the scope (authenticated account), which is useful behavioral context. However, it omits details about the return value, potential side effects, or error conditions, which are relevant for a mutation 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?

The description is a single, concise sentence that front-loads the core action ('Create a new form') and then states the prerequisite. Every word earns its place with no redundancy.

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

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

The tool is simple and the schema covers parameters, but there are no annotations or output schema. The description mentions the API key requirement but does not specify what the tool returns after creation or any behavioral edge cases, leaving a notable gap for the agent's decision-making.

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 100% description coverage for both parameters (name and description), so the baseline is 3. The description adds no extra information about parameters, but the schema already provides adequate semantics.

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 'Create a new form' with a specific verb and resource, and specifies the context of the authenticated FormsList account. This distinguishes it from sibling tools like get_form, list_forms, and get_submissions, which are read-oriented.

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 provides clear context by mentioning the required FORMSLIST_API_KEY and the authenticated account, indicating when this tool is applicable. It does not explicitly state exclusions or alternatives, but the create intent is unambiguous relative to 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?

No annotations are present, so the description carries the full burden. It explicitly states 'Pure local generation — no API key, no network', indicating the tool is offline and non-destructive. It also discloses the output (HTML snippet plus AJAX example), which is substantial for a codegen tool.

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

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

Two sentences, front-loaded with the core purpose. Every clause adds value: the first sentence defines the deliverable, the second specifies local execution and input format. 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 simple snippet generator without an output schema, the description covers the key aspects: deliverable, local execution, and accepted input. It does not detail validation or exact string representation, but these are not critical for the tool's simplicity.

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 baseline is 3. The description reiterates the endpoint_or_hash accepted formats but adds no new meaning beyond the schema's parenthetical. The fields parameter is left to the schema, which already provides a default.

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 'Build a ready-to-paste HTML form snippet', which is a specific verb and deliverable. It clearly distinguishes itself from sibling CRUD tools by emphasizing 'Pure local generation — no API key, no network.'

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 the use case for generating an embed snippet for an existing FormsList endpoint. It provides input guidance ('Pass either the full endpoint URL... or just the form hash') but does not explicitly name alternative tools or exclusion criteria.

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?

No annotations are provided, so the description carries the full burden. It adds useful behavioral context: requires FORMSLIST_API_KEY and returns settings, endpoint, and submission counts. It does not cover error handling or rate limits, but for a read operation this is acceptable.

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 sentences, front-loaded with the purpose and quickly adding the auth requirement. Every word earns its place with 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 simple read tool with one parameter and no output schema, the description adequately covers the key aspects: what it does, what it returns, and the required key. It doesn't specify the response structure, but that is less critical here.

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 has one parameter, form_id, with description 'The form ID', yielding 100% schema coverage. The description adds no further parameter meaning, so the baseline score 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 uses a specific verb and resource: 'Get details of a single form' with a parenthetical listing of what details (settings, endpoint, submission counts). This clearly distinguishes it from siblings like list_forms and get_submissions.

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 when to use the tool: when you need details of a single form, as opposed to listing all forms or getting submissions. It provides clear context but does not explicitly name alternatives or state 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?

With no annotations, the description carries the full burden. It discloses pagination behavior and the API key requirement, which are useful non-obvious details. However, it does not describe response format, error behavior, or whether the operation is read-only (though 'get' implies it). Gaps remain for a read tool with 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 two short sentences, front-loaded with the primary purpose ('Get submissions for a form') and includes the essential auth note. Every word contributes value, with no fluff or redundancy.

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

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

For a simple paginated read tool with three parameters and no output schema, the description covers purpose, pagination, and auth. It does not explain return values, but the nature of the tool makes this inferable. The description is sufficiently complete for the tool's complexity.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds no extra meaning beyond the restatement that results are paginated, which relates to page and per_page but does not explain their mechanics. Thus, the baseline 3 is appropriate.

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

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

The description clearly states the tool retrieves submissions for a form, which is a specific verb+resource pair. It is distinguished from sibling tools like get_form (form details) and list_forms (form list) by the resource type (submissions vs forms). The pagination note further clarifies 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 when to use this tool: whenever you need form submissions. It provides clear context without explicitly naming alternatives or exclusions. The mention of the required API key is a useful prerequisite, though it does not explicitly contrast with 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?

With no annotations provided, the description carries the burden and does well by disclosing the instant creation, zero-account requirement, ownership claiming via claim_url, and the exact return artifacts (endpoint URL, claim_url, html_snippet, curl_example). It omits potential side effects like email validation or uniqueness constraints, but core behavioral transparency is strong.

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

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

The description is two sentences with no wasted words. It front-loads the primary action and constraint, then lists the return values and claim process succinctly. Every clause adds 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?

Since there is no output schema, the description appropriately lists all returned items. It explains the ownership handoff and provides enough context for an agent to decide to use it. It doesn't cover edge cases like duplicate emails or rate limits, but for a simple instant-provisioning tool the core information 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?

The schema already documents both parameters fully (email receives notifications, form_name is optional). The description adds no additional parameter-level meaning, so with 100% 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 clearly states the action ('Create a working form endpoint instantly') and the resource ('for any email'). It differentiates from siblings by highlighting 'no account needed' and the claim_url flow, making its unique purpose unmistakable.

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 notes 'no account needed' and describes the claim-later mechanism, which implies when this tool is appropriate. However, it does not explicitly contrast it with sibling tools like create_form or state when not to use it, so it stops short of full exclusion 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?

No annotations are available, so the description carries the full burden. It discloses the authentication requirement (FORMSLIST_API_KEY), which is useful behavioral context, but it does not mention pagination, rate limits, or the shape of the returned data. The behavior is a simple read/list, which is mostly inferable, but some additional detail would improve 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 two sentences, concise, and front-loaded with the primary action. Every sentence adds value: the first states the function, the second states the required credential. No filler or redundancy.

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

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

Given the tool's simplicity (no parameters, no output schema), the description provides a complete picture: what it does and the prerequisite auth. It is sufficient for an agent to select and invoke the tool without additional 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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics; it adds context about the authenticated account, which is sufficient.

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 the verb 'List' and the resource 'all forms in the authenticated FormsList account', which explicitly differentiates it from sibling tools like get_form (single form) and get_submissions. The scope is precise and 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?

The description implies usage when the agent needs to retrieve all forms from the account, but it does not explicitly mention alternatives or when not to use it. For example, it does not point to get_form for single-form retrieval or note any prerequisites beyond authentication, so guidance is implicit rather than explicit.

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