Read forms, fields, entries, reports and comments by field title, and submit entries.
Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 18 tools
Most tools target a distinct resource+action (form vs report vs entry vs comment vs webhook vs user), and count/list/get variants are cleanly separated. The one real overlap is wufoo_list_form_entries vs wufoo_get_labeled_entries, which return the same underlying entries with different keying; the descriptions explicitly cross-reference each other, so the confusion cost is low but not zero.
Every tool uses the wufoo_ prefix followed by a consistent verb_noun pattern (list_forms, get_form, count_form_entries, submit_entry, add_webhook, delete_webhook). The scope qualifier (form/report) is placed predictably inside the name, making the whole set easy to scan.
18 tools is on the heavy side but justified: the surface covers four resource families (forms, entries, reports, webhooks/users) plus counts, so most tools earn their place. A couple of near-duplicates (get_labeled_entries, get_report_fields) push it slightly above ideal.
Read coverage is strong (forms, fields, entries, comments, reports, widgets, users), and entry creation plus webhook add/delete are present. However the entry lifecycle is one-way: no update-entry or delete-entry, no single-entry fetch, no single-comment or comment creation, and forms/reports have no create/update/delete, leaving notable dead ends.
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 sparse destructiveHint annotation: discloses idempotency semantics (same URL updates handshake key/metadata rather than duplicating), the 10-integration quota, the returned WebHookPutResult.Hash and why to retain it, and the underlying API endpoint. This is exactly the mutation-behavior context an agent needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, front-loaded with the WRITE marker and the core action; each sentence (idempotency, quota, return value, endpoint) carries distinct 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?
With no output schema, the description compensates by naming the returned field and its downstream use; it also covers quota limits, idempotency, and the API route. Nothing material is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both required and optional parameters are already documented in the schema. The description's mention of the handshake key and metadata setting is consistent with the schema but adds little new syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'WRITE: adds a webhook to a form' — a specific verb plus resource — and explains the effect (Wufoo POSTs every new entry to the given URL). This clearly separates it from sibling wufoo_delete_webhook and the read-oriented list/get 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?
Explains the triggering behavior and the idempotency rule so an agent knows re-calling with the same URL is safe, plus the hard cap of 10 integrations per form. It stops short of explicitly naming delete_webhook as the alternative operation, though it alludes to needing the returned hash to delete.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by specifying the return shape ({Count}) and the underlying GET endpoint, which is useful for an identifier-only count operation with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no wasted words. The core action is front-loaded, followed by the return shape and endpoint reference, making it easy to parse quickly.
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 count tool with full schema coverage, annotations for safety, and no output schema, the description supplies the missing return-value information. Nothing an agent needs in order to call it correctly 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?
Schema coverage is 100% and the single form parameter is fully documented in the schema, including examples and a pointer to wufoo_list_forms. The description adds no parameter information beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: counting comments on a form's entries. It is clearly distinguishable from sibling tools like wufoo_list_form_comments (listing vs counting) and wufoo_count_form_entries (entries vs 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?
Usage is implied by the description's count-focused purpose, but there is no explicit when-to-use guidance or mention of alternatives such as wufoo_list_form_comments. The agent can infer the tool's role, but routing guidance is absent.
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 the safety profile is covered. The description adds value beyond that by naming the underlying endpoint (GET .../count.json) and declaring the response shape {EntryCount}, which the absent output schema would otherwise leave unknown.
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 clauses, front-loaded with the count operation, then the filter semantics, then the return shape and endpoint. 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?
For a simple read-only counting tool, the description covers purpose, filtering behavior, return shape, and the backing endpoint; with annotations covering safety and the schema fully documented, nothing needed 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 coverage is 100%, so the baseline is 3. The description adds meaning by clarifying that the filter set is optional ('all of them, or only those matching filters') and that filters follow the same format as wufoo_list_form_entries, which helps the agent reuse known filter conventions.
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 (count) and resource (a form's entries), plus the two modes: all entries or filtered. It is unambiguously distinguishable from the sibling wufoo_list_form_entries, which returns entries rather than a count.
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 a concrete use case ('Useful to plan paging') and points to wufoo_list_form_entries as the source of the filter format. It does not spell out when to prefer this over other count tools (e.g. wufoo_count_report_entries), 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.
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 supply readOnlyHint=true, and the description is consistent with that safe-read profile while adding useful specifics: the return shape {EntryCount} and the underlying endpoint. No details on auth or rate limits, but for a trivial read that gap is minor.
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: purpose, return shape, endpoint. Front-loaded and free of 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 present, the description helpfully discloses the return value ({EntryCount}). For a single-parameter read tool this is nearly complete; only the sibling routing condition 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%, and the schema itself documents the 'report' parameter including hash-vs-title formats and a pointer to wufoo_list_reports. The description adds nothing beyond 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?
Clear verb+resource: 'Count the entries in a report', which reads distinct from sibling wufoo_list_report_entries. It doesn't explicitly name that sibling as the alternative, but the count-vs-list distinction is unambiguous from the name and text.
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 tool's nature (count when you only need a number), but there is no explicit when-to-use/when-not statement or routing to the alternative wufoo_list_report_entries when full entry data is required.
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 safety profile is covered. The description adds genuinely new behavioral context beyond that: the receiving URL stops getting new entries immediately, and the hash cannot be rediscovered after the fact. Both are operationally important for a destructive 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?
Front-loads the WRITE marker and the effect, then the prerequisite, then the raw endpoint. Dense and mostly waste-free, though the literal REST path is marginally useful padding for an agent that already has the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two fully-documented params and no output schema, the description covers what matters: mutation semantics, immediate effect, and how to obtain the required hash. Only the absence of any failure/error behavior keeps it 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 coverage is 100%, so both parameters are already documented in detail (form identifier formats, hash pattern). The description only restates that the hash originates from wufoo_add_webhook, which the schema also references, so it adds little beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (removes) and resource (a webhook from a form), and the 'WRITE:' prefix immediately separates it from the read-oriented siblings. It is clearly the inverse of wufoo_add_webhook, which an agent can identify 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?
Gives a concrete prerequisite: the hash must come from wufoo_add_webhook, and it warns that Wufoo has no endpoint to list webhooks, which steers the agent away from searching for a list tool. It does not state explicit when-not-to-use conditions, but the routing 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 real context by listing the settings returned (confirmation message, notification emails, public flag, entry limit, links) and the underlying REST path, which helps the agent anticipate output shape.
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 with zero filler; the identifier-based purpose and returned field list are front-loaded before the endpoint note.
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, enumerating returned fields is exactly the right compensation, and identifier sourcing is covered. Only explicit when-to-use guidance against the list/field siblings is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented, so baseline 3 applies. The 'by hash or URL title' phrasing restates what the schema already says rather than adding format or edge-case detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch one form's settings') and enumerates the fields returned, which cleanly separates it from siblings like wufoo_get_form_fields and wufoo_list_forms. An agent can distinguish it 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 description implies single-form retrieval by hash or URL title, and the schema description points to wufoo_list_forms as the discovery step, but the description itself never states when to use this versus the list or field variants. Usage is inferable, not explicit.
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?
readOnlyHint already covers the safety profile, and the description adds genuinely new behavioral context: admin-only fields are excluded, certain field types carry nested SubFields or Choices, and the API ID format (Field###) is what filters, sorting and submissions consume. It does not disclose pagination or error behavior, but for a read-endpoint this is well above the annotation baseline.
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 payload (field structure) then details of returned attributes, edge cases, and the API endpoint. Dense but each clause carries information; only the trailing Wufoo endpoint line is arguably redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must describe return values, and it does so thoroughly — field attributes, nested SubFields and Choices by field type, and the admin-field exclusion. It misses only usage/prerequisite context, which is minor for a read 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 100%, so both parameters (form, system) are fully documented in the schema, including examples and the pointer to wufoo_list_forms. The description does not add syntax or format detail 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?
States a specific verb and resource — retrieving the field structure of a form — and enumerates exactly what is returned (Title, Type, API ID, required flag, default value, page, SubFields, Choices). It is clearly distinct from wufoo_get_form metadata, but it never names that or any other sibling, 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. Nothing tells the agent when to prefer this over wufoo_get_form or wufoo_get_report_fields, nor any prerequisite for obtaining the form identifier.
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?
Annotations only cover read-only safety, and the description carries the rest: empty/null values are dropped unless includeEmpty is set, EntryId/DateCreated and other system keys are preserved, sub-field keys follow a 'Title — Label' convention, and an extra fieldIds (title → API ID) map is returned. It also discloses the underlying two-call (fields.json + entries.json) behavior, which is meaningful for performance expectations.
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 the core differentiator (title-keyed entries) before secondary details, and each sentence carries distinct information: key conventions, default-key preservation, empty handling, fieldIds return, argument parity with the sibling, and the endpoint. Dense but not padded.
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 9 parameters fully covered by the schema and no output schema, the description fills the remaining gap by describing the shape of the response (title-keyed entries, retained system keys, dropped empties, fieldIds map) and the source endpoints. An agent has enough to call it correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents form, sort, match, system, filters, pageSize, pageStart, includeEmpty and sortDirection. The description defers parameter behavior to wufoo_list_form_entries rather than restating syntax, adding only the practical link that the returned fieldIds help build filters/submissions. 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 ('Fetch a page of a form's entries') and immediately names the transformation that distinguishes it from siblings: Field### keys replaced by human titles. The contrast with wufoo_list_form_entries is explicit, so an agent can route between them 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?
Names a sibling (wufoo_list_form_entries) and states this tool takes the same paging/sorting/filter arguments, which frames the relationship and implies when to pick this variant. It stops short of an explicit 'use this instead of X when you need titles' conditional, so it is clear 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.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the HTTP route (GET /reports/{identifier}.json) as extra context but discloses nothing about pagination, error behavior, or what a report 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, front-loaded with the purpose. The API route is arguably dispensable but the description is otherwise tight.
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?
A simple read tool with annotations covering safety and a fully documented single param; the description is adequate but doesn't mention errors when the identifier is unknown or the relationship to sibling tools like wufoo_get_report_fields.
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% and the parameter description already explains the hash-or-URL-title format and references wufoo_list_reports. The description's 'by hash or URL title' repeats what the schema says, adding no new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and resource (one report) with the identifier form. It clearly distinguishes 'one report' from wufoo_list_reports, but doesn't explicitly name siblings the way a 5 would.
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?
Implicitly, use this to get a single report rather than a list, and the schema note points to wufoo_list_reports for discovering identifiers. There is no explicit when-to-use/when-not statement.
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?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the underlying endpoint (GET /reports/{identifier}/fields.json) and the shape equivalence to wufoo_get_form_fields, but says nothing about error behavior for unknown reports or response size.
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 tight sentence plus an endpoint note, front-loaded with what is returned. Nothing is wasted, though the shape reference leans on the reader knowing the sibling tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only lookup with 100% schema coverage and a readOnly annotation, the description is adequate; the 'same shape as wufoo_get_form_fields' clause substitutes for an output schema. Only error/edge-case behavior is unaddressed.
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 (report identifier and the system metadata flag) are fully documented in the schema. The description adds no parameter-level detail beyond that, making 3 the correct baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: retrieving the field structure of the form a report is built on. The parenthetical relating it to wufoo_get_form_fields helps disambiguate it from the sibling, though it stops short of a full explicit 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?
No when-to-use or when-not guidance is given. The description notes the output matches wufoo_get_form_fields, but never says when an agent should call this instead of that sibling (e.g., when only the report identifier is known).
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 the safety profile is covered. The description adds genuine behavioral context beyond that: page-size cap of 100, the Wufoo default of 25, and the underlying endpoint. It stops short of noting auth requirements or rate limits, so it is good but not exhaustive.
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 paragraph that front-loads the core action before the optional filter, pagination and endpoint details. Efficient, with only the trailing API-path sentence bordering on 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?
With no output schema, the description compensates by listing the returned fields and documenting pagination behavior and the optional entry filter. That covers what an agent needs to call it correctly, though auth/permission expectations are unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3; the schema already documents form, entryId, pageSize and pageStart. The description largely restates the max-100 page size and default, adding little syntax or format detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (list comments team members left on a form's entries) and enumerates the returned fields, which cleanly separates it from siblings like wufoo_list_form_entries and wufoo_count_form_comments. An agent can identify the tool 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 phrase 'Optionally only for one entry' implies the entryId filtering scenario, giving some usage context. However, no alternative tools are named (e.g. wufoo_count_form_comments for counts) and there are no explicit when-not conditions, so guidance remains implied rather than stated.
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 cover the safety profile (readOnlyHint=true), and the description adds valuable behavior: the return keying (Field105…, EntryId, DateCreated, CreatedBy, DateUpdated, UpdatedBy), the Filter1=Field105 Contains foo serialization, AND/OR defaults, and the pageSize cap of 100. It doesn't discuss rate limits or ordering guarantees, but it goes well past the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single information-dense paragraph, front-loaded with what the tool returns and followed by filtering/sorting/paging and the sibling pointer. It is long but nearly every clause carries new semantics; only the trailing GET endpoint restates a known pattern.
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 8 parameters, no output schema, and no nested objects, the description covers return keying, filtering, sorting, and paging adequately. An agent has enough to call it correctly; only edge details like error behavior or total-count semantics 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 coverage is 100%, so the baseline is 3, but the description adds the wire serialization ('Filter1=Field105 Contains foo, combined with match AND/OR') and reiterates the 100 page cap, which meaningfully clarifies how the filter array and match parameters interact.
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') and immediately scopes how the entries are keyed (field API ID plus system fields). It explicitly contrasts itself with wufoo_get_labeled_entries, so an agent can pick between the two 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 to use it (API-ID keyed entries, Entry-Manager-style filtering/sorting/paging) and names the alternative tool for human-readable titles. It does not explicitly state when-not-to-use beyond that routing hint, 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.
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 safety is covered; the description adds real behavioral context beyond that: the access scope is the API key's user, the exact field set returned, and the fact that includeTodayCount injects an EntryCountToday field. It stops short of describing pagination/default limits or response envelope, which keeps it from a 5.
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: the scope and returned fields come first, the parameter effect second, and the raw endpoint last. No filler and nothing redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates well by enumerating the returned fields and the optional EntryCountToday. For a zero-required-parameter list tool this is close to complete, though noting default page size or total-count behavior would close the last 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%, so page, limit, and includeTodayCount are already documented; baseline is 3. The description adds marginal value by explaining the observable effect of includeTodayCount (adds EntryCountToday), but says nothing extra about page/limit.
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?
Specific verb 'List' plus resource 'forms' scoped to 'the API key's user can access', which cleanly separates it from wufoo_get_form (single form) and wufoo_list_reports. It even enumerates the fields returned, so an agent knows exactly what it gets.
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 name and the listing semantics, and the sibling set makes the alternative obvious (get_form for one form), but the description never states when to use this versus those alternatives or any prerequisites/rate limits. Adequate but with a clear gap.
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. The description adds real behavioral context beyond that: entries are keyed by field API ID (like a datagrid/export view) and no paging or filter parameters are documented, which saves an agent from futile attempts. It stops short of describing result volume or ordering.
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 plus an endpoint reference, all front-loaded with the essential meaning first. Slightly boilerplate in the trailing endpoint citation, but nothing wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description gives the agent a mental model of the return value (entry data keyed by field API ID, matching datagrid/export output) and notes the lack of paging. Enough to call it correctly; only result volume and ordering remain unaddressed.
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%, with both parameters fully documented in the schema (including the pointer to wufoo_list_reports for the report identifier). The description adds marginal value by noting the keying and the absence of documented paging/filter params, but nothing beyond the schema's own field semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names the specific resource (the entries that make up a report) and pins down its shape: what the datagrid widget or an export would show, keyed by field API ID. That clearly separates it from siblings like wufoo_list_form_entries, wufoo_get_labeled_entries, and wufoo_list_report_widgets.
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 resource (report entries rather than form entries), and the note that Wufoo documents no paging or filter parameters usefully constrains what an agent should attempt. However, it never explicitly states when to prefer this over wufoo_list_form_entries or wufoo_get_labeled_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?
Annotations already declare readOnlyHint=true, so the safety profile is covered structurally. The description adds useful context beyond that: the access scope is limited to the API key's user, the fields returned are enumerated, and the underlying endpoint is disclosed. It says nothing about pagination, sorting, or result limits, which matters for a listing endpoint.
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 tight sentence plus the raw endpoint reference, front-loaded with the verb and resource. Every clause earns its place — scope, returned fields, and API mapping are all informative 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?
With no input parameters, no output schema, and annotations already signaling read-only, the description is close to complete: it enumerates the fields an agent will receive, which substitutes for the absent output schema. Only the pagination/sorting behavior of the endpoint is left unstated.
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 the schema carries no per-parameter semantics to supplement; baseline 4 applies. The description correctly avoids inventing parameters that do not exist.
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 reports') and scopes the result set to what the API key's user can access, which distinguishes it from wufoo_get_report and wufoo_list_forms. It also enumerates the returned fields. It stops short of explicitly naming a sibling it is not, so a 4 rather than 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 explicit when-to-use or when-not-to-use guidance, and no prerequisites or alternatives are named. The scoping phrase 'the API key's user can access' gives mild implied context for what results to expect, so usage is inferable but not stated.
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?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavioral context by specifying included widget types, excluded widget types, and returned fields (Name, Type, TypeDesc, Size, Hash), though it does not cover auth, rate limits, 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?
It is a single dense sentence plus the API endpoint, front-loading the included widget types and returned fields. 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 read-only listing tool with no output schema, the description enumerates the returned fields and excludes non-returned widget types, so the agent knows what to expect. It omits response container or pagination details, but given the simple one-parameter contract, it is nearly 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 100%, and the sole report parameter is fully documented in the schema with hash/URL-title format and a pointer to wufoo_list_reports. The description only repeats the identifier in the endpoint template, adding no new parameter meaning 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 states the resource (report widgets), the exact widget types included (chart, graph pie/bar/line, big-number), and explicitly excludes text/datagrid widgets. This lets an agent distinguish it from sibling report tools without opening each 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?
Usage is strongly implied: call this when you need widget metadata for a report, and the exclusion tells you not to use it for text or datagrid widgets. However, it does not name sibling alternatives or state prerequisites beyond the required report identifier.
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?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuine behavioral context beyond that: the returned field set and the explicit note that each user's API key is redacted, plus the underlying GET /users.json call. It stops short of noting ordering or any size/rate constraints.
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, field list front-loaded, redaction caveat and endpoint appended without padding. Every clause carries information; nothing is redundant with the title or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe returns, and it does so thoroughly (name, email, timezone, company, flags, permissions). The only unmet needs are edge details like result ordering or behavior on accounts with many users, which are minor for a parameterless 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 there is nothing for the description to disambiguate; per the rubric this is a baseline 4. The field list it provides describes the response rather than inputs, which is still useful but not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List the account's users') and enumerates the fields returned, so an agent immediately knows this is account-user enumeration, not form/report/entry listing like the sibling 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 only implied by the tool name and resource; there is no explicit when-to-use statement, no prerequisites, and no named alternative. Since no sibling also lists users, the risk of misfire is low, but the description itself provides no routing guidance.
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 declare destructiveHint=true; the description goes well beyond that by disclosing side effects (stored, triggers notifications, webhooks, integrations), failure behavior (per-field errors returned on rejection), and a concrete rate limit of 50 submissions per user per 5 minutes. These are exactly the traits an agent cannot infer from 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?
A single dense paragraph, but it is front-loaded with the write semantics and every clause carries a distinct fact (key format, sub-fields, date format, validation, rate limit, endpoint). The trailing raw endpoint reference is the only mildly redundant element.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description still tells the agent what a successful write does and what a rejected one returns (per-field errors). Combined with the rate limit and key-format guidance, an agent has everything needed to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: keys are field API IDs sourced from wufoo_get_form_fields, composite fields (name, address, checkbox) require one key per sub-field ID, and dates must be YYYYMMDD. That sub-field and date-format guidance is not visible 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 verb and resource ('submits a new entry to a form') and immediately qualifies the write semantics ('exactly as if someone filled it in'). The 'WRITE:' prefix cleanly separates it from the read-oriented siblings like wufoo_list_form_entries and 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?
Points the agent at wufoo_get_form_fields for the key format and wufoo_list_forms for the form identifier, and warns that validation and form limits apply. It stops short of an explicit 'do not use this for reading/x' exclusion, but the routing context is clear.
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_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.
