ShipMyForm

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a structural limitation (OAuth connectors cannot be added here) and the dependency on list_connector_types, but says nothing about auth requirements, whether the new connector is active immediately (a sibling set_connector_active exists), validation failures, or duplicate handling.

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

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

Three tight sentences with the core action front-loaded, then the config prerequisite, then the hard exclusion. 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 mutation tool with no annotations and no output schema, the description covers the essential gaps: where to get valid types and config fields, and which connectors are unsupported. It falls short only on post-creation state (active vs inactive) and error behavior, which an agent might need given the sibling set_connector_active tool.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema, including that 'type' comes from list_connector_types and that 'config' is keyed by config field names. The description reinforces the list_connector_types lookup but adds no new syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Route a form's submissions') and enumerates concrete destination types (email, webhook, Slack, Discord, Airtable, HubSpot, Telegram). This clearly separates it from siblings like list_connectors, remove_connector, and test_connector.

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

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

Gives an explicit prerequisite ('Get the config fields from list_connector_types') and an explicit exclusion ('OAuth connectors (Google Sheets, Notion) must be added in the dashboard'). It routes the agent to the correct sibling tool for the config payload and rules out an unsupported path.

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 and does well: '(shown once)' warns the agent the secret is not retrievable later, and 'a key can never grant scopes it does not itself hold' discloses the privilege-escalation constraint. It omits return shape and any rate/permission limits, but the key behavioral risks are covered.

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

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

Two tight sentences, front-loaded with the core action and followed by the safety-relevant constraint. 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?

For a mutation tool with no annotations and no output schema, the description covers the two things an agent most needs: that the key is shown once and that scopes cannot exceed the caller's. Minor gaps remain around naming rules and any limits on how many keys can exist.

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

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

Schema coverage is 67%, with preset and scopes already documented. The description adds meaning beyond the schema by explaining the privilege ceiling on scopes ('never grant scopes it does not itself hold'), though it says nothing about the required '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?

States a specific verb (mint) and resource (API key for this workspace), immediately distinguishing it from list_api_keys and revoke_api_key. The parenthetical scope qualifier further sharpens what kind of key is produced.

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 context for when to use it: handing a limited key to another agent. It doesn't explicitly name sibling alternatives (list_api_keys, revoke_api_key), but the use case and its safety framing make selection 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?

With no annotations, the description carries the full burden, and it does disclose useful behavior: the returned endpoint + HTML snippet, automatic email notifications to the account owner, and no plan gating. However, it omits authorization requirements, duplicate-name behavior, and failure modes for a mutating 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?

Three short sentences, front-loaded with the core action and return value; no filler. 'Works on every plan' justifies itself by preempting a plan-limit check, though it reads slightly promotional.

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 create tool with no output schema and no annotations, the description covers the primary return value and the notable side effect (automatic notification setup). It is close to sufficient, with auth and error behavior the only real omissions.

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, purpose, and allowedDomains with examples. The description adds no parameter-level meaning beyond that, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('Create a form') and goes further by naming what the caller receives: an endpoint plus a paste-ready HTML snippet. It does not explicitly distinguish itself from siblings like get_form_snippet or update_form, so sibling ambiguity is only partially resolved.

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?

There is no guidance on when to choose this over update_form, get_form, or get_form_snippet, and no prerequisites or exclusions are stated. 'Works on every plan' is a constraint removal rather than usage direction.

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 supplied, so the description bears the full behavioral burden. It does disclose one meaningful downstream effect — the form's endpoint stops accepting submissions — which is real context beyond the schema. However, it omits the traits that matter most for an irreversible mutation: permanence of deletion, whether existing submissions/data are also destroyed, and any auth requirements.

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

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

A single short sentence with the action front-loaded and the consequence trailing. Nothing is padded or redundant.

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

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

For a one-parameter tool with no output schema, the definition is serviceable, but a destructive operation with zero annotation coverage should at least state that the deletion is irreversible and what happens to the associated submissions. Those omissions leave a meaningful hole for an agent deciding whether to call it.

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

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

Schema coverage is 100% for the single formId parameter, including a format example ('frm_abc123'), so the schema fully documents the input. The description adds no extra semantics, which is the expected baseline of 3 when the schema does the work.

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

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

The description gives a specific verb (Delete) plus resource (form), so the action is unambiguous. It does not, however, distinguish itself from the nearby 'delete_submissions' sibling, which an agent could plausibly confuse with form removal; the clarification that deletion targets the form itself and not its submissions has to be inferred.

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?

There is no when-to-use guidance, no mention of the alternative tools (delete_submissions, update_form, create_form), and no prerequisites such as permissions or confirmation. The agent gets a definition of the operation but no routing 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that deletion is permanent and that associated files are removed too (a cascade side effect), but it omits auth/permission requirements, batching behavior, or what happens with unknown/invalid ids.

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

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

One short sentence that is front-loaded with the verb and free of filler. However, brevity comes at the cost of leaving important behavioral details unstated for a destructive operation.

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

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

For a permanent, destructive, batch operation with no annotations, no output schema, and 0% parameter coverage, the description is too thin. It should at minimum clarify the id list semantics and whether deletion is recoverable or requires elevated permissions.

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 0% and the description never mentions the single 'ids' parameter. It does not explain the array format, the 1-200 item bounds, or how invalid ids are handled, so it fails to compensate for the schema gap.

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

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

States a specific verb ('delete') and resource ('submissions'), and differentiating it from delete_form is easy since the resource names differ. It does not explicitly name or contrast with siblings, but the purpose is unambiguous at a glance.

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 offers no when-to-use guidance, no mention of alternative tools (e.g., delete_form for individual forms), and no preconditions. Usage is only implied by the name.

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 disclosure burden. It usefully reveals the 2,000-record cap and the CSV-text return format, but says nothing about read-only nature, permissions, truncation behavior beyond the cap, or pagination.

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

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

A single sentence with zero filler; the record cap and format are front-loaded, and the optional filter is stated last. Nothing is repeated from the title.

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

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

For a simple two-parameter export with no output schema, the description supplies the essentials: what is returned (CSV text), the cap, and the filter. Missing only edge-case behavior such as what happens past 2,000 records, which 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?

Schema coverage is 50%: formId is documented in the schema, while status only exposes an enum. The description confirms status is an optional filter, but adds no meaning beyond what the enum values (ok/spam/flagged) already convey, so it does not compensate for the coverage gap.

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

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

States a specific verb (export), resource (a form's submissions), and output format (CSV text), which implicitly separates it from list_submissions and get_submission. It stops short of naming the sibling alternatives explicitly, so differentiation is inferred rather than 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 phrase 'optionally filtered by status' hints at a parameter, not at when to pick this tool over list_submissions, get_submission, or get_submission_stats. No prerequisites, no exclusions, no alternative routing is given.

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

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

With no annotations, the description carries the full behavioral burden. 'Get' and the returned-field enumeration imply a safe, parameterless read, which is meaningful context, but it says nothing about auth requirements, whether it returns a cached or live account, or any rate limits.

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

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

A single front-loaded sentence that lists the payload fields with zero filler. It is efficiently sized, though the missing leading verb makes it read as a fragment rather than a fully self-contained statement.

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 usefully compensates by enumerating the returned fields — the key information an agent needs. For a zero-parameter getter this is nearly complete, with only the lack of auth/usage framing as a 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 takes zero parameters, so per the rubric this is a baseline 4. There are no parameter semantics to clarify and the description correctly does not invent any.

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 the specific resource and enumerates the account fields returned (email, verification state, plan, limits, usage, dashboard URL), which tells an agent exactly what data this fetches. It lacks an explicit verb, but the title 'Get account' plus the field list make the purpose unambiguous. It does not distinguish itself from sibling retrieval tools like get_billing_portal or verify_account.

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?

There is no statement of when to call this tool versus alternatives such as get_billing_portal or verify_account, nor any prerequisites or exclusions. The agent must infer usage from the field list alone.

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 behavioral burden. It says the result is a self-service URL with billing actions, but does not disclose authentication requirements, whether the call itself is read-only, how long the URL lasts, or that plan/card/cancel changes happen in the portal rather than through this tool.

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

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

It is brief and front-loads the portal URL idea, but it is a sentence fragment and packs the key usage context into a colon-separated list rather than a clear directive. It avoids waste but is under-structured for the routing job.

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 tool with no output schema, the description conveys that the return is a URL and what the user can do there. It is still incomplete on when to choose it over billing-related siblings and on auth/expiry details, so it is minimally adequate rather than fully self-contained.

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

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

The tool takes zero parameters and schema description coverage is 100%, so there is no parameter semantics for the description to add. The baseline for a zero-parameter tool 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 identifies the resource ('self-service billing portal URL') and the user actions it enables ('change plan, update the card, cancel'), so the agent can tell it returns a portal link rather than performing billing mutations. It does not explicitly name or differentiate against siblings such as start_upgrade, so it stops short of a 5.

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

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

There is no statement of when to call this tool, when not to call it, or which sibling to use instead. The implied use case (let a user manage billing) is clear from the capability list, but the description leaves all routing guidance to inference.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the returned content surface (configuration, connectors, hosted-page status), which is useful since there is no output schema, but it says nothing about read-only semantics, required credentials, or error behavior for a missing form.

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

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

A single economical phrase with no filler and the payload scope stated immediately. It is arguably too terse (an incomplete sentence), but nothing 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 tool with no annotations and no output schema, the description is minimally sufficient: it names what the response contains. It omits the safety profile and any usage context, leaving clear 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% – formId is documented with an example ('frm_abc123') – so the schema does the heavy lifting. The description adds no additional meaning about the identifier format or lookup behavior, making the baseline 3 appropriate.

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

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

The phrase identifies the resource (a form) and the scope of its payload (full configuration, connectors, hosted-page status), but it is a sentence fragment with no verb, so the operation itself is only inferred. It also does nothing to separate this from get_form_snippet or list_forms, which an agent could plausibly reach for instead.

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?

There is no statement of when to call this versus the sibling tools (get_form_snippet, list_forms, update_form). The single-form lookup is only implied by the required formId in the schema, not by any prose 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?

With no annotations, the description carries the full burden. It usefully discloses the output artifact (a code snippet, not structured data), which matters since there is no output schema, but says nothing about read-only nature, auth/permission requirements, or whether generating a snippet has any 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?

A single economical sentence with the artifact front-loaded. Every clause earns its place; it loses a point only for being a noun phrase with no explicit action verb to orient the agent.

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 2-parameter read/generation tool with no output schema, the description covers what comes back and one parameter's role, but omits when to prefer it over get_form, any auth requirements, and what the snippet content actually contains. Adequate but with clear 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 coverage is 50% (framework has no description). The description re-lists the enum values already visible in the schema and clarifies that the snippet is 'wired to the form's endpoint,' which ties formId to a meaningful effect, but adds no format details on formId beyond the schema example.

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 concrete output — a copy-paste form snippet wired to the form's endpoint — in one of four frameworks, which is specific and distinguishable from get_form (which returns form data). It never uses an explicit verb, but the resource and artifact are 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?

There is no when-to-use guidance, no mention of prerequisites, and no reference to siblings like get_form or create_form that an agent might confuse this with. The agent must infer that this is for generating integration code rather than reading form data.

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 behavioral burden. It discloses the payload contents (spam signals, delivery history), which is genuine added value, but says nothing about permission requirements, behavior on a nonexistent ID, or whether the lookup is scoped to the caller's account.

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

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

A single economical sentence with the resource front-loaded and no filler. It is efficient, though its brevity reflects under-specification rather than tight editing.

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 annotations and no output schema, the description is the only source of behavioral signal, and it does usefully preview the return contents. However, it omits the parameter's meaning and any usage context, leaving the definition only minimally complete for a lookup tool.

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

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

Schema description coverage is 0% and the description never mentions submissionId — where it comes from or what format it takes. The single parameter is self-evident from its name, but the description contributes nothing beyond the schema.

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

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

The description names a specific resource ('One submission') and enumerates what it carries ('spam signals and delivery history'), which distinguishes it from list_submissions and get_submission_stats. It stops short of an explicit retrieval verb, but the intent is unambiguous from the name-plus-description pairing.

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?

There is no guidance on when to fetch a single submission versus list_submissions or get_submission_stats, and no prerequisites or conditions are stated. The agent must infer usage purely from the tool name.

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 disclosure burden. It does add one genuinely useful behavioral fact — universal plan availability — which likely matters given many siblings are plan-gated. However, it never states that this is a safe read-only operation, its auth requirements, or whether counts are sampled/realtime, leaving a mutation-vs-read ambiguity an agent shouldn't have to resolve.

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, zero filler, with the payload (the return contents) front-loaded and the availability caveat trailing. Nothing is padded and every clause carries information.

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

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

There is no output schema, so the description must convey return contents — and it does, naming the three count categories plus quota usage. For a one-parameter stats tool that is nearly sufficient; only the response shape/refresh behavior is left unstated, which 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?

Schema description coverage is 100% and the single formId parameter is fully documented with an example, so the schema does the heavy lifting. The description's phrase "for a form" reinforces the scoping but adds no syntax or format detail beyond what the schema already provides. Baseline 3 is correct.

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

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

The description states exactly what the tool returns: delivered/spam-held/flagged counts for a form plus workspace quota usage. That is a specific resource and metric set, clearly distinct from get_submission (single item) and list_submissions (enumeration). It stops short of explicitly naming those siblings, so it is clear but not fully self-differentiating.

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?

"Works on every plan" is an availability caveat, not usage guidance. There is no statement of when to reach for this versus list_submissions or get_submission, and no mention of prerequisites. An agent must infer the use case from the name alone.

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 full behavioral burden, and it discloses a genuinely non-obvious side effect: spam/ok labels 'teach the classifier, so your judgement improves future filtering,' while flagged evidently does not. It omits reversibility, permissions/auth needs, and the 200-item batch limit, leaving gaps for a tool with zero annotation coverage.

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

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

Three short sentences, front-loaded with the core action followed by the behavioral consequence and the workflow. Efficient and well-ordered; the middle clause is slightly promotional but still earns its place by conveying the learning effect.

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

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

For a simple two-parameter tool with no output schema or annotations, the description covers purpose, the triage workflow, and the classifier-feedback behavior. Missing details on what labeling does to existing classifier state, whether labels are reversible, and the batch maximum keep it just short of complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the label enum by glossing 'ok' as 'not spam' and explaining the classifier effect of spam/ok, but it says nothing about the 'ids' array (that it takes submission IDs, up to 200 per call). Partial compensation only.

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

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

States a specific verb+resource ('Mark submissions') and enumerates the three possible labels with a clarifying gloss ('ok (not spam)'), so the action is unambiguous. It does not explicitly contrast itself with siblings like delete_submissions or export_submissions, but the verb 'mark/label' is inherently distinct from delete/list/export. Clear but no explicit sibling differentiation, so a 4.

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 a workflow cue: 'This is how you triage in your own environment: list, decide, label,' which points to listing first (list_submissions) and then labeling. However, it names no explicit when-not condition and no alternative tools, so it is context without 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?

No annotations are provided, so the description carries the full disclosure burden. It does add one genuinely useful behavioral fact — that the response is metadata only, i.e. secret key material is not returned — but it says nothing about permissions required, whether the result is paginated or complete, or what 'metadata' includes.

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

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

A single short phrase with no filler, and the key qualifier ('metadata only') is placed where it will be read. It is arguably too terse to be well-formed prose, but it is not padded or buried.

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

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

For a simple zero-parameter list tool with no output schema and no annotations, the description covers the essential safety-relevant fact (no secret material returned). It stops short of describing what the list contains, ordering, or any limits, leaving the agent to discover the return shape empirically.

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 takes no parameters and has 100% coverage, so there is nothing for the description to clarify. Baseline of 4 applies 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 names the resource (API keys) and scopes it to 'this workspace', so an agent can tell it apart from create_api_key and revoke_api_key, which mutate the same resource. It is a noun phrase rather than an explicit verb+resource, but the name and the read-only framing make the purpose 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?

There is no statement of when to call this versus create_api_key or revoke_api_key, no prerequisites, and no conditions or exclusions. The only implicit guidance is the phrase 'metadata only', which hints at a read-side inspection use case but is never framed as usage advice.

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 does disclose the shape of the result ('status and last error'), which is genuinely useful behavioral context, but it says nothing about pagination, ordering, permissions, or behavior when the form has no connectors.

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

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

A single efficient sentence with zero filler, and the resource being acted on is stated first. It is arguably under-specified rather than over-verbose, which is a completeness problem rather than a conciseness one.

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 with no output schema, the description is minimally adequate: it names the scope (a form) and the returned fields. It omits pagination/limits and connector identity details, which an agent would need if a form has many connectors.

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

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

Schema description coverage is 100% and there is exactly one parameter (formId, with an example), so the schema already does the work. The description adds no syntax, format, or scoping detail beyond it, making the baseline 3 correct.

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

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

The name and title give a clear verb+resource ('List a form's connectors'), and the description adds what is returned (status and last error). It does not differentiate from the sibling list_connector_types or explain how it differs from test_connector, so it stops short of a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the closely related siblings (list_connector_types, test_connector, add_connector). The agent must infer usage entirely from the name.

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 at all, the description carries the full burden. It usefully discloses what each entry contains (config fields, required plan), which is real behavioral context beyond a bare 'list' statement, but says nothing about ordering, pagination, or whether results are static catalog data versus account-scoped.

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

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

One dense sentence with the payload described first and the per-entry contents appended. Nothing is wasted and nothing important is buried.

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

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

For a zero-param read-only catalog listing with no output schema, telling the agent that entries include config fields and plan requirements is sufficient to know what comes back. The missing piece is scope (global catalog vs. account-filtered), which matters for routing decisions.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies.

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

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

States a specific resource (connector types) and what the listing contains: config fields and required plan. It is distinguishable from the sibling list_connectors, which returns the account's configured connectors rather than the available catalog, though the description never names that distinction explicitly.

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

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

The phrase 'Every destination submissions can be routed to' implies the tool is used when picking a routing destination, but there is no explicit when-to-use, no prerequisite, and no mention of the add_connector/list_connectors alternatives an agent might confuse it with.

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 behavioral burden. It discloses one return characteristic (public endpoint URLs are included) but says nothing about ordering, pagination, result size, or required permissions for a workspace-wide enumeration.

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

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

A single short, front-loaded sentence with no filler. It is slightly fragmentary and could carry one more routing clause without bloat, but nothing 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 zero-parameter list tool with no output schema and no annotations, the description covers the resource and one output field but omits pagination, ordering, and the shape of the returned form objects, which an agent may need to use the results correctly.

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

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

The tool takes zero parameters and schema coverage is 100%, so there are no parameter semantics to add; the baseline of 4 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 the resource (the workspace's forms) and what is returned (their public endpoint URLs), making the operation identifiable as a bulk read. It does not use an explicit verb like 'list' in the body text and gives no differentiation from the sibling get_form, so an agent still has to infer the contrast.

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?

There is no statement of when to use this tool versus get_form or the other listing tools such as list_submissions. Usage for enumerating all forms in a workspace is only implied by the noun phrase.

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 burden and does disclose two non-obvious traits: spam is excluded unless status='spam', and a paid plan is required. These are meaningful behavioral/auth facts not derivable from the schema. It stops short of describing pagination behavior or return shape, so it isn't fully complete.

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

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

Two tight sentences: purpose and scope first, then the filter inventory, then the spam and plan caveats. Front-loaded and free of filler, though the parenthetical filter list is dense.

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

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

For an 11-parameter read tool with no annotations and no output schema, the description covers purpose, filters, spam behavior, and plan gating. It still leaves pagination mechanics, sort options, and several parameter semantics unaddressed, so gaps remain given the low schema coverage.

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 45% (below 50%), so the description should compensate more than it does. It maps filters to status, date range, text search, country, attachments, and failed deliveries, but leaves sort, limit, offset, and formId semantics unexplained (limit max 100, offset paging, enum values).

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

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

States a specific verb (read/list) and resource (submissions) with explicit scope ('across the workspace or for one form') and enumerates the supported filters. It is clearly distinguishable from get_submission (single), delete_submissions (removal), and export_submissions, though it doesn't name any sibling to contrast itself.

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

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

Usage is implied by the scope statement and the list of filters, and it notes the paid-plan prerequisite. However, it gives no explicit when-to-use-vs-when-not guidance and never names an alternative tool (e.g. get_submission_stats or export_submissions) for adjacent needs.

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 behavioral burden. It usefully discloses the return payload (URL + embed script) and a fallback branch (designed page vs. default email+message form), but says nothing about idempotency, what republishing does to an existing page, or permission requirements for a mutation.

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

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

Two sentences, zero filler, front-loaded with the primary action and outcome before the fallback clause. Every sentence earns its place.

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

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

For a one-parameter mutation with no output schema, the description adequately covers what the tool produces and its internal branching. It leaves minor gaps around republish/overwrite semantics and auth, which keeps it from a 5.

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

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

Only one parameter (formId) and schema description coverage is 100%, so the schema already documents it fully. The description adds no syntax, format, or constraint details beyond the schema, making the baseline 3 appropriate.

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

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

Names a specific verb+resource (publish a hosted form page) and states the concrete outcome: a URL on shipmyform.com plus an embed script. Distinct from siblings like get_form_snippet and unpublish_hosted_page, which an agent can tell apart without opening schemas.

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

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

Gives clear context for when this applies ('standalone page ... no website needed'), which implies the alternative embedding flows. It never explicitly names the alternative tool or an exclusion, so it stops short of the 5-level when/when-not 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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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 must carry the behavioral burden, and it does disclose the code format (6 digits), the delivery channel (email), and the destination (the account's address). It omits rate limits, auth requirements, and whether a fresh code invalidates the previous one, so the disclosure is partial.

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

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

A single front-loaded sentence with no filler; every word (fresh, 6-digit, account's address) adds precision.

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, no-output-schema action the description is nearly sufficient: the agent knows exactly what will happen. It only lacks usage context (when to trigger it) and any note on side effects or throttling.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly reflects this by identifying the target (the account's address) rather than any caller-supplied argument.

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 (email/resend), resource (6-digit verification code), and destination (account's address), which is far more concrete than the title alone. However, it does not distinguish itself from siblings like verify_account or sign_up, leaving the agent to infer the relationship.

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?

There is no explicit when-to-use guidance, no prerequisites (e.g., must be signed in, code previously sent), and no mention of alternatives such as verify_account. The word 'resend' implies a prior send failed or was not received, but this is left to inference.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses the self-revocation restriction, but says nothing about whether revocation is permanent/irreversible, what permissions are required, or what error results if the id is unknown or already revoked.

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, front-loaded sentences with zero filler; the core action comes first and the constraint second.

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-param destructive tool with no annotations and no output schema, the description covers the essential action and one notable edge case, but omits irreversibility, permissions, and failure behavior, leaving meaningful 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 0%, so the schema does not define keyId. The phrase "by id" identifies the parameter's meaning at a minimal level, but adds no format, source, or constraint detail beyond that.

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

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

States a specific verb+resource ("Revoke a key by id"), which an agent can distinguish from create_api_key and list_api_keys without opening schemas. It doesn't explicitly call out sibling alternatives by name, so it stops short of a 5.

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

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

Provides an implied usage rule plus one hard constraint: the key authenticating the current connection cannot revoke itself. However, there is no explicit when-to-use/when-not guidance relative to alternatives (e.g., list_api_keys to find the id first).

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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 provided, so the description carries full burden, and it does real work: it discloses that this is step one of a two-step flow, that no browser/auth is needed, that a code is emailed, and that the API key only materializes after verify_account. It omits code expiry, rate limits, and what happens on repeated invocations.

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

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

Three tight sentences, front-loaded with purpose, then the verification flow, then the edge case of an existing account. No filler and every clause is load-bearing.

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?

Without an output schema, the description correctly explains where the API key comes from (verify_account) rather than leaving the return value mysterious, and it covers the unauthenticated and existing-account cases. Remaining gaps around code lifetime and re-invocation behavior are minor for a bootstrap tool.

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

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

Schema coverage is 80%, so the schema already documents email, agent, preset, scopes, and workspaceName. The description adds only the email input and the verify_account { email, code } shape, contributing little beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb+resource ("Start a ShipMyForm account") plus the delivery mechanism (6-digit emailed code) and explicitly distinguishes its role from the sibling verify_account. An agent can tell this apart from create_api_key or verify_account without opening any schema.

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

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

Gives clear context: works without authentication, works for existing accounts (code approves API access), and names verify_account as the mandated next step. It stops short of explicitly contrasting with create_api_key (the other key-provisioning sibling), but the two-step flow is unambiguous.

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

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

With no annotations, the description carries the full burden and does well: it discloses that payment happens out-of-band by a human on the hosted page, that activation is automatic and asynchronous, and that the agent should poll get_account. It does not cover auth requirements, whether repeated calls create multiple checkout sessions, or expiry of the URL.

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

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

Two tight sentences, front-loaded with the return value (checkout URL) and followed by the activation flow; every clause earns its place with no filler.

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

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

For a two-parameter tool with no output schema and no annotations, the description adequately covers the return value, the human-in-the-loop payment step, and the follow-up check. It leaves gaps on error/edge behavior (already subscribed, abandoned checkout) and the period parameter.

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 0%, so the description must explain both parameters and does not: the 'period' monthly/annual option is never mentioned. Worse, it names the plans 'Starter or Business' while the enum values are starter/pro, introducing a label that conflicts with the schema rather than clarifying 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?

States a concrete verb+resource ('Get a hosted checkout URL') for upgrading to a paid plan, which cleanly separates it from siblings like get_billing_portal, sign_up and get_account. Minor deduction because it labels the plans 'Starter or Business' while the schema enum is starter/pro, so the agent cannot fully trust the plan vocabulary.

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

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

Usage is implied clearly (call this to begin a paid-plan upgrade) and it names get_account as the post-payment verification step. However it gives no when-not guidance, no mention of get_billing_portal as the alternative for managing an existing subscription, and no prerequisite/eligibility conditions.

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 does disclose a meaningful behavioral trait beyond the name: an actual test delivery is sent, i.e. a real side effect, not a dry-run validation. However it says nothing about failure handling, rate limits, or whether the connector's state is affected by a failed test.

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

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

A single front-loaded sentence with no filler; the action and outcome lead. Slight penalty only because the same brevity leaves the gaps noted elsewhere unaddressed.

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 annotations, no output schema, and an undocumented required parameter, the description is too thin for a tool that triggers a real outbound delivery. It should describe what "result" reports, failure behavior, and prerequisite connector state.

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

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

There is one parameter with 0% schema description coverage, so the schema documents nothing about connectorId. The description adds no meaning — it never says where the ID comes from (presumably list_connectors) or what format it takes, leaving the parameter entirely undocumented.

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 ("Send a test delivery through a connector") plus the outcome ("report the result"), which is distinct from siblings like add_connector, remove_connector, and set_connector_active. It does not explicitly name those siblings, but the testing action is self-evidently different.

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

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

Usage is implied — you call this to verify a connector works — but there is no explicit when-to-use, no prerequisite (e.g. connector must exist and be active), and no reference to alternatives such as list_connectors to obtain an ID.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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

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

Tool has no description.

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?

Tool has no description.

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 and does disclose two non-obvious behaviors: a one-time API key is returned on success, and email notifications get turned on as a side effect. That is genuinely useful disclosure beyond the schema, though it omits retry limits, code expiry, and the scope implications of the request.

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

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

Three short sentences, each carrying distinct information (action + code source, conditional email + return value, side effect), with the essential mechanics front-loaded and 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?

There is no output schema, so the description's disclosure that an API key is returned once is exactly the missing piece an agent needs. Combined with the conditional-email rule and the notification side effect, it is largely complete, with only the 'agent' parameter and error/expiry behavior unexplained.

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

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

Schema coverage is 60%, so the baseline is 3. The description reinforces the conditional email requirement and explains the notable return value, but the 'agent' parameter is documented nowhere and preset/scopes semantics are left entirely to the schema 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?

States a specific action (prove/verify the account email) with the exact mechanism (6-digit code emailed by sign_up), which anchors it among the many account tools. It doesn't explicitly differentiate itself from resend_verification_code, but the code-generation source is named, so an agent can place it correctly.

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?

Implies the usage window by referencing sign_up as the code source and gives one concrete conditional (pass email when not connected with a key). It never states what to do with an expired/rejected code or routes to resend_verification_code as the alternative, so guidance is implied rather than explicit.

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