Skip to main content
Glama

wdf_data_templates_submissions_update

DestructiveIdempotent

Replaces a submission's entire data object with the values provided in data. This is a full overwrite, not a merge — any existing field not included in data will be cleared to empty. Keys in data must match the field IDs from the Data Template (Form) schema (via wdf_data_templates_get_schema_and_sample_submissions), not display labels — an unrecognized key may be silently dropped rather than raising an error. Before calling this tool, first call wdf_data_templates_submissions_get, wdf_data_templates_submissions_search or wdf_data_templates_submissions_list_recent to retrieve the current field values, then include the complete set of fields in data — the ones you're changing plus every field you want to keep.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dataYesUpdated submission data as a key-value object (fieldId: value)
dataTemplateIdYesThe Data Template ID.
submissionNumberYesThe Submission Number.

TDQS

A5/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description reveals critical details: omitted fields are cleared to empty, unrecognized keys may be silently dropped, and keys must match field IDs from the schema. It also provides a mandatory pre-call workflow, significantly enriching the behavioral model.

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

Conciseness5/5

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

The description is concise and front-loaded: the first sentence states the core action and overwrite semantics, the second covers key-matching requirements and silent dropping, and the third provides a clear preparatory workflow. Every sentence adds necessary information with no fluff.

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

Completeness5/5

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

Given the tool's complexity (full overwrite, silent key dropping, field ID requirement), the description covers all critical operational aspects, including explicit pre-call workflow and the need to include all fields to preserve. While no output schema exists, the description's focus on input semantics and side effects is appropriate for an update tool.

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

Parameters5/5

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

Although the schema provides descriptions for all parameters, the description adds crucial semantics for 'data': it must use field IDs (not display labels), unrecognized keys may be silently ignored, and the full set of existing fields must be included to avoid clearing them. This goes far beyond the schema's basic 'key-value object' definition.

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

Purpose5/5

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

The description clearly states that the tool replaces a submission's entire data object, using the specific verb 'replaces' and outlining the full overwrite behavior. It distinguishes itself from sibling tools like create by focusing on updating an existing submission, and from read tools by describing a write operation.

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

Usage Guidelines5/5

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

The description explicitly instructs the caller to first retrieve current field values via get, search, or list_recent, and to include the complete set of fields in data. It also warns against using display labels and clarifies that this is a full overwrite, not a merge, implicitly stating when not to use it.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation5/5

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.

Naming Consistency5/5

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.

Tool Count5/5

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.

Completeness4/5

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.

Resources