Read forms, fields, entries, reports and comments by field title, and submit entries.
Scored across 18 tools
The verb_noun naming plus explicit descriptions make nearly every tool distinct: count vs list pairs, form vs report variants, and webhook add/delete are clearly separated. The only mild overlap is wufoo_list_form_entries vs wufoo_get_labeled_entries (same data, different keying), but the descriptions explicitly explain the difference, so misselection is unlikely.
Every tool uses the wufoo_ prefix followed by a consistent verb_noun pattern (add_webhook, count_form_entries, get_form_fields, list_reports, submit_entry). Resource scoping (form/report/comments/widgets/users) is applied uniformly and predictably.
18 tools is slightly heavy but well within a reasonable range for a platform API covering forms, entries, reports, widgets, comments, users, and webhooks. Each tool maps to a distinct endpoint and none feels redundant or filler.
Read coverage is thorough across forms, entries, comments, reports, widgets, and users, and writes cover entry submission and webhook add/delete. Minor gaps remain: no single-entry get, and no entry update/delete or form creation, though the Wufoo API itself largely does not support these, so the surface is close to complete for the domain.
WRITE: adds a webhook to a form, so Wufoo POSTs every new entry to the given URL. Idempotent per URL: calling again with the same URL updates its handshake key / metadata setting instead of adding a duplicate. Forms allow at most 10 integrations. Returns WebHookPutResult.Hash — keep it, it is needed to delete the webhook. Wufoo: PUT /forms/{identifier}/webhooks.json.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL Wufoo will POST each new entry to. | |
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| metadata | No | Include form/field structure in each POST (Wufoo default false). | |
| handshakeKey | No | Shared secret Wufoo includes in each POST so the receiver can reject unwanted requests. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the single destructiveHint annotation: it discloses idempotency semantics (updates handshake key/metadata instead of duplicating), a hard limit of 10 integrations per form, the exact return field to retain (WebHookPutResult.Hash), and the underlying endpoint (PUT /forms/{identifier}/webhooks.json). No output schema exists, and the description compensates by naming the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads 'WRITE:' as a mutation marker, then packs idempotency, the limit, the return contract, and the raw endpoint into a few dense sentences. Every sentence carries operational information 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 4-param mutation with no output schema, the description covers everything an agent needs: safety profile, idempotency, quota, and the return value that must be stored for later deletion. Nothing material to correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the field docs: it explains that idempotency is keyed on the URL and that handshakeKey/metadata are updated on re-invocation. The form identifier reference ('See wufoo_list_forms' in the schema) is complemented by the endpoint pattern here.
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 (adds a webhook) and resource (to a form) with the concrete effect (Wufoo POSTs every new entry to the given URL). It also distinguishes itself from the delete side of the lifecycle by noting the returned hash is needed for deletion, so an agent can tell it apart from wufoo_delete_webhook.
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: idempotent per URL, so repeat calls update rather than duplicate, and the 10-integration cap constrains when it can be used. It references the downstream action (delete) but stops short of an explicit 'use X instead when...' routing statement, so it is strong context rather than full 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.
Count all comments on a form's entries. Returns {Count}. Wufoo: GET /forms/{identifier}/comments/count.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes the safe-read profile, so the description is not carrying the safety burden. It adds genuine context beyond the annotations: the exact return shape ('Returns {Count}') and the underlying API call (GET /forms/{identifier}/comments/count.json), which tells the agent this is a cheap non-paginated aggregate call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, front-loaded statements: what it does, what it returns, and which endpoint backs it. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by naming the return shape ({Count}), and the single required parameter is covered by the schema. Minor residual gaps remain (e.g. whether the count spans all entries and whether deleted/spam comments are included), but nothing blocks a correct call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single 'form' parameter is fully documented in the schema, including its hash/URL-title forms and a pointer to wufoo_list_forms. The description adds nothing beyond that, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Count all comments on a form's entries'), which cleanly distinguishes it from the listing sibling (wufoo_list_form_comments) and from the entry-counting siblings (wufoo_count_form_entries, wufoo_count_report_entries). An agent can pick this tool 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?
The counting semantics imply when to use it (when only a total is needed rather than the comment records), and the sibling list makes the list/count split inferable. However, there is no explicit 'use this instead of X when Y' statement or any prerequisite guidance, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count a form's entries — all of them, or only those matching filters (same filter format as wufoo_list_form_entries). Useful to plan paging. Returns {EntryCount}. Wufoo: GET /forms/{identifier}/entries/count.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| match | No | Combine filters: AND (all must match, default) or OR (any). | |
| filters | No | Entry Manager-style filters (up to 10), sent as Filter1, Filter2… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description goes further by disclosing the return shape ({EntryCount}) and the underlying endpoint, plus the fact that filters reuse the list_form_entries convention — genuinely useful context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences, front-loaded with the operation and scope, then use case, then return contract. Nothing is redundant and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the operation, its filtering scope, the return field, and the endpoint for a read-only count tool with only one required parameter. Since readOnlyHint is set and the return value is stated, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents form, match, and filters. The description adds a cross-reference to wufoo_list_form_entries for filter format, but no additional syntax or semantics beyond that; baseline 3 is appropriate when the schema carries the load.
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 (Count) and resource (form entries) and immediately scopes it: all entries or only those matching filters. Distinguishes itself from siblings like wufoo_count_form_comments and wufoo_count_report_entries by targeting form entries specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the practical purpose explicitly — 'Useful to plan paging' — which tells the agent when to reach for it, and points to wufoo_list_form_entries as the source of the matching filter format. It lacks an explicit when-not or a note on when a full list is preferred, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count the entries in a report. Returns {EntryCount}. Wufoo: GET /reports/{identifier}/entries/count.json.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | Report identifier: its permanent hash (e.g. qa4d98l1ib9or7) or its URL title. See wufoo_list_reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description usefully discloses the return shape ({EntryCount}) and the underlying endpoint, which matters since there is no output schema, but it adds nothing about permissions or limits. This is modest added value on top of annotations, not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and immediately followed by the return shape and endpoint. No filler, every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only count, the description plus full schema coverage and the readOnlyHint leave little ambiguity about correct invocation. The only gap is a cross-reference to wufoo_list_report_entries for the list-vs-count decision, which is a minor omission rather than a blocking one.
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 exists and schema description coverage is 100%: the schema itself documents the report identifier format, length bounds, and points at wufoo_list_reports. The description mentions '{identifier}' in the endpoint string but adds no new meaning — baseline 3 is correct when the schema does all 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?
'Count the entries in a report' states a specific verb (count) plus resource (report entries), and the 'report' scope cleanly separates it from the sibling wufoo_count_form_entries and wufoo_count_form_comments. An agent knows exactly what is counted without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says what the tool does but never says when to use it versus wufoo_list_report_entries (list vs count) or the form-level count sibling. No prerequisites, no exclusions, no alternative routing — the agent must infer the choice 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.
WRITE: removes a webhook from a form; the receiving URL stops getting new entries immediately. Needs the webhook hash returned by wufoo_add_webhook (Wufoo has no endpoint to list webhooks). Wufoo: DELETE /forms/{identifier}/webhooks/{webhookHash}.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| hash | Yes | Webhook hash (WebHookPutResult.Hash from wufoo_add_webhook). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the bar is lower, yet the description adds real substance: the receiving URL stops getting new entries immediately, and the hash must be sourced from wufoo_add_webhook because Wufoo cannot list webhooks. That is useful operational context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with the 'WRITE:' marker, then the effect, then the prerequisite, then the raw endpoint. Every clause earns its place; slightly dense but no waste.
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-param destructive tool with no output schema, the description covers the mutation effect, the hash prerequisite, and the missing-list-endpoint caveat. Nothing an agent needs to call it correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both 'form' and 'hash', including the pattern and provenance. The description reinforces the hash's origin but adds no syntax or format detail beyond the schema — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'removes a webhook from a form'. The 'WRITE:' prefix and the deletion semantics distinguish it clearly from the read/list siblings, and it explicitly contrasts with wufoo_add_webhook.
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?
Explains the prerequisite for use — you need the webhook hash from wufoo_add_webhook, and notes there is no list endpoint, which is essential context for selecting this tool. It does not spell out explicit when-not-to-use conditions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one form's settings by hash or URL title — name, description, confirmation message, notification emails, public flag, language, start/end dates, entry limit and links. Wufoo: GET /forms/{identifier}.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| includeTodayCount | No | Include EntryCountToday. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the concrete field set returned and maps the call to the upstream endpoint (GET /forms/{identifier}.json), but says nothing about auth requirements, rate limits, or behavior when the identifier is invalid.
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 tight single sentence that front-loads the verb and resource, followed by a short endpoint reference. The endpoint tag is marginally redundant but grounds the call in the upstream API; nothing else 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?
With no output schema, the description carries the burden of conveying what comes back, and it does list the returned settings. Minor gaps remain (no error/not-found behavior, no mention of the optional includeTodayCount flag), but an agent has enough to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented in the schema, including the hash-vs-URL-title distinction. The description echoes the identifier form but adds no syntax or format detail beyond the schema, and never mentions includeTodayCount. 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 ('Fetch one form's settings') and enumerates the returned fields (name, description, confirmation message, notification emails, public flag, language, dates, entry limit, links). The singular 'one form' plus the identifier-based lookup clearly separates it from the sibling wufoo_list_forms.
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 it ('by hash or URL title') and the schema points to wufoo_list_forms for discovering identifiers, but there is no explicit when-not guidance or named alternative for related reads like wufoo_get_form_fields. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The field structure of a form: each field's Title, Type, API ID (Field###, used for filters, sorting and submissions), required flag, default value and page. Checkbox, name, address and likert fields list SubFields with their own IDs; multiple-choice, dropdown and likert fields list Choices. Admin-only fields are not returned. Wufoo: GET /forms/{identifier}/fields.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| system | No | Include system metadata (IP, LastPage, CompleteSubmission, payment Status/PurchaseTotal/Currency/TransactionId/MerchantType). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint, so the description carries most of the burden and delivers: it discloses that checkbox/name/address/likert fields nest SubFields and that choice-style fields nest Choices, and that admin-only fields are omitted. This is meaningful return-shape behavior beyond the annotations, though pagination/error/rate behavior is unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence front-loads the resource and then systematically enumerates attributes and nesting rules with zero filler. It is packed but every clause carries information; the endpoint reference is a compact addition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must convey the return shape, which it does by listing field attributes and nested SubFields/Choices. It omits any note on how the `system` parameter alters the payload, but overall it is sufficient for correct invocation and interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are fully documented in the schema, establishing the baseline of 3. The description adds nothing about the `system` flag and only reinforces the form-identifier semantics already covered by 'See wufoo_list_forms' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: 'the field structure of a form,' then enumerates the attributes returned (Title, Type, API ID, required flag, default, page). It is distinguishable from wufoo_get_form (metadata) and wufoo_get_report_fields by the 'form' + 'fields' framing, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is only implied by the note that the API ID is 'used for filters, sorting and submissions,' which hints at why an agent fetches fields, but the tool is never contrasted with alternatives like wufoo_get_form or wufoo_get_report_fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a page of a form's entries with every Field### key replaced by the field's human title — e.g. "Email", or "Title — Label" for sub-fields of checkbox, name, address and likert fields ("Name — First", "Address — City"). EntryId, DateCreated and the other default/system keys stay as they are. Empty values are dropped unless includeEmpty is set. Also returns fieldIds (title → API ID) for building filters or submissions. Takes the same paging, sorting and filter arguments as wufoo_list_form_entries. Wufoo: GET /forms/{identifier}/fields.json + /entries.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| sort | No | Field API ID to sort by (e.g. EntryId, DateCreated, Field105). | |
| match | No | Combine filters: AND (all must match, default) or OR (any). | |
| system | No | Include system metadata (IP, LastPage, CompleteSubmission, payment Status/PurchaseTotal/Currency/TransactionId/MerchantType). | |
| filters | No | Entry Manager-style filters (up to 10), sent as Filter1, Filter2… | |
| pageSize | No | Entries per page (1-100; Wufoo default 25). | |
| pageStart | No | Zero-based index of the first entry to return (default 0). | |
| includeEmpty | No | Keep empty-string and null values (default false: they are omitted). | |
| sortDirection | No | ASC (default) or DESC. Only applies together with sort. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes the safety profile, but the description adds real behavioral context beyond annotations: keys are remapped, default/system keys (EntryId, DateCreated) are left alone, empty values are dropped unless includeEmpty is set, and a fieldIds map is returned. It does not cover rate limits or error behavior, so it falls short of exhaustive, but it meaningfully enriches the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The text is dense but front-loaded: the transformation (the reason to call this tool) comes first, followed by defaults, then return contents. The inline examples add length but also precision. It is slightly heavy for a single paragraph but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of describing returns, and it does: entries keyed by title, preserved system keys, dropped empties, plus fieldIds. Combined with 100% schema coverage for the 9 parameters and readOnlyHint, an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, and the description rises above it: it explains the includeEmpty default interplay with dropped empty values and explains what fieldIds is for (building filters or submissions). The cross-reference to wufoo_list_form_entries also tells the agent the paging/sort/filter parameters behave identically.
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 (fetch a page of entries) plus the distinctive transformation that defines this tool: every Field### key replaced by its human title, with sub-field naming rules. That transformation is exactly what separates it from the sibling wufoo_list_form_entries, so an agent can route between them without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says it "takes the same paging, sorting and filter arguments as wufoo_list_form_entries," which references the alternative but only for argument reuse, not for routing. There is no explicit statement of when to pick this tool over wufoo_list_form_entries or when the title-keyed view is undesirable (e.g. numeric key stability), so usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one report by hash or URL title. Wufoo: GET /reports/{identifier}.json.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | Report identifier: its permanent hash (e.g. qa4d98l1ib9or7) or its URL title. See wufoo_list_reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the description's remaining job is to add context. It only restates the REST endpoint ('GET /reports/{identifier}.json') with no disclosure of error behavior, identifier-resolution fallbacks, or what a report object contains.
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 identifier forms stated up front. Nothing to trim and nothing important buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool whose annotation covers safety, this is close to sufficient. However, there is no output schema, so the description could usefully hint at what a report contains or that no entries are returned here; that gap keeps it at minimum-viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the single 'report' parameter is already fully documented with an example hash and a cross-reference. The description's 'by hash or URL title' merely echoes the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one report') and clarifies the identifier can be a hash or URL title. The 'one report' framing implicitly separates it from wufoo_list_reports, but it never names or contrasts with that sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance is given: nothing says when to prefer this over wufoo_list_reports or how the identifier is obtained. The pointer to wufoo_list_reports lives only in the schema's parameter description, not in the tool description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The field structure of the form a report is built on (same shape as wufoo_get_form_fields). Wufoo: GET /reports/{identifier}/fields.json.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | Report identifier: its permanent hash (e.g. qa4d98l1ib9or7) or its URL title. See wufoo_list_reports. | |
| system | No | Include system metadata (IP, LastPage, CompleteSubmission, payment Status/PurchaseTotal/Currency/TransactionId/MerchantType). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, and the description adds the raw endpoint (GET /reports/{identifier}/fields.json) plus the fact that output mirrors wufoo_get_form_fields. That shape hint is useful, but there is no disclosure of auth needs, pagination, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, resource stated first, sibling cross-reference and endpoint afterward. No filler; 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?
With annotations covering read-only safety and the description pointing at wufoo_get_form_fields for output shape, an agent has enough to call it correctly. No output schema exists, and the description partly compensates via the shape reference, though it stops short of describing the actual fields returned.
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 'report' (hash or URL title) and 'system' (system metadata toggle) are fully documented in the schema. The description adds only the endpoint path and does not enrich either parameter beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific resource (the field structure of the form underlying a report) and explicitly anchors it against the sibling wufoo_get_form_fields by noting the identical shape, so an agent can separate 'report's base-form fields' from 'form fields directly'. The retrieval verb is implied rather than stated, which keeps it just short of a clean 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?
It names a comparable sibling to clarify return shape but gives no when-to-use/when-not guidance and no selection criteria between wufoo_get_report_fields, wufoo_get_form_fields, wufoo_get_report, or wufoo_list_report_widgets. The agent must infer the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the comments team members left on a form's entries in the Entry Manager: CommentId, EntryId, Text, CommentedBy, DateCreated. Optionally only for one entry. Page with pageStart/pageSize (max 100). Wufoo: GET /forms/{identifier}/comments.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| entryId | No | Only comments on this EntryId. | |
| pageSize | No | Comments per page (1-100; Wufoo default 25). | |
| pageStart | No | Zero-based index of the first comment (default 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description goes further by disclosing the returned field set (valuable since there is no output schema), the source (Entry Manager), and the underlying endpoint (GET /forms/{identifier}/comments.json), adding real context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then packs field list, optional filter, pagination, and endpoint into a tight, waste-free block. Every fragment contributes information an agent needs.
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 read-only list tool with 100% schema coverage and a readOnly annotation, listing the returned fields compensates for the absent output schema, and pagination plus the optional filter are covered. Only minor behavioral detail (e.g., default page size context) is left implicit in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents form, entryId, pageSize, and pageStart fully. The description's mentions of 'Optionally only for one entry' and pagination largely restate the schema, warranting the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the comments team members left on a form's entries') and enumerates the returned fields (CommentId, EntryId, Text, CommentedBy, DateCreated), which cleanly separates it from sibling tools like wufoo_list_form_entries and wufoo_count_form_comments.
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 notes the optional single-entry narrowing ('Optionally only for one entry'), which implies a valid usage mode, but never tells the agent when to pick this over wufoo_count_form_comments or wufoo_list_form_entries. Usage is inferable but no explicit when/when-not or 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.
List a form's submitted entries (as in the Entry Manager), keyed by field API ID (Field105…) plus EntryId, DateCreated, CreatedBy, DateUpdated, UpdatedBy. Filter like the Entry Manager (Filter1=Field105 Contains foo, combined with match AND/OR), sort by any field ID, and page with pageStart/pageSize (max 100). For entries keyed by human field titles use wufoo_get_labeled_entries. Wufoo: GET /forms/{identifier}/entries.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| sort | No | Field API ID to sort by (e.g. EntryId, DateCreated, Field105). | |
| match | No | Combine filters: AND (all must match, default) or OR (any). | |
| system | No | Include system metadata (IP, LastPage, CompleteSubmission, payment Status/PurchaseTotal/Currency/TransactionId/MerchantType). | |
| filters | No | Entry Manager-style filters (up to 10), sent as Filter1, Filter2… | |
| pageSize | No | Entries per page (1-100; Wufoo default 25). | |
| pageStart | No | Zero-based index of the first entry to return (default 0). | |
| sortDirection | No | ASC (default) or DESC. Only applies together with sort. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered and the description is not required to re-state it. It does add useful behavior beyond the annotations: the underlying call is GET /forms/{identifier}/entries.json, filters are mapped onto Wufoo's Filter1/Filter2 wire format, and the response shape (field API IDs plus EntryId, DateCreated, CreatedBy, DateUpdated, UpdatedBy) is described for a tool with no output schema. No auth or rate-limit detail, but nothing is contradicted or misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences, front-loaded with the resource and its keying scheme, then the alternative pointer, then the raw endpoint. Every clause carries information (keying, filter syntax, sort, paging cap, sibling routing, endpoint) with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter read tool with no output schema, the description covers the essentials: what comes back (field API IDs plus system columns), how to filter/sort/page, and where to go for the title-keyed alternative. Return-value information is present precisely because no output schema exists, and the read-only annotation handles the safety dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3 and the schema carries the per-parameter burden. The description adds meaning on top: it shows the concrete filter wire syntax ('Filter1=Field105 Contains foo, combined with match AND/OR') and confirms paging limits and sort-by-field-ID semantics in prose, which helps the agent compose correct calls rather than just read field docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('List a form's submitted entries') with concrete scope details: keyed by field API ID plus system fields, filterable like the Entry Manager, sortable, paginated. It explicitly names the sibling it is not (wufoo_get_labeled_entries), so an agent can distinguish it from the title-keyed variant and from the count/list_report siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing rule: use this tool when entries should be keyed by field API ID, and use wufoo_get_labeled_entries when human field titles are wanted. It also states the operative mechanics (Filter1=Field105 Contains foo with AND/OR, sort by any field ID, page with pageStart/pageSize max 100), which tells the agent how to apply the tool rather than merely what it is.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the forms the API key's user can access: name, description, hash (permanent identifier), URL title, public/private, start/end dates, entry limit, created/updated timestamps. Set includeTodayCount to add EntryCountToday. Wufoo: GET /forms.json.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default 1). | |
| limit | No | Forms per page (1-1000; Wufoo default 1000). | |
| includeTodayCount | No | Include EntryCountToday, the number of entries received today. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real value by disclosing the returned fields and clarifying the includeTodayCount behavior. It stops short of noting pagination or auth/rate-limit behavior, but with annotations present this is solid.
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 densely packed sentences, front-loaded with the action and scope, then the return fields, then the API route. Every clause earns its place, especially the field enumeration given the absence of an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the field enumeration and the endpoint hint give the agent enough to call and interpret it correctly. Only minor items like pagination semantics are omitted, and those live in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so page and limit are fully documented in the schema, and includeTodayCount's meaning is already in the schema description that the text mirrors. The description adds essentially nothing beyond the structured fields, 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 ('List the forms the API key's user can access') and immediately enumerates the resource scope. An agent can distinguish it from the singular sibling wufoo_get_form without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'the forms the API key's user can access' implies the context of use, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many list_* siblings. Usage is inferable but not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The entries that make up a report — what its datagrid widget or an export would show, keyed by field API ID. Wufoo documents no paging or filter parameters for this endpoint. Wufoo: GET /reports/{identifier}/entries.json.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | Report identifier: its permanent hash (e.g. qa4d98l1ib9or7) or its URL title. See wufoo_list_reports. | |
| system | No | Include system metadata (IP, LastPage, CompleteSubmission, payment Status/PurchaseTotal/Currency/TransactionId/MerchantType). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. Beyond that, the description usefully discloses that there are no paging or filter parameters, preventing an agent from attempting unsupported pagination, and notes the entry keying by field API ID. It stops short of describing auth needs or 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?
Two efficient sentences plus the endpoint reference, front-loaded with what the entries are. Slightly dense but no filler; the no-paging note 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 read-only list tool with no output schema, the description conveys enough: what the return contains (report entries as a datagrid/export would show, keyed by field API ID) and the absence of paging/filtering. Would benefit from a pointer to the sibling used for filtered or labeled retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself documents both parameters, including that 'system' pulls IP/payment metadata and that 'report' accepts a hash or URL title with a cross-reference to wufoo_list_reports. The description adds nothing new about parameters, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (list report entries) and adds real meaning with 'what its datagrid widget or an export would show, keyed by field API ID,' which clarifies the data shape. It distinguishes the resource from form entries by noun, but does not explicitly contrast with siblings like wufoo_list_form_entries or wufoo_get_labeled_entries.
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?
No statement of when to use this versus alternatives. The only constraint given is that Wufoo documents no paging or filter parameters, which is a limitation note, not routing guidance. An agent gets no help choosing between this and wufoo_get_labeled_entries or wufoo_list_form_entries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the reports the API key's user can access: name, description, hash, URL title, public flag and created/updated timestamps. Wufoo: GET /reports.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, so the description is not obligated to restate it. It does add genuinely useful behavior: it enumerates the returned attributes (name, description, hash, URL title, public flag, timestamps), which compensates for the absent output schema. It stops short of mentioning pagination or result limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the verb and scope, followed by the endpoint reference. The field enumeration is longer than minimal but earns its place since no output schema exists. 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 zero-parameter, read-only list tool, everything an agent needs is present: scope, read semantics via annotations, and the shape of the returned records. The absence of an output schema is offset by the inline field list.
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 implies a no-argument listing call scoped by the API key and introduces no misleading parameter expectations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource ('List the reports') and scopes it to 'the API key's user can access', which is more precise than a bare list tool. It does not explicitly name or contrast against siblings like wufoo_get_report or wufoo_list_report_widgets, so differentiation is left to inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use or when-not-to-use guidance, and no alternative tool is named (e.g., 'use get_report for a single report'). The only implicit clue is the scope phrase 'the API key's user can access', which hints at the auth context but does not route the agent between options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The chart, graph (pie/bar/line) and big-number widgets on a report: Name, Type, TypeDesc, Size and Hash (the hash embeds the widget). Text and datagrid widgets are not returned. Wufoo: GET /reports/{identifier}/widgets.json.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | Report identifier: its permanent hash (e.g. qa4d98l1ib9or7) or its URL title. See wufoo_list_reports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true already covering the safety profile, the description adds genuine behavioral context: the exact fields returned and the filtering rule that excludes text/datagrid widgets. It stops short of noting pagination or ordering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A compact, front-loaded sentence listing returned fields followed by the exclusion and the raw endpoint. Dense but every clause carries information; no wasted padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by enumerating the fields returned (Name, Type, TypeDesc, Size, Hash) and what is filtered out. For a single-parameter read-only list tool this is close to complete, though pagination/ordering details are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the sole 'report' parameter is fully documented in the schema (hash or URL title, pointing to wufoo_list_reports). The description only restates the endpoint URL template and adds nothing 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?
The description names the specific resource (chart, graph and big-number widgets on a report) and enumerates the returned fields, so an agent knows exactly what this tool yields. It is clearly distinguishable from siblings like wufoo_get_report or wufoo_list_reports.
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 provides an implicit exclusion ('Text and datagrid widgets are not returned') that helps scope selection, but it never states when to reach for this tool versus wufoo_get_report or other report siblings, nor any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's users: name, email, timezone, company, owner/admin flags and create-forms/reports/themes permissions. Each user's API key is redacted from the result. Wufoo: GET /users.json.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, and the description adds the non-obvious behavioral detail that each user's API key is redacted from the result. It also lists the visible returned fields and the underlying GET endpoint, though it does not mention pagination or 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?
Two tightly written sentences front-load the resource and returned fields, then add the important redaction behavior, and finally identify the endpoint. Every element 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 simple read-only list operation with no parameters, an empty schema, and no output schema, the description supplies the return fields and the API-key redaction detail. Nothing essential for correct invocation appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics for the description to clarify. The empty schema and zero-parameter baseline make 4 the appropriate score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: listing the account's users, and it enumerates the returned fields (name, email, timezone, company, owner/admin flags, permissions). No sibling tool covers user listing, so the purpose is immediately distinguishable from form, report, entry, and webhook tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the operation itself, but the description provides no explicit when-to-use guidance, prerequisites, or alternatives. For a simple read-only list endpoint this is minimally adequate, though an agent must infer that it is the only user-listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
WRITE: submits a new entry to a form, exactly as if someone filled it in — it is stored and triggers the form's notifications, webhooks and integrations. Keys are field API IDs from wufoo_get_form_fields (Field1, Field105…); fields with sub-fields (name, address, checkbox) take one key per sub-field ID. Dates must be YYYYMMDD. Field validation and form limits still apply: a rejected submission returns each field error. Limited by Wufoo to 50 submissions per user per 5 minutes. Wufoo: POST /forms/{identifier}/entries.json.
| Name | Required | Description | Default |
|---|---|---|---|
| form | Yes | Form identifier: its permanent hash (e.g. s1afea8b1vk0jf7) or its URL title (e.g. wufoo-api-example). See wufoo_list_forms. | |
| fields | Yes | Values keyed by field API ID, e.g. {"Field1": "Ada", "Field2": "Lovelace", "Field217": "20260315"}. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true, yet the description discloses substantial behavior beyond that: the entry is stored and triggers notifications, webhooks and integrations; validation failures return per-field errors; and there is a hard rate limit of 50 submissions per user per 5 minutes. It even names the underlying endpoint POST /forms/{identifier}/entries.json.
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?
Dense but front-loaded: the write nature leads, followed by key format, date format, failure behavior, and rate limits in that order. Every sentence carries information an agent needs to call this correctly; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter write tool with a nested object and no output schema, the description covers the nested keying scheme, the date format, failure semantics, throttling, and the sibling needed to discover field IDs. There is no material gap left for an agent to guess.
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 already 100%, so the baseline would be 3, but the description adds genuinely new meaning: the fields object is keyed by field API IDs obtained from wufoo_get_form_fields, sub-fielded fields (name, address, checkbox) require one key per sub-field ID, and dates must be formatted YYYYMMDD.
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 ('submits a new entry to a form') and prefixes it with 'WRITE:' so the agent immediately separates it from read siblings like wufoo_list_form_entries and wufoo_get_labeled_entries. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies the use case (creating an entry as if filled in by a person) and routes to the sibling wufoo_get_form_fields for obtaining the required field API IDs, plus wufoo_list_forms is referenced in the schema for the form identifier. It doesn't state when NOT to use it or name an alternative for bulk submission, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
wufoo_add_webhook1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_count_form_comments1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_count_form_entries1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_count_report_entries1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_delete_webhook1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_get_form1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_get_form_fields1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_get_labeled_entries1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_get_report1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_get_report_fields1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_form_comments1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_form_entries1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_forms1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_report_entries1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_report_widgets1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_reports1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_list_users1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_submit_entry1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"wufoo_add_webhookwufoo_count_form_commentswufoo_count_form_entrieswufoo_count_report_entrieswufoo_delete_webhookwufoo_get_formwufoo_get_form_fieldswufoo_get_labeled_entrieswufoo_get_reportwufoo_get_report_fieldswufoo_list_form_commentswufoo_list_form_entrieswufoo_list_formswufoo_list_report_entrieswufoo_list_report_widgetswufoo_list_reportswufoo_list_userswufoo_submit_entryBuild, preview, edit, publish and analyze forms and surveys; read responses and manage webhooks.
Browse Formstack forms, submissions and webhooks, search responses, and create submissions.
Forms, submissions, workflows and reports in Faldaro, exactly as privileged as your API key.
Read Fillout forms and submissions, export responses, and create submissions and webhooks.
Add one secure layer between your agents and this server.
