Give AI assistants secure access to your organization's structured business data. Search records, create and update records, retrieve schema information, and manage workflow states using natural language.
You need two values for every request:
x-api-key — your Web Data Forms API Key
x-group-id — your Web Data Forms Group ID
You can find these in your Web Data Forms accounts group->information page.
Preferred method: request header
When possible, pass the credentials as HTTP headers:
x-api-key:
x-group-id:
This is the preferred option because it keeps credentials out of the URL and is more secure.
Fallback method: query parameters
If your MCP client does not support custom headers, the server also accepts the credentials as URL query parameters. Example:
https://mcp.webdataforms.com?x-api-key=abc123&x-group-id=xyz456
Detailed information here: https://github.com/Web-Data-Forms/mcp-server-docs/blob/main/README.md
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.6/5 across 9 of 9 tools scored.
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.
wdf_data_templates_get_schema_and_sample_submissionsAReturns the complete schema for a Data Template (Form), including all fields (with their field IDs), searchable fields, and representative sample submissions. Use this tool to understand the available fields and expected data before creating, updating, or searching submissions — the field IDs returned here are the exact keys expected in data for wdf_data_templates_submissions_create and wdf_data_templates_submissions_update. Can also be used to retrieve searchable fields schema and sample submissions for a Data Template (Form).
| Name | Required | Description | Default |
|---|---|---|---|
| dataTemplateId | Yes | The Data Template ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat those. It adds value by stating that 'the field IDs returned here are the exact keys expected in data' for create/update operations, which clarifies an important behavioral aspect. It also details what the return includes (all fields, searchable fields, sample submissions).
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 description is concise at two sentences, but the second sentence ('Can also be used to retrieve searchable fields schema and sample submissions...') is largely redundant with the first sentence which already mentions those elements. Minor redundancy prevents a perfect score, but it remains efficient and front-loaded.
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 single-parameter read-only tool, the description is highly complete. It covers the return content, the purpose relative to create/update/search operations, and the exactness of field IDs. With strong annotations and no output schema required, no additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the single parameter (dataTemplateId) with 100% coverage. The description adds minimal semantic context by clarifying that a Data Template is a Form and that field IDs are the keys for other operations, but this is supplemental rather than essential. Baseline of 3 is appropriate given high schema coverage.
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 clearly states what the tool does: 'Returns the complete schema for a Data Template (Form), including all fields... searchable fields, and representative sample submissions.' It uses a specific verb ('Returns') and resource ('schema for a Data Template'), and distinguishes this from sibling tools that manage submissions or list templates.
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 provides explicit guidance on when to use the tool: 'Use this tool to understand the available fields and expected data before creating, updating, or searching submissions.' It also notes an additional use case for retrieving searchable fields schema and sample submissions. However, it does not explicitly mention alternatives or when not to use it, so it doesn't fully earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wdf_data_templates_listALists 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 parameters | |||
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.
wdf_data_templates_submissions_createAInspectCreates a new submission for a specific Data Template (Form). Use this tool after obtaining the Data Template (Form) schema (via wdf_data_templates_get_schema_and_sample_submissions) and collecting all required information from the user. Keys in data must match the field IDs from the Data Template (Form) schema, not display labels — an unrecognized key may be silently dropped rather than raising an error. Provide all fields marked as required in the Data Template (Form) schema; omitted optional fields are simply left blank on the new submission.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Submission data as a key-value object (fieldId: value) | |
| dataTemplateId | Yes | The Data Template ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: unrecognized keys are silently dropped rather than raising an error, and required fields must be provided. These go beyond the annotations (readOnlyHint=false, openWorldHint=true) and are critical for correct usage. No contradiction with annotations exists.
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 description is four sentences, each carrying distinct information: purpose, usage context, key-matching caveat, and field requirements. It is well-structured and avoids redundancy 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?
The description covers purpose, prerequisite, parameter semantics, and error behavior, which is comprehensive for a tool with only two parameters. The only omitted aspect is the exact return value/output format, which is less critical for invocation given no output schema, but still a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes parameters as 'The Data Template ID' and 'Submission data as a key-value object'. The description enriches the 'data' parameter significantly by explaining key matching to field IDs, the silent-drop behavior, and required vs optional handling. This is essential semantic information above 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 first sentence clearly states the tool's action ('Creates a new submission') and resource ('specific Data Template (Form)'), distinguishing it from sibling retrieval/update tools. The verb 'creates' inherently differentiates it from update/list/search siblings. No ambiguity.
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 explicitly states the prerequisite workflow: obtain the schema first via the named sibling tool, then collect user input. This provides clear 'when to use' guidance without needing to enumerate exclusion cases. It also sets expectations for data preparation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wdf_data_templates_submissions_getAReturns the complete contents and metadata of a specific submission. Use this tool when you already know the Submission Number and need to view or verify its data. If you don't already have the Submission Number, you may obtain it via wdf_data_templates_submissions_search or wdf_data_templates_submissions_list_recent.
| Name | Required | Description | Default |
|---|---|---|---|
| dataTemplateId | Yes | The Data Template ID. | |
| submissionNumber | Yes | The Submission Number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds that it returns 'complete contents and metadata' and is for viewing/verifying, which provides useful behavioral context beyond the annotations. However, it does not describe error behavior or response format in detail.
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 description is two sentences, front-loaded with the purpose, and every sentence adds value. It is concise and well-structured.
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?
Given the tool is a simple read operation with two well-specified parameters and no output schema, the description is sufficient. It covers purpose, usage context, and alternative tools, and clarifies the return is complete contents and metadata.
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 descriptions cover 100% of parameters (dataTemplateId and submissionNumber), but they are minimal (just repeating the names). The tool description does not add meaning beyond the schema, though it indirectly guides on how to obtain the submission number via other tools. Baseline 3 is appropriate given high schema coverage.
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 clearly states the tool returns the complete contents and metadata of a specific submission, using the specific verb 'returns' and resource 'submission'. It also distinguishes from sibling tools by specifying it is for when you already know the Submission Number.
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 states when to use this tool ('when you already know the Submission Number and need to view or verify its data') and provides alternatives for obtaining the number via wdf_data_templates_submissions_search or wdf_data_templates_submissions_list_recent. This is clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wdf_data_templates_submissions_get_workflow_metaAReturns the valid workflow configuration for the current group, including available statuses, priorities, types, and assignable users. Use this tool before updating workflow fields if the valid values are not already known.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing the safety profile. The description adds valuable context by noting the result is scoped to the 'current group' and listing the categories of returned data. For a read-only metadata endpoint, this is sufficient behavioral disclosure.
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 description is two sentences, both purposeful and free of redundancy. The first sentence states the return value, the second gives actionable guidance. Every word earns its place, making it highly concise and well-structured.
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?
Despite having no parameters and no output schema, the description sufficiently explains what the tool returns and when to use it. Listing the return categories provides a clear picture of the output. The sibling update_workflow tool gives complementary context, and the description covers all necessary information.
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 has zero parameters, and the input schema is an empty object. Per the rubric, 0 params receives a baseline 4 because there is no parameter burden to clarify. The description correctly mentions no parameters, aligning with 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 uses the specific verb 'Returns' and clearly identifies the resource: the valid workflow configuration for the current group. It further enumerates the exact categories of data (statuses, priorities, types, assignable users), making it unmistakably distinct from sibling tools that handle submission data or 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?
The description provides an explicit when-to-use instruction: 'Use this tool before updating workflow fields if the valid values are not already known.' This gives clear context for invocation. However, it does not state when not to use it or mention alternative tools, so it falls just short of the highest level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wdf_data_templates_submissions_list_recentAReturns the most recent submissions for a Data Template (Form). Use this tool to browse or summarize recent submissions when you do not need to search by particular field values.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | The number of submissions to return (default: 20). | |
| dataTemplateId | Yes | The Data Template ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context beyond the core purpose, such as the 'most recent' ordering and the browse/summarize use case, but no additional details like pagination or return format.
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 description is two sentences, concise and front-loaded. The first sentence states the core action, and the second provides usage context. No redundant words 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 2 parameters, full schema coverage, and strong annotations, the description is complete. It communicates the return outcome (recent submissions) and the appropriate use case, without over-explaining what is already 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?
The input schema covers 100% of the parameters, with descriptions for both dataTemplateId and limit, including a default for limit. The tool description does not add any additional parameter semantics, so it stays at the baseline of 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?
The description clearly states the tool's function: 'Returns the most recent submissions for a Data Template (Form).' This uses a specific verb and resource, distinguishing it from sibling tools like wdf_data_templates_submissions_search, which is implied by the contrasting phrase 'when you do not need to search by particular field values.'
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 provides explicit usage guidance: 'Use this tool to browse or summarize recent submissions when you do not need to search by particular field values.' This clearly indicates when to use this tool versus a search-based alternative, though it does not explicitly name the alternative sibling tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wdf_data_templates_submissions_searchASearches submissions using a searchable field value. Use this tool to locate existing submissions matching the search criteria. Only fields configured as searchable in the Data Template (Form) can be used as search criteria — call wdf_data_templates_get_schema_and_sample_submissions first to see which fields are searchable for this Data Template (Form).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (1 - 50) | |
| searchField | Yes | The searchable field to search by | |
| searchValue | Yes | The value to search for | |
| dataTemplateId | Yes | The Data Template ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe-read nature is known. The description adds meaningful context: only fields configured as searchable can be used, and a specific prerequisite call is required. This goes beyond the structured data, though it does not mention rate limits or output details.
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 core purpose and followed by a key constraint and prerequisite. Every word earns its place; no fluff or redundant restatement of 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?
For a search tool with a prerequisite and constraint, the description covers the essential context: what it does, how to use it correctly (searchable fields), and the needed preliminary step. No output schema exists, but the description focuses on usage, not return format, which is acceptable given the tool's nature. Minor gap: no mention of pagination or default limit, but the schema covers limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all parameters with descriptions (100% coverage), so baseline is 3. The description adds value by clarifying that 'searchField' must be a searchable field within the Data Template, which is not explicit in the schema. It also implies 'searchValue' is the matching value, aligning with schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Searches submissions using a searchable field value' and 'locate existing submissions matching the search criteria.' It distinguishes from sibling tools like list_recent by emphasizing search across fields, and directs to get_schema first, clarifying the search scope.
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 states when to use the tool ('Use this tool to locate existing submissions matching the search criteria') and provides a critical prerequisite: call wdf_data_templates_get_schema_and_sample_submissions first to determine which fields are searchable. This effectively guides the agent away from inappropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wdf_data_templates_submissions_updateAReplaces 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.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Updated submission data as a key-value object (fieldId: value) | |
| dataTemplateId | Yes | The Data Template ID. | |
| submissionNumber | Yes | The Submission Number. |
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.
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.
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.
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.
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.
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.
wdf_data_templates_submissions_update_workflowAReplaces a submission's workflow state (status, priority, type, and optionally assignee and comment) with the exact values provided — this is a full overwrite (except the comment, which is appended), not a partial update. statusId, priorityId, and typeId are all required even if only one is changing; reuse the submission's existing values for any field you don't intend to change — retrieve these via wdf_data_templates_submissions_get, wdf_data_templates_submissions_search, or wdf_data_templates_submissions_list_recent, which include the submission's current workflowState. Call wdf_data_templates_submissions_get_workflow_meta to get the valid IDs for any field you are changing.
| Name | Required | Description | Default |
|---|---|---|---|
| typeId | Yes | Workflow Type ID | |
| comment | No | Comment content | |
| statusId | Yes | Workflow Status ID | |
| priorityId | Yes | Workflow Priority ID | |
| assigneeUserId | No | User ID to assign the submission to, null to unassign | |
| dataTemplateId | Yes | The Data Template ID. | |
| submissionNumber | Yes | The Submission Number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (destructiveHint=true, readOnlyHint=false), the description adds critical behavioral details: it's a full overwrite, the comment is appended rather than replaced, and all three workflow IDs are required even if only one changes. This significantly clarifies the tool's side effects and 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?
The description is concise and front-loaded, with three dense sentences that each carry important information. There is no fluff; every clause adds value by explaining the overwrite semantics, required fields, and how to retrieve necessary data.
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?
Given the tool's complexity (7 parameters, 5 required, no output schema), the description is remarkably complete. It covers the core behavior, prerequisites, how to obtain IDs, how to preserve unchanged values, and the appending comment behavior, leaving few questions unanswered.
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?
Although schema coverage is 100%, the description adds deep semantic value by explaining the interplay between statusId, priorityId, and typeId (all required, reuse existing values) and how to discover valid IDs via get_workflow_meta. It also clarifies assigneeUserId can be null to unassign and comment behavior.
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 clearly states the tool 'replaces a submission's workflow state' with exact values, using the specific verb 'replaces' and resource 'workflow state'. It explicitly distinguishes this from a partial update by noting it's a 'full overwrite', differentiating it from sibling tools like the general 'update'.
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 provides explicit guidance on when to use the tool and how to ensure correct usage: retrieve existing values via get/search/list_recent and valid IDs via get_workflow_meta. It also warns that this is not a partial update, implying alternative usage for partial changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
