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

Annotations already declare readOnlyHint and idempotentHint. The description adds behavioral context by explaining that it examines flow configuration and returns suggestions, confirming it is non-destructive. It also details return values, adding further transparency.

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 well-structured with a clear introductory sentence, an 'Args' section, a 'Returns' section, and examples. It is concise yet informative, front-loaded with purpose, and every sentence serves a purpose.

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 an analysis tool with one required and two optional parameters, the description covers purpose, usage contexts, parameters, return structure, and provides multiple examples. This is sufficient for an agent to invoke the tool correctly, especially with the output schema available.

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 description provides an Args overview and examples that add context, but the schema already contains detailed descriptions for each sub-property (thus schema coverage is effectively high). The description adds value through examples but does not substantially extend beyond the schema.

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

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

The description clearly states the tool analyzes chatflows/agentflows and provides improvement suggestions. The verb 'analyze' and resource 'flow' are specific, and the purpose is distinct from sibling tools like create, delete, list, which are all different operations.

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 positions this as the primary tool for improvement-related queries and provides examples of targeted improvements using the improvement_goal parameter. However, it does not explicitly list when not to use it, though the context from sibling tools implies it.

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

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

The description notes that flow_data must be a valid JSON string and indicates the return includes the new ID. Annotations show readOnlyHint=false, consistent with a write operation. No contradictions detected. Additional context about permissions or side effects would improve transparency.

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 moderately concise with a clear structure (overview, Args, Returns, Examples). The first two sentences are somewhat redundant ('Create a new...' and 'This tool creates...'), but the overall layout aids readability.

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 the tool's core purpose, input requirements (JSON flow_data), and return value (new ID). It does not address error conditions or validation details, but for a straightforward create operation with output schema present, it is sufficiently complete.

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

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

The input schema already contains descriptions for all parameters (name, flow_data, flow_type, etc.). The tool description restates these parameter names and adds emphasis on flow_data being JSON, but does not significantly enrich parameter understanding beyond the schema.

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

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

The description explicitly states 'Create a new chatflow or agentflow in Flowise,' providing a clear verb ('Create') and specific resource ('chatflow or agentflow'). This effectively distinguishes the tool from sibling operations like update, delete, or list.

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

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

The description implies usage for creating new flows and provides examples for both 'CHATFLOW' and 'AGENTFLOW' types. However, it lacks explicit guidance on when not to use this tool (e.g., versus update) or alternative tools for similar tasks.

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

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

Annotations already indicate destructiveHint=true. The description adds 'This removes conversation history from the database. Use with caution.' which reinforces the destructive nature but does not disclose additional behavioral details like irreversibility or side effects. With annotations carrying the main burden, a 3 is appropriate.

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 (4 lines) and front-loaded with the core purpose. However, the Args and Returns sections are redundant with the schema and could be omitted. It earns its place for the caution but includes boilerplate.

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 annotations (destructive, idempotent) and an output schema (confirmation), the description is somewhat complete. However, for a destructive tool, it could explain what happens if flow_id is missing or whether deletion is permanent, which would improve safety. It meets minimum viability but lacks depth.

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

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

Schema description coverage is 0%, meaning the description does not elaborate on parameters beyond listing them ('Input containing flow_id, optional session_id and chat_id.'). The schema itself provides decent descriptions, but the description adds no extra meaning or usage guidance for parameters. With low coverage, the description fails to compensate.

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 explicitly states it deletes chat message history for a specific flow, using clear verb 'Delete' and resource 'chat history'. This distinguishes it from sibling tools like flowise_get_chat_history which retrieves history.

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 says 'Delete chat message history for a specific flow' and adds 'Use with caution', which implies the tool is for deletion when needed. However, it does not explicitly state when not to use or mention alternatives beyond the caution.

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

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

Adds information about irreversibility and return confirmation beyond annotations, but annotations already indicate destructive and idempotent traits; no new behavioral traits disclosed.

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?

Clear and well-structured with purpose, warning, and return; slight redundancy with schema but no unnecessary content.

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?

Covers basic action and warning but lacks details on error cases, prerequisites (e.g., flow must exist), or effects on dependent resources.

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 already provides description for flow_id; description only repeats parameter purpose without adding new meaning.

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 explicitly states the verb 'Delete' and resource 'chatflow or agentflow', clearly distinguishing from sibling tools like create or 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?

Includes a warning about irreversibility, which is a strong usage hint, but lacks explicit when-to-use or alternatives compared to other sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the description does not need to repeat these. The description adds that it returns 'detailed assistant information including configuration,' which is basic but not contradictory. It does not disclose any behavioral traits beyond what annotations provide.

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 short and front-loaded, clearly stating the purpose in the first sentence. It avoids unnecessary details, though the Python docstring format (Args/Returns) is slightly verbose. Overall, it is efficient.

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?

This is a simple read-only tool with a single required parameter and an output schema. The description adequately conveys that it returns detailed information, but it lacks usage context or examples. Given the low complexity, it is minimally viable but not comprehensive.

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 already provides descriptions for both parameters (assistant_id and response_format), so the schema coverage is effectively complete. The tool description merely restates parameter names without adding new meaning, so a baseline score of 3 is appropriate.

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

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

The description clearly states 'Get detailed information about a specific assistant,' which uses a specific verb ('Get') and a well-defined resource ('assistant'). This distinguishes it from sibling tools like flowise_list_assistants, which list multiple assistants.

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 no guidance on when to use this tool versus alternatives such as flowise_list_assistants or other get-type tools. There is no mention of prerequisites, context, or 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is clear. The description adds minimal behavioral context beyond 'retrieve history' and 'returns list of chat messages with timestamps and content,' which aligns with annotations. It does not contradict them.

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 front-loaded with the main purpose and uses a clear structure. However, the 'Args' and 'Returns' sections repeat schema info, making it slightly longer than necessary. Still, it's reasonably concise.

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 simplicity (one parameter object with four sub-parameters, good annotations, and an output schema), the description adequately covers the basic functionality. It mentions the return format (list with timestamps and content) but omits details like ordering or pagination, which are partially covered by the schema's limit parameter.

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 description lists the parameters (flow_id, session_id, limit, response_format) but does not add significant meaning beyond what the input schema already provides. The schema has descriptions for each parameter, so the description's summary is redundant. Baseline 3 due to 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 title 'Get Chat History' and description 'Retrieve chat message history for a specific flow' clearly state the action (retrieve) and resource (chat history for a specific flow). It distinguishes from sibling tools like flowise_delete_chat_history and other get/retrieve tools.

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

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

The description mentions the tool is 'useful for reviewing past interactions or debugging,' providing a use case. However, it does not explicitly state when not to use or mention alternatives. Implicitly, it's for reading, but lacks clear exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, indicating safe, non-destructive, and idempotent behavior. The description does not add extra behavioral context beyond these annotations.

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

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

The description is concise with two sentences and a structured Args/Returns block. However, the formatting adds slight redundancy and could be streamlined.

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 simple nature of the tool and presence of annotations and output schema, the description provides minimal but adequate information. It does not explain the response format or any potential edge cases.

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 description only lists parameter names (store_id and response_format) without adding meaning beyond what the input schema already provides. Schema descriptions exist but the tool description does not elaborate on their usage or constraints.

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 action (Get) and resource (detailed information about a specific document store). It distinguishes from siblings like flowise_list_document_stores which lists all stores, while this retrieves details for a single store.

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

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

No guidance on when to use this tool versus alternatives such as flowise_list_document_stores for listing or other get tools. The description simply states the function without providing usage context or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is clear. The description adds context about retrieving nodes, edges, and settings, which goes beyond annotations without contradiction.

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 well-structured with Args/Returns sections and front-loaded purpose. It is not overly verbose but could be slightly more concise by removing redundant self-explanatory sections.

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 simplicity, presence of annotations, and an output schema, the description covers purpose, parameters, and example adequately. No missing critical 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?

Despite 0% schema description coverage from context signals, the tool's description explicitly mentions the params object with flow_id and response_format, explains response_format options, and gives a usage example, compensating for the gap.

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 verb 'Get' and resource 'detailed information about a specific chatflow or agentflow', including full configuration. It distinguishes from sibling tools like flowise_list_flows (list) and flowise_analyze_flow (analyze).

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 example ('Use with the flow ID from flowise_list_flows') implying a prerequisite, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives like flowise_update_flow or flowise_analyze_flow.

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

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

Annotations already convey readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds minimal behavioral info beyond 'list all assistants,' with no mention of pagination or filtering. Adequate but not enriching.

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 short and includes structured Args/Returns sections. It wastes no words, though the Args section is somewhat redundant.

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

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

Given the output schema exists (assumed) and annotations provide safety, the description is fairly complete for a simple list tool. Could mention if there's any pagination or default ordering.

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?

With schema description coverage at 0%, the description needed to compensate but only restates 'params: Input containing response_format' without explaining the parameter's purpose or impact. Schema has enum but description adds no value.

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 'List all assistants configured in Flowise,' which is a specific verb-resource combination. It distinguishes from siblings like 'flowise_get_assistant' by indicating it lists all, not just one.

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

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

No explicit guidance on when to use this tool versus alternatives (e.g., flowise_get_assistant for a single assistant). The description provides background on assistants but no usage context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, which sufficiently convey safety. The description adds that the tool returns a list with details, but does not disclose any other behavioral traits like pagination, performance implications, or side effects. The description adds marginal value beyond the annotations.

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

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

The description is three sentences with a clear front-loaded purpose, followed by structured Args and Returns sections. No filler or redundant information, making it efficient for an AI agent to parse.

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 tool has one parameter and a presumably defined output schema. The description mentions the return format ('list with details') which is sufficient for a simple list operation. While more detail on response_format could be helpful, the output schema likely handles that. The overall completeness is good for the tool's simplicity.

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

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

Schema description coverage is 0%, meaning no property descriptions exist beyond the param name. The description only states 'params: Input containing response_format' without explaining the enum values, default, or behavior. Given the low coverage, the description fails to compensate.

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 explicitly states 'List all document stores configured in Flowise' which identifies the specific verb (list) and resource (document stores). It also explains that these stores contain indexed documents for RAG, providing context that distinguishes it from other list tools like list_flows or list_assistants.

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 no guidance on when to use this tool versus similar list tools (e.g., flowise_list_document_stores vs flowise_get_document_store) or under what conditions it is appropriate. No alternatives or exclusions are mentioned.

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

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

Annotations already indicate read-only, non-destructive, idempotent behavior. The description adds context on the returned summary (deployment status, visibility, categories) and output formats, enhancing transparency without contradiction.

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 structured with Args, Returns, and Examples sections, front-loaded with the main purpose, and every sentence provides useful information.

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 list tool with an output schema, the description covers input filtering, output format, and examples. No gaps remain.

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 already includes clear descriptions for flow_type and response_format. The description adds examples and usage context, providing additional meaning beyond the schema.

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

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

The description precisely states 'List all chatflows and agentflows in the Flowise instance' with a clear verb and resource, and it distinguishes from siblings like flowise_get_flow and flowise_analyze_flow.

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 examples for different use cases (no params, flow_type filter, response_format) but does not explicitly exclude when to use alternatives for detailed single flow info.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds no new behavioral details beyond stating it retrieves a list. It does not contradict annotations, but also does not elaborate on any behavioral traits.

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 well-structured: a single sentence stating the purpose, followed by a clear Args/Returns format. Every sentence adds value with no wasted words.

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 simplicity (listing tools), the description covers the essential purpose and output. It mentions the input parameter and return type. Annotations and output schema provide additional context. It does not elaborate on edge cases or error scenarios, but that is acceptable for a straightforward 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?

Input schema coverage is 0% meaning schema properties lack descriptions, but the description includes a minimal 'Args: params: Input containing response_format.' This adds some meaning, though the schema itself already has descriptions for the input model and response_format. The description does not clarify the parameter's purpose beyond what is in the schema, and it omits details about the default value or enum options.

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: 'List all tools available in Flowise.' The verb 'List' and resource 'tools' are specific, and the tool is distinct from sibling tools that list other entities (e.g., flows, assistants).

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 does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, there is no mention of context, preconditions, or when not to use it. The sibling names imply differentiation, but not explicitly.

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

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint. Description adds no extra behavioral context beyond confirming it's a list operation.

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

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

Front-loaded with purpose, then args/returns section. Could be slightly more concise but no wasted sentences.

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

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

With annotations and output schema present, description adequately explains what the tool does and returns. Minimal but sufficient.

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?

Input schema has one parameter with descriptions; description just restates 'params: Input containing response_format' without adding meaningful guidance on options like json vs markdown.

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 title and description clearly state the verb 'list' and resource 'global variables', distinguishing it from sibling tools like list_flows or list_assistants.

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 context about variables storing API keys/URLs, but no explicit when-to-use vs alternatives, no exclusions.

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

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

Annotations already provide readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds that it returns a server status message, which is useful context beyond annotations.

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

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

Three short sentences with no wasted words. The purpose is front-loaded, and structure is efficient.

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 health-check tool with no parameters, the description is complete: it states purpose, usage, and return value.

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?

No parameters exist, so schema coverage is 100%. The description doesn't need to add parameter details. Baseline 4 is appropriate.

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

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

The description clearly states the tool checks if the Flowise server is reachable and responding, which is a specific verb+resource. It distinguishes from sibling tools that perform actual operations.

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 says 'Use this tool to verify connectivity before making other requests', providing clear guidance on when to use this tool versus alternatives.

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

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

Annotations already indicate the tool is not read-only (readOnlyHint: false) and has potential side effects (openWorldHint: true). The description adds a warning about streaming not being recommended for MCP but does not detail other behavioral traits like state changes or authentication needs.

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

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

The description is well-structured with separate sections for Args, Returns, and Examples, and it front-loads the purpose. However, it is slightly verbose, repeating 'flow' multiple times.

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 (sending messages with optional session and overrides) and the existence of an output schema, the description covers the main points adequately. It could be more complete by explaining the streaming warning or the nature of override_config.

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?

Despite 0% schema description coverage for the top-level param, the description lists the key parameters (flow_id, question, session_id, streaming, override_config) and adds context (e.g., streaming not recommended). However, it doesn't fully compensate for the lack of formal parameter descriptions in the schema.

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

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

The description clearly states the tool sends a message to a chatflow or agentflow and returns a response, distinguishing it from sibling tools like analysis, creation, or deletion tools.

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

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

The description provides examples (simple question, with session, override settings) but lacks explicit guidance on when not to use this tool or how it compares to alternatives among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds useful behavioral context (output format: 'retrieved documents with relevance information') beyond annotations, but does not cover pagination or error conditions.

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 (2 sentences) and front-loaded with the main purpose. Every sentence adds value; no redundant or vague wording.

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

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

With an output schema present, the description's mention of 'relevance information' is sufficient. It covers the core function and parameters, but lacks detail on the exact structure of the output or the difference between querying a vector store vs. a document store directly.

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 provides descriptions for store_id and query. The description only restates 'Input containing store_id and query', adding no new semantics. Schema coverage is marked 0% but nested parameters are described, so baseline 3 is appropriate.

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

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

The description explicitly states the verb 'execute a retrieval query' and the resource 'document store's vector store', clearly differentiating it from sibling tools like flowise_upsert_vector (writes) or flowise_get_document_store (reads store metadata).

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

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

No guidance on when to use this tool versus alternatives (e.g., flowise_get_document_store for listing stores, or flowise_upsert_vector for adding documents). The description does not mention context, prerequisites, or exclusions.

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

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

Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true. The description adds the partial update behavior ('only provided fields will be updated') which is not in annotations, but does not disclose other traits like authorization needs or rate limits.

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 with three sentences plus bulleted examples, structured with Args, Returns, and Examples sections. Every part adds value without redundancy.

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

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

The description covers the partial update behavior and provides examples for common use cases. It does not specify the format of flow_data (JSON string) or detail the return structure, but these are provided in the input schema and output is hinted at. Overall adequate for a tool with good schema coverage.

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 description does not individually describe parameters, but the input schema has clear descriptions for each field. The description provides usage examples (rename, update config, make public) that add contextual meaning beyond the schema, compensating for the lack of parameter descriptions in the text.

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 'Update an existing chatflow or agentflow', specifying a specific verb and resource. It distinguishes from sibling tools like create, delete, and get, making the purpose unambiguous.

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 mentions that 'Only provided fields will be updated', implying it's a partial update, but lacks explicit guidance on when to use this tool versus alternatives like create or delete. No exclusions or prerequisites are stated.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the mutation nature is known. The description adds that the tool 'triggers the flow's document processing pipeline', providing context about side effects beyond the annotation, but lacks details on auth, rate limits, or what gets destroyed.

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 reasonably concise with separate 'Args' and 'Returns' sections, though the 'Args' section adds little value beyond the schema. It fits within a few lines and is front-loaded with the main action.

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 the basic intent and pipeline triggering, but lacks details on edge cases (e.g., invalid flow_id) and behavior (insert vs. update logic). An output schema exists, so return value details are less critical, but the description is still incomplete for a mutation tool with pipeline side effects.

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 provides detailed descriptions for all parameters (flow_id, override_config, stop_node_id), so the description adds little new semantic meaning. The description briefly mentions 'flow_id, optional override_config and stop_node_id' but does not enrich beyond the schema.

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

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

The description clearly states 'Insert or update vectors in a chatflow's vector store,' with a specific verb-resource pair that distinguishes this tool from siblings like flowise_query_vector_store. The title 'Upsert Vectors to Flow' reinforces the purpose.

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 mentions 'triggers the flow's document processing pipeline' but provides no guidance on when to use this tool versus alternatives (e.g., flowise_query_vector_store for reading). No explicit context for when-to-use or when-not-to-use.

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