Lists all automation-enabled Data Templates (Forms) available for the current group. Use this tool first when you need to determine which Data Template (Form) should be used for a user's request, before retrieving its schema or working with submissions.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, openWorld, idempotent, non-destructive traits. The description adds context beyond annotations by specifying the filter ('automation-enabled') and scope ('current group'). However, it does not describe return format or pagination, but with no parameters and a simple list operation, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose and then a clear usage instruction. No redundant information or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with zero parameters and no output schema, the description is complete. It tells what is listed, the scope, and when to use it. Sibling tools are mentioned implicitly through the usage guidance, providing enough context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description adds no param-specific details (none needed). Baseline for zero params is 4, and the description adequately frames the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Lists all automation-enabled Data Templates') and a clear resource/scope ('available for the current group'). It also distinguishes itself from siblings by saying 'Use this tool first... before retrieving its schema or working with submissions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs when to use the tool: 'Use this tool first when you need to determine which Data Template (Form) should be used for a user's request, before retrieving its schema or working with submissions.' This clearly positions it relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a unique, clearly defined purpose: listing templates, fetching schema, and performing distinct submission operations (create, get, list recent, search, update, workflow update). Even overlapping actions like list_recent and search are differentiated by whether criteria are used, and get is by submission number. The workflow-specific tools are also distinct from the data-field tools.
All tools follow a consistent wdf_data_templates_ prefix, with template-level actions using verb phrases (list, get_schema_and_sample_submissions) and submission-level actions using submissions_<verb>. The pattern is uniform, and the verb-first structure (create, get, update, search, list_recent) makes it predictable.
Nine tools is within the ideal range for a focused domain. The count covers the full workflow of form management—schema discovery, submission CRUD (minus delete), searching, listing, and workflow state changes—without unnecessary redundancy. Each tool corresponds to a distinct operation needed to work with web data forms.
The tool set covers the core lifecycle: list templates, get schema, create/read/update submissions, search/list, and manage workflow state. The only notable gap is the lack of a delete operation for submissions, which may be intentionally omitted for audit purposes. Workflow metadata retrieval and sample submissions provide good supporting context, so agents can operate effectively.
