wflow-mcp

Official

by wflowcom

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action: roles, teams, documents, registers, users, orgs, plus discovery/escape-hatch tools. Even create_document_with_files vs update_document are clearly separated by file attachment vs inline line items, and api_catalog/request serve unique discovery/execution roles.
Naming Consistency4/5
Tools consistently follow a verb_noun pattern (list_*, get_*, upsert_*, delete_*, create_*, search_*, update_*). Minor exceptions like wflow_whoami, wflow_api_catalog, and wflow_request break the strict verb-first scheme but remain predictable and readable.
Tool Count4/5
26 tools is above the typical 15-tool comfort zone, but the server covers a broad enterprise domain (documents, users, teams, roles, registers, organizations) plus low-level discovery/request capabilities. Most tools earn their place, though a unified document creation tool could reduce redundancy.
Completeness3/5
Documents, users, teams, roles, and registers have solid CRUD/lifecycle coverage, and bulk/export/event operations are a plus. However, there is no typed get_role, no document delete, and no approval/workflow action tools; these are deferred to the generic wflow_api_catalog/wflow_request escape hatch, which mitigates but does not fully cover the gaps.
Average 4/5 across 26 of 26 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Irreversible' is a useful but minimal disclosure; it does not explain cascading effects on users assigned to the role, required permissions, or whether deleting a role with dependencies is even allowed. Significant gaps remain for a destructive operation.
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?
Two short sentences convey the essential action and a key warning. Every word earns its place, with no redundant or vague content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with two parameters and no annotations or output schema, the description is too sparse. It does not address what happens to role assignments, error conditions, or whether organization scoping affects the deletion scope, leaving the agent underinformed for high-stakes usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema lists roleId (required) and organization (optional), but schema description coverage is 0%. The description only hints that deletion is 'by id', which maps to roleId, but does not clarify the format of roleId or the purpose of the organization parameter. It fails to compensate for the lack of schema descriptions.
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 a specific verb+resource: 'Delete a role by id'. It distinguishes from sibling tools like wflow_upsert_role (create/update) and wflow_list_roles (read). The addition of 'Irreversible' reinforces the intended destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as wflow_list_roles to find a role ID first or wflow_upsert_role to modify instead of delete. There is no mention of prerequisites or situations where deletion might be inappropriate, leaving the agent to infer usage from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral disclosure. It does disclose irreversibility, which is a key trait. However, it omits other behavioral aspects like required permissions, whether related data is cascade-deleted, or what happens on failure. The single caution adds some value but is not comprehensive.
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 a single, front-loaded sentence plus a clear caution. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple two-parameter tool with no output schema and no annotations, the description provides the essential action and irreversibility. However, it lacks details about return values, error behavior, or prerequisites, leaving some ambiguity for a high-stakes irreversible operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions 'by id', which loosely corresponds to userId but does not clarify the optional 'organization' parameter. The schema's property names are self-explanatory but the description adds minimal meaning beyond them.
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 the action ('Delete (revoke)'), the target ('a user from an organization'), and the method ('by id'). This distinguishes it from sibling tools like wflow_delete_role or wflow_upsert_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The 'Irreversible' warning is a caution, not a usage guideline. Unlike tools that name alternatives or prerequisites, this description provides no such context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that deletion is irreversible, which is a critical behavioral trait. However, it does not mention side effects on associated data, required permissions, or whether it is a hard or soft delete, leaving notable gaps.
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 extremely concise: two short sentences that immediately convey the action and the key warning. There is no fluff, and the critical 'Irreversible' note is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature, lack of annotations, and absence of an output schema, the description omits return values, error handling, prerequisites, and effects on related entities. The irreversibility warning is helpful but insufficient for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only reinforces 'by id' for teamId, offering no explanation of the 'organization' parameter, value formats, or how teamId is obtained. This adds minimal value beyond the parameter names.
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 uses a specific verb 'Delete' and resource 'team', and clarifies 'by id'. It clearly distinguishes from sibling tools like wflow_list_teams, wflow_get_team, and wflow_upsert_team by indicating a destructive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implicitly suggests when to use this tool (to remove a team), but there is no explicit guidance on when to prefer it over alternatives, nor any exclusions or prerequisites. The 'Irreversible' warning is the only additional usage hint, but no alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly indicates a read operation ('Return') and lists event types, but does not disclose the response format, pagination, or behavior for missing documents. The added examples provide some context beyond the name, but important behavioral details are omitted.
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 two sentences with no wasted words. The first sentence states the core function, and the second adds a practical usage context. It is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains the purpose and event types for a simple read tool, but lacks details about the 'organization' parameter and does not describe the return structure. Since there is no output schema and only 50% schema coverage, some completeness gaps remain, though the tool is relatively simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% because the 'organization' parameter lacks a description. The tool description does not compensate for this gap—it mentions document events but gives no explanation of what 'organization' or 'documentId' mean beyond the schema's minimal note. The description adds no parameter semantics beyond the schema.
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 the tool returns the chronological event/audit trail for a document, with specific examples of event types (created, updated, approved, etc.). This distinguishes it from sibling tools like wflow_get_document by focusing on history rather than current document state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'Useful for controlling and spotting inconsistencies,' but does not explicitly contrast with alternatives like wflow_get_document or state when not to use it. It gives a context for use but lacks clear boundaries or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the tool fetches a team including members, which is a read operation but does not describe what happens if the team is not found, any authentication requirements, or response format. This is adequate for a simple fetch but not deeply transparent.
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 a single, concise sentence that directly states the purpose. No filler or redundant information. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool, the description is adequate but not complete. It lacks details on return values (what shape the member users take), error handling, or the role of the 'organization' parameter. Since there is no output schema and no annotations, the description carries a heavier burden than it fulfills, leaving some ambiguity for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'by id' (teamId) but does not explain the 'organization' parameter at all. The schema only provides parameter types, so the description adds minimal meaning beyond the schema. This is a significant gap for the undocumented 'organization' parameter.
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 uses a specific verb 'Fetch' with a clear resource 'a team by id' and adds 'including its member users', which distinguishes it from sibling tools like wflow_list_teams (which lists all teams) and wflow_upsert_team/wflow_delete_team. This fully clarifies what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need a specific team by its id, and its members. However, it does not explicitly state when not to use it or mention alternatives like wflow_list_teams for broader queries. The context is clear but lacks explicit exclusions or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It discloses the returned data components (roles, teams, permissions, rights), but it does not mention potential errors (e.g., user not found), authentication requirements, or any side effects. Since this is a read operation, the transparency is adequate but not rich.
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 a single, well-structured sentence. It front-loads the action and resource ('Fetch a user by id') and then lists the included data. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch tool with only 2 parameters and no output schema, the description provides a reasonable overview of the returned data (UserFull). However, it omits clarification of the optional 'organization' parameter and does not indicate the output format or any limitations. The description is adequate but not complete given the lack of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters. The description mentions 'by id' but does not clarify that 'userId' is the required parameter or explain the optional 'organization' parameter. Without additional context, an agent may not know how to set the 'organization' field or whether it affects the lookup.
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 the action ('Fetch a user by id') and defines the scope: roles, team membership, document-type permissions, and effective rights (UserFull). This distinguishes it from siblings like wflow_list_users, wflow_whoami, and wflow_find_users_with_right by specifying the exact data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need full details for a specific user by ID. However, the description does not provide explicit guidance on when to choose this over alternatives, nor does it mention any exclusions or prerequisites (e.g., needing a user ID from a list or search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently states the create/attach side effects and the auto-extraction of SK QR receipts and ISDOC files, but does not mention return values, authentication needs, or error behavior, leaving gaps in comprehensive transparency.
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 well-structured: two sentences, action-first, with no redundant filler. It packs essential info (single-call attachment, auto-extraction, optional params) efficiently, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is moderately complete for a creation tool. It explains the core behavior and special file handling, but omits the return value and the organization parameter, making it not fully self-sufficient. Compared to worse examples, it provides enough context to be functional, but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to typeId and invoiceType by calling them 'pinned' and optional, but it does not clarify the 'organization' parameter, which also lacks a schema description. With 75% schema coverage, the tool description provides modest added value but does not fully compensate for the undefined parameter.
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 the tool's action: 'Create a new document and attach one or more local files in a single call.' It uses a specific verb and resource, and distinguishes from sibling tools like wflow_upload_document_file by emphasizing the creation of a new document combined with file attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating new documents with local files, but does not explicitly contrast it with alternatives or provide when-not-to-use guidance. It mentions optional typeId and invoiceType, giving some context, but lacks explicit references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return payload (all fields, VAT subtotals, lines, accounting), which is useful behavioral context. However, it does not explicitly state this is a read-only operation, what happens if the document is not found, or any authorization requirements. This is adequate but not comprehensive.
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 a single, concise sentence that front-loads the action and purpose, then enumerates the key fields returned. Every word contributes, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with no output schema, the description covers the essential information: what it does and what the response contains. It could mention error handling or confirm read-only behavior, but the core invocation details are present and the sibling context clarifies its role among related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters (documentId and organization), so the schema already documents them fully. The description only repeats that the lookup is 'by its id' and does not add new semantics about parameter format or defaults beyond the schema.
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 uses the specific verb 'Fetch' and names the resource 'full document object' with a clear scope ('by its id'). It distinguishes this from sibling tools like wflow_search_documents (searching) and wflow_get_document_events (events) by enumerating included fields (VAT subtotals, lines, accounting).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a document ID and want the full object, but it does not explicitly discuss when to use this over alternatives such as wflow_search_documents or wflow_get_document_events. No exclusions or prerequisites are stated, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses auto-pagination, query/sort support, and typical entry fields, which adds value beyond the name. However, it does not mention error handling, permissions, or result count limits, leaving gaps for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences plus an example; the long type list is informative but slightly redundant with the schema enum. Overall efficient and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with no annotations and no output schema, the description covers main behaviors (auto-pagination, query/sort, typical fields) but omits edge cases like onlyValid semantics, maxItems behavior, and error responses. Moderate completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 50% of parameters (type, query, onlyValid). The description adds an example combining query and type, and mentions typical response fields, which helps parameter understanding. But it does not clarify sort, maxItems, or organization, so compensation is only partial.
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?
Description clearly states 'Read entries from any wflow register/reference table', using the specific verb 'Read' and resource 'register/reference table'. It distinguishes from sibling getters (like get_team, get_user) by listing 24 register types, making the exact scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: this is for reading from registers/reference tables, with an example showing how to resolve a cost centre. It does not explicitly mention when not to use or alternatives, but the scope is self-evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the scope (basic list only) and explicitly points to another tool for deeper data, implying a read-only operation. This provides useful behavioral context beyond a simple listing statement.
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?
Two sentences convey the purpose and a navigation hint with no redundant words. The description is front-loaded with the core function and keeps the alternative instruction brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks annotations and output schema, and the description fails to explain the two parameters. While the return fields are stated, the absence of parameter semantics makes correct invocation for anything beyond a default listing unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines two parameters (search, organization) with no descriptions and 0% coverage. The description offers no explanation of these parameters, leaving the agent to guess their purpose and formatting.
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 the tool lists roles in an organization, including id, name, and description. It distinguishes itself from sibling tools by pointing to wflow_request for one role's rights & members.
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?
Explicitly instructs to use wflow_request GET roles/{id} to get one role's rights & members, providing clear guidance on when this tool is insufficient and directing to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions the returned fields, giving some transparency, but does not clarify behaviors such as pagination, ordering, the meaning of 'system flag', or the difference between organization options beyond what the schema already states. It is read-oriented ('List') but lacks deeper behavioral detail.
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 a single, clear sentence that immediately states the action and scope, with no extraneous information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a listing tool with no output schema and no annotations, the description provides essential purpose and fields but lacks other contextual details like return format, potential errors, or the semantics of allOrganizations vs organizations (though schema covers those). It is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 3 of 4 parameters (75% coverage), leaving 'search' undocumented. The description adds the context of 'one or many organizations', aligning with the organization-related parameters, but does not add meaning for 'search' or elaborate on the parameter usage beyond what the schema provides. Since coverage is moderate, the description partially compensates but not fully.
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 the tool lists teams (specific resource) with a scope of one or many organizations, and lists return fields (id, name, description, system flag). This distinguishes it from sibling tools like wflow_get_team (single team) and wflow_list_users (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool ('List teams in one or many organizations') and implies cross-organization capability, which is a distinct use case. However, it does not explicitly mention alternatives or when not to use it, but the scope itself provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the output structure (id, identity, hasFullAccess) and the allOrganizations sweeping behavior. However, it doesn't mention edge cases like pagination limits, error behavior, or whether organization parameters are mutually exclusive. This is adequate but has gaps.
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?
Two sentences, zero fluff. First sentence states purpose; second adds return shape and a tips. Perfectly front-loaded and economical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema, so description must compensate. It does explain return fields and the allOrganizations use case, but leaves ambiguity around the interplay between organization, organizations, and allOrganizations (e.g., mutually exclusive? precedence?). No mention of maxItems behavior. Moderate completeness for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83% (5/6 params described). The description adds value by explaining allOrganizations with a usage example, but doesn't cover maxItems (which lacks schema description). Since the schema does most heavy lifting, baseline 3 is appropriate; the description doesn't significantly elevate it.
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 the tool's function: 'List users in one or many organizations.' It specifies the resource (users), the action (list), and scope (one/many orgs). It also provides the return shape (id, identity, hasFullAccess), distinguishing it from sibling tools like wflow_get_user (single user) and wflow_find_users_with_right (filter by right).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for using allOrganizations: 'Use `allOrganizations` to sweep every org (e.g. to find where a user exists)' — a concrete use case. It doesn't explicitly mention alternatives or exclusions, but the context is clear enough for an agent to decide when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the act of attaching a file and does not disclose side effects such as replacing the main file, handling multiple attachments, or authorization requirements.
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?
Three concise sentences, each providing distinct information without redundancy. The purpose is front-loaded, with parameter semantics and workflow guidance following naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core usage and a recommended workflow, but omits behavioral details such as the response format, error handling, and clarification of the `organization` parameter. Given the tool's simplicity, it is adequate but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters described). The description adds explicit meaning to `main=true` and contextualizes `filePath` and `documentId` via the workflow. The `organization` parameter is undocumented but self-explanatory.
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 'Attach a local file to an existing document' with a specific verb and resource. It distinguishes from sibling tools by focusing on existing documents and mentioning a workflow with wflow_update_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit context for when to use the tool (attaching a file to an existing document) and suggests a workflow with wflow_update_document. It lacks explicit exclusion of alternatives like wflow_create_document_with_files, but the usage intent is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does convey a read-only implication via 'Return' and the GET endpoint, and it indicates authentication is involved ('authenticated account', 'confirm auth is working'). However, it does not disclose potential failure modes (e.g., unauthenticated requests), rate limits, or explicitly confirm there are no side effects, leaving some ambiguity.
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 two concise sentences. The first states the core function and endpoint, and the second adds a use case. There is no redundant phrasing or unnecessary detail, making it efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately covers purpose, use case, and the endpoint. It does not elaborate on return value structure or error handling, but the phrase 'return the authenticated account/identity' gives a reasonable sense of the output. Given the tool's low complexity, this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers the single parameter (organization) with a clear description: 'Organization slug. Defaults to WFLOW_ORG.' The description text adds no additional meaning to the parameter, but with 100% schema coverage the baseline is 3. No further elaboration is necessary here.
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 the tool's function: 'Return the authenticated account/identity for an organization' and provides the underlying HTTP endpoint '(GET /account)'. The verb 'Return' and the resource 'authenticated account/identity' are specific and distinguish this from sibling tools like wflow_list_users or wflow_get_user which deal with user listings rather than the acting identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Useful to confirm auth is working and see the acting user.' This tells the agent when to invoke this tool. It does not explicitly mention alternatives or when not to use it, but the guidance is sufficient for a simple identity-check tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the operation uses POST/PUT and that omitting teamId creates, while passing it updates. However, it does not explain effects on existing users (replace vs merge), required permissions, idempotency, or error handling. The HTTP semantics are helpful but incomplete for a mutation tool.
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 two sentences long, front-loaded with the action (Create/Update), and contains no filler. Every clause adds value: HTTP methods, body, and a usage example. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, and the description covers core usage (create/update, body, usage scenario). However, it omits the 'organization' parameter entirely and does not address update semantics (e.g., whether users are replaced or appended). The description is sufficient for basic use but incomplete for edge cases and full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the team object and teamId, but the description adds crucial meaning: how to select create vs update (omit or pass teamId). It also clarifies the team object structure (name, description?, users?). The 'organization' parameter remains undocumented in the description, but the overall parameter semantics are well explained beyond the schema.
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 the tool's function: create a team via POST (omit id) or update via PUT (pass teamId). It explicitly distinguishes the two modes and provides the body structure. The verb 'Create/update' and resource 'team' are specific, and the HTTP method clarification removes ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete use case: "This is how you 'create a new team X and add these users to it'." This implies when to use the tool (team creation/update) and differentiates from siblings like list or delete. However, it does not explicitly state exclusions or alternatives, but the context clearly separates it from wflow_list_teams and wflow_delete_team.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It transparently discloses a key side effect: the exported file is written to disk and its path returned. However, it does not mention whether documents are marked as exported by default, what the markAsExported parameter does in practice, or any permission/authorization requirements. This is moderate disclosure for a tool that potentially mutates state.
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?
Two sentences, front-loaded with the core action and format list, followed by the optional filter and the output behavior. Every word earns its place; no vague filler or repetition of schema field names without added meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 6 parameters, no output schema, and no annotations, the description covers the essential use case, the return value, and a practical application (comparing with accounting ledger). It omits details on format-specific parameters (the 'parameters' JSON string) and the implications of markAsExported, which could cause an agent to misuse the tool, but the core behavior is well specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 83% of parameters with descriptions. The description adds meaningful context for 'format' by listing all enum values, for 'filter' by calling it a StructuredFilter and explaining its purpose (narrow the set), and for the output via savePath by explaining that the path is returned. This goes beyond the baseline of schema-heavy coverage, though 'parameters' and 'organization' remain under-explained.
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 opens with the specific verb 'Export', identifies the resource ('documents'), and enumerates the supported formats. It also states the outcome (file written to disk, path returned), which clearly distinguishes it from sibling document retrieval tools like wflow_search_documents or wflow_get_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need to export documents in a specific accounting/ERP format. It also mentions optional narrowing with a StructuredFilter, which signals a comparison to search/filter tools. However, it does not explicitly exclude alternatives or state 'use wflow_search_documents for in-app filtering', so it lacks explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal key behavior: it sweeps all organizations, includes full-access users implicitly, and defaults to payment rights. However, it does not mention potential side effects (e.g., rate limits, performance on many orgs), authentication requirements, or output format, which are significant for an unannotated tool.
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 only two sentences, front-loaded with the primary purpose and then giving a concrete use case and parameter guidance. Every sentence earns its place, with no redundant filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema, the description provides enough context to understand the tool's operation and common use cases. It clarifies the default rights and the full-access nuance, but it does not explicitly describe how the organization parameters (organization vs. organizations vs. allOrganizations) relate to each other. Since schema descriptions cover these, the omission is acceptable, though a brief note would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 value by explaining the default behavior of `rights`, the significance of `includeFullAccess` (full-access users implicitly hold every right), and provides examples of other rights to check. This goes beyond the schema's field descriptions, justifying a 4.
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 uses a specific verb ('Sweep') and clearly states the resource ('organizations', 'every user who holds a given right') and scope ('cross-organization'). It also distinguishes itself from sibling tools like wflow_list_users by focusing on rights-based search across organizations, and gives a concrete example ('which users can pay across organizations?').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating the default rights (payment rights) and directly answering a common question. It also explains how to extend usage by passing the `rights` parameter with examples. However, it does not explicitly state when to avoid this tool or mention alternatives, so it stops short of 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses HTTP methods (POST/PUT), the body structure, and the rights enum names, adding useful behavioral context. However, it does not explain update semantics (replace vs merge), permissions, or side effects, which are important for a mutation tool.
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 two concise sentences, front-loaded with the core behavior and followed by specific parameter details. Every sentence earns its place without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (nested object, two modes) and the lack of annotations or output schema, the description covers purpose, parameters, and usage modes adequately. It could mention the response or organization parameter, but it is reasonably complete for an upsert operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning beyond the schema by explaining the role body structure, the roleId parameter, and the rights enum values. It does not explain the organization parameter, but schema coverage is 67%, so the description compensates well for the key parameters.
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 the tool creates or updates a role, using specific verbs and resource. It distinguishes from sibling tools like wflow_list_roles and wflow_delete_role by explaining the dual create/update behavior and the difference between POST and PUT.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use create (omit id) versus update (pass roleId). It does not explicitly mention alternatives or exclusions, but the sibling tools are clearly different operations, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well: it discloses the critical safety default (dry run, apply=false changes nothing), explains how to execute (apply=true), and describes patch merging. It doesn't mention permissions, lock handling, or reversibility, but the most important behavioral trait—the no-op by default—is clearly highlighted.
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?
Three tight sentences, front-loaded with the main purpose and the most important safety warning. The example is concrete and useful, and every clause earns its place. No redundant fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a bulk-mutation tool with 8 parameters and no output schema, the description covers the essential operational concerns: what the tool does, how the patch is applied, and the dry-run safety mechanism. It doesn't explain the interaction between organization params or maxItems/ignoreLock, but the schema provides their literal definitions. Overall it's sufficient for an agent to use the tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the schema covers all 8 parameters with descriptions (100% coverage), the baseline is 3. The description adds genuine value by explaining the patch as a partial DocumentUpdate merged with each document's id and providing a concrete patch shape. It also clarifies apply semantics beyond the schema's simple 'false = dry run; true = actually write'.
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 the action: 'Find every document matching a wflow query and apply the SAME partial patch to each.' This is a specific verb+resource with scope, and it distinguishes this bulk tool from singular tools like wflow_update_document or read-only search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete example use case ('set all documents with order Z01 to cost centre Centrála') and clearly explains the dry-run vs apply flow. It doesn't explicitly name alternatives like wflow_update_document for single-document updates, but the bulk-update intent is unmistakable from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses path templating, organization injection, query filter syntax, JSON body handling, and the WFLOW_READONLY write-blocking behavior. However, it does not mention response format, error handling, or authentication, which would have made it fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence and four focused bullets, each conveying a distinct operational rule. It is slightly verbose for a simple tool, but the complexity of the generic caller justifies the length; there is minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers request construction but omits any mention of return values, error handling, or pagination. Since there is no output schema, an agent may be left uncertain about what the tool actually returns when called, leaving a notable gap for a generic API caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning beyond the schema: explains how {organization} placeholders are resolved, provides a wflow filter syntax example for 'query', and clarifies that 'body' is sent as JSON for PUT/POST/PATCH. This is more than the schema alone provides.
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 the tool is a low-level escape hatch for calling ANY wflow public API endpoint, using a specific verb and resource. It distinguishes itself from the typed siblings by instructing to use it when no typed tool fits, and references wflow_api_catalog for discovery.
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?
Explicitly says 'Use this when no typed tool fits' and directs the agent to browse the surface with wflow_api_catalog first. This provides clear when-to-use guidance and contrasts with the many specific sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It states 'Unspecified fields are left unchanged', a key merge behavior for updates, and enumerates allowed permission values. It doesn't cover error cases or authorization requirements, but the primary side effects are transparent.
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 compact and well-structured: the first sentence states the purpose, and the second provides a structured field specification with enum values. No redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the nested user object and absence of an output schema, the description covers the primary fields and enum values. It does not clarify semantics for array fields (roles, teams, documentTypes) such as replace vs. merge, and the optional organization parameter is unexplained. These gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50% (only the user parameter is described). The description compensates by detailing the user object's body fields, including optional markers, and the allowed enum for permission. It also clarifies the merge behavior. However, the 'organization' parameter is not mentioned, leaving its purpose undocumented.
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 'Add (by `login`) or update a user's access', a specific verb+resource that distinguishes it from sibling tools like wflow_list_users, wflow_get_user, and wflow_delete_user. It also clarifies the upsert semantics explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this tool is for adding or updating a user identified by login. It doesn't explicitly name alternatives, but the upsert purpose is unambiguous given the sibling tool set. No exclusions or when-not-to-use guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains what the tool returns (name, baseURL, slug) and the significance of the slug as the `organization` parameter for other tools. It does not explicitly state read-only semantics, but 'List' implies it, and the useful context about slug mapping goes beyond a minimal list definition.
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 three sentences with no redundancy. Each sentence provides distinct value: what is listed, what fields are returned, and why the slug matters. It is well-structured and front-loaded with the core purpose.
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 simplicity (no parameters, no output schema), the description is complete. It states the resource, the accessible scope, the return fields, and how the output connects to other tools. No critical information is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. The description adds no parameter-specific details, but none are needed. The baseline of 4 applies here.
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 uses a specific verb ('List') and resource ('organizations'), clearly distinguishing it from siblings like list_roles and list_teams. It also explains the tool's role as the entry point for cross-organization tasks, which adds purpose beyond a generic list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use this tool ('entry point for any cross-organization task'), providing clear context. It does not need to mention alternatives because no sibling tool lists organizations, but it lacks an explicit 'when not to use' clause, preventing a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses auto-pagination, default slim rows vs. full objects, and the cross-org behavior. It does not mention permissions, error handling, or explicitly state read-only status, but the 'search/list' framing strongly implies a safe read. The behavioral details provided exceed the minimum.
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 compact and well-structured: a front-loaded summary followed by three bullet points and a return-value note. Every sentence earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description effectively explains the return behavior (slim default, full objects with slim=false) and covers all core parameters with examples. It omits details about the maxItems safety cap and pagination bounds, but these are present in the schema. Overall, it is complete enough for a search 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 schema coverage is 100%, the description adds significant value beyond the schema: it provides executable filter examples, explains the quoting rule, gives a sort format example, and illustrates when to use cross-org parameters. This transforms abstract parameter names into actionable knowledge.
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 the tool's verb+resource ('Search / list documents') and scope ('across one or many organizations'), distinguishing it from sibling tools like wflow_get_document (single document) and wflow_export_documents (export). The phrases 'wflow filter syntax' and 'auto-pagination' add specific behavioral detail not present in the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage examples for `query` (e.g., `orderNo = "Z01"`, `totalAmount > 1000`), `sort` (e.g., `created desc,totalAmount`), and explicitly explains when to use `allOrganizations` or `organizations` for cross-org queries. It does not explicitly name alternatives or state when not to use this tool, but the context and examples give clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses partial-update semantics ('unspecified fields are left untouched'), register resolution by code/externalId/id, and line item format. This is strong behavioral context, though it omits nuances like ignoreLock behavior.
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 three dense, front-loaded sentences: first states the core action, second explains register resolution with an example, third covers line items. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested object and lack of output schema, the description covers essential usage: create/update, partial update, register references, and line items. It does not mention return value or lock handling, but those are optional and the core usage is complete.
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?
The description adds substantial meaning to the nested `document` parameter, explaining register reference syntax with an explicit accounting example and line item structure. This goes well beyond the schema's minimal 'DocumentUpdate object' description.
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 the tool's dual function with a specific verb and resource: 'Create (omit id) or update (include id) a document.' This distinguishes it from siblings like wflow_search_documents or wflow_create_document_with_files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to create vs. update by omitting or including `id`, which is clear usage context. However, it does not explicitly mention alternatives or exclusions, such as bulk_update_documents, so it stops short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses critical behavioral traits. It details that PUT replaces the entire set and marks missing entries as invalid, which reveals destructive behavior. It also clarifies matching logic (by externalId or code) and the PATCH behavior of leaving other entries untouched. This is transparent and goes beyond a simple 'write' statement.
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 well-structured, using bullet points to present the two modes clearly. The opening sentence establishes the core action, and each detail (match key, invalid marking, entry fields) earns its place without redundancy. It is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior for a complex tool with two modes and no output schema. It explains the mode differences, match key, and entry format. However, it does not clarify the meaning or required format of the 'organization' parameter, nor does it describe the response format or success indicators. These gaps slightly reduce completeness, but the core usage is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%, with 'method' and 'entries' having descriptions. The tool description adds significant value by elaborating on the method parameter (explaining PUT vs PATCH semantics) and by specifying the expected entry structure {externalId?, code, description?, isValid?}, which the schema leaves open (additionalProperties). This enhances understanding beyond the schema, though the 'organization' parameter remains unexplored.
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 the tool's purpose: 'Write entries to a register.' It distinguishes between two modes (PUT and PATCH) and provides the title 'Create/update register entries (import a reference table),' which reinforces the resource and action. This makes it distinct from sibling tools like wflow_get_register and other wflow_upsert_* tools targeting different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each mode: PUT for full replacement (with ERP reference-table import context) and PATCH for partial updates. It explains the behavioral difference between the two, offering context without explicitly naming alternative tools, but the guidance is sufficient for selecting the appropriate mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation via 'Return the catalog' and adds context about the filter behavior and return fields. However, it does not explicitly state that the tool is non-mutating or mention any potential pagination/limits. The clear read verb and logical discovery purpose are sufficient to deserve a 4.
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 two concise sentences. The first states the purpose and output fields; the second provides usage guidance, alternative tool, and filter examples. Every sentence earns its place with no redundancy or 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 simplicity (one optional parameter, no output schema, no annotations), the description is complete. It covers what the tool returns, when to use it, how to filter, and the next step (wflow_request). It provides sufficient context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the filter parameter fully ('Case-insensitive substring matched against path, summary and tag'), giving a baseline of 3. The description adds value by reinforcing that the filter is optional, providing concrete examples, and explaining how filtering integrates with the catalog discovery workflow.
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 the tool's function: 'Return the catalog of wflow public API operations (method, path, summary, tag).' It uses a specific verb and resource, and explicitly distinguishes itself from siblings by positioning as a discovery tool for endpoints not covered by typed tools.
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 gives explicit usage guidance: 'Use this to discover endpoints that no typed tool covers, then call them with `wflow_request`.' This tells the agent when to use this tool and points to the alternative for invoking the discovered endpoints. Filter examples (e.g., 'payment', 'approval') further clarify usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![wflow-mcp-experimental MCP server](https://glama.ai/mcp/servers/wflowcom/wflow-mcp-experimental/badges/card.svg)](https://glama.ai/mcp/servers/wflowcom/wflow-mcp-experimental)

Score Badge

Copy to your README.md:

[![wflow-mcp-experimental MCP server](https://glama.ai/mcp/servers/wflowcom/wflow-mcp-experimental/badges/score.svg)](https://glama.ai/mcp/servers/wflowcom/wflow-mcp-experimental)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/wflowcom/wflow-mcp-experimental'

If you have feedback or need assistance with the MCP directory API, please join our Discord server