autoflow-mcp

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the basic action and target states, but does not mention that cancellation is likely destructive or irreversible, whether partial outputs/assets remain, or what side effects the user should expect. For a cancellation operation, this is a significant gap.

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 a single focused sentence with no filler. The verb and resource are front-loaded, and every word contributes to the core meaning. It is appropriately concise for a one-parameter tool.

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 no annotations and no output schema, the description should provide more context for a destructive operation. It does not explain what happens after cancellation, whether cancellation can be undone, or how to avoid cancelling the wrong job when jobId is omitted. The schema covers the parameter, but the behavioral context is incomplete.

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 100%, so the schema already documents the jobId parameter and its default behavior when omitted. The description adds context that the job is a generation job, but does not add meaningful parameter semantics beyond that. 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 uses a specific verb ('Cancel'), names the resource ('generation job'), and scopes it ('running or queued', 'in Google Flow'). It clearly communicates what the tool does, though it does not explicitly differentiate itself from sibling tools like autoflow_clear_queue.

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 intended use is implied: cancel a running or queued generation job. However, there is no explicit guidance about when to prefer this over autoflow_clear_queue, when omitting jobId is appropriate, or what the user should expect if multiple jobs are active. The parameter schema provides some of this, but the description itself does not.

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?

With no annotations provided, the description carries the full behavioral burden. It clearly states the tool captures a JPEG screenshot and implies a non-mutating, read-only operation by framing the result as visual inspection material. It does not explain how the screenshot is returned or stored, but for a zero-parameter screenshot action this is a minor gap.

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 one concise sentence with no filler. It front-loads the action and output format, then presents the intended use cases. Every clause earns its place.

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 low-complexity, zero-parameter tool with no output schema, the description gives the essential context: what is captured, in what format, and why the agent would want it. It could explicitly state how the screenshot is delivered or that it does not alter the project, but the current level is adequate and close to 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 tool has zero parameters and the schema description coverage is 100%, so there is no parameter information for the description to add. The baseline of 4 applies because no parameter semantics are needed.

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

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

The description uses a specific verb ('Capture') and a concrete resource ('visual JPEG screenshot of the Google Flow project workspace'), then states three clear purposes: inspect progress, verify visual output, and diagnose UI state. This fully distinguishes the tool from siblings like autoflow_status or autoflow_get_recent_assets.

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 clear contexts for use: inspecting progress, verifying visual output, and diagnosing UI state. It does not explicitly name alternative sibling tools or state when not to use it, but the use cases are sufficiently specific to guide an agent.

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?

No annotations are present, so the description carries the full burden of explaining behavior. It states what is cleared but does not disclose that the action is destructive/irreversible, whether only queued jobs are affected, or what happens to in-progress jobs. This is a significant gap for a clearing 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?

The description is a single, clear, front-loaded sentence with no filler. It communicates the essential action and scope efficiently.

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 zero-parameter tool the description is minimal but arguably sufficient to understand the basic action. However, with no annotations and no mention of irreversibility, confirmation behavior, or relationship to sibling tools like autoflow_cancel, it leaves meaningful gaps for an agent deciding whether this is the right destructive operation.

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 has zero parameters, so there are no parameter meanings to explain. The description still adds value by specifying the scope of the operation ('all pending queued generation jobs'), which is the relevant semantic content.

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

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

The description uses a direct verb (Clear) with a specific resource (all pending queued generation jobs). It clearly distinguishes itself from siblings like autoflow_get_queue (viewing) and autoflow_generate (creating) by stating the scope of the action.

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 is provided about when to use this tool versus alternatives such as autoflow_cancel or autoflow_get_queue. The description does not mention prerequisites, exclusions, or any decision criteria for choosing this tool.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does add one genuinely useful trait — 'queued sequentially' — which tells the agent that calls are enqueued and processed in order rather than run concurrently. However, it does not disclose whether the call blocks until completion or returns immediately, what it returns (e.g., a job ID), failure/timeout behavior, or the download implications of autoDownloadResourceQuality.

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?

A single ~25-word sentence where every phrase earns its place: action, platform, models, mechanism, and queuing behavior. The main action is front-loaded, and there is zero filler or repetition of schema 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?

This is a complex tool — 9 parameters, asynchronous generation, no annotations, and no output schema — yet the description is a single sentence. It never mentions what to expect after invocation (immediate return vs. blocking, job references), how to monitor the queued job (despite autoflow_get_queue and autoflow_status existing as siblings), or the auto-download workflow. The 100% schema coverage mitigates the parameter-side gap, but the workflow-side gaps remain significant.

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 100%, so the baseline is 3; every parameter already has a meaningful description and enums where applicable. The description loosely maps to parameters ('Veo 3 or Nano Banana' → model, 'video or image' → mode), but it adds no syntax, defaults, or format details beyond what the schema already provides.

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

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

The description states a specific verb ('Generate'), a clear resource ('AI video or image on Google Flow'), the relevant models ('Veo 3 or Nano Banana'), and the mechanism ('via the Autoflow extension'). It is immediately distinguishable from all siblings, which are queue/status/management tools (autoflow_status, autoflow_get_queue, autoflow_clear_queue, etc.) — an agent can tell this is the content-creation tool without opening the schema.

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 phrase 'queued sequentially' implies a queue-based workflow, which loosely suggests that sibling tools like autoflow_get_queue or autoflow_cancel manage the resulting jobs. However, the description never explicitly states when to use this tool vs. its queue-management siblings, nor does it say when not to use it. Usage context is implied rather than 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?

No annotations are provided, so the description is the sole source. The verb 'inspect' suggests a read-only operation, but it does not explicitly state that no modifications or side effects occur. The behavioral trait is implied rather than 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?

The description is a single, compact sentence that conveys the tool's purpose and the returned information without redundancy. It is well-structured and immediately scannable.

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 no output schema and no parameters, the description adequately explains what the tool returns (active job, pending jobs, recent history). It provides sufficient context for an agent to decide whether to call the tool and what to expect from the response.

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

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

The tool has no parameters, so schema coverage is trivially high. The description adds nothing about parameters because there are none, which is appropriate. The baseline score of 3 applies as no additional parameter explanation is needed.

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 'Inspect' and the specific resource 'current status of the Autoflow sequential job queue', enumerating the aspects covered (active job, pending jobs, recent history). This unambiguously distinguishes it from sibling tools like autoflow_status, which likely reports overall status rather than queue details.

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 checking queue details but does not explicitly mention when to prefer this over alternatives (e.g., autoflow_status) or provide any context for selection. Basic guidance is inferred from the verb, but explicit direction is missing.

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?

With no annotations, the description must carry the behavioral burden, but it only states the action. It does not clarify what 'recent' means, whether partial or failed generation assets are included, whether the list is ordered or limited, or what the return structure looks like.

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 one sentence, starts with the active verb, and contains no filler. It is front-loaded and immediately communicates the core operation.

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 definition is usable for a no-parameter list tool but lacks the semantics of 'recent', any description of the output shape, and explicit differentiation from sibling tools. Given no output schema, the agent still has to guess return details.

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

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

The tool accepts zero parameters, so the schema is trivially complete. The description adds domain context by identifying what the returned items are (video and image assets), which is enough for a parameterless tool.

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 names the specific operation ('scan and list') and the resource ('recent video and image generation assets... on Google Flow project canvas'). This is distinct from sibling tools such as autoflow_generate (creating assets) and autoflow_get_queue (queue items), so the agent can identify the correct tool immediately.

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 is given about when to call this tool versus alternatives like autoflow_get_queue or autoflow_list_characters. There is no explicit 'when to use' or 'use this instead of' statement; the usage must be inferred from the resource name.

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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does clearly state that the tool automatically detects and dismisses specific UI blockers, which is useful. However, it does not explain what happens when no dialogs are found, whether the heal is verified, or whether dismissal has side effects on the flow state.

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 entire description is one front-loaded sentence that states the action and then specifies the exact objects it handles. There is no filler, redundancy, or repetition of structured schema data.

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

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

For a zero-parameter action with no output schema and no annotations, the description is adequate but leaves gaps. It does not say whether the tool returns success/failure, whether an active flow or tab must already be open, or whether the healing is verified after execution.

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

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

The tool has zero parameters and the schema is fully covered, so there is no parameter ambiguity to resolve. The description adds no parameter details, but none are needed.

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 names a concrete action ('Trigger self-healing') and enumerates the exact targets: Google Flow error dialogs, rate limit popups, and warning snackbars. This is specific enough to distinguish it from siblings like autoflow_reload_tab or autoflow_cancel, which address different failure modes.

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?

It gives clear context for when to use the tool: whenever blocking Google Flow error dialogs, rate limit popups, or warning snackbars are present. It does not explicitly name alternatives or exclusion cases, but the trigger conditions are stated plainly.

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?

With no annotations present, the description carries the full burden of disclosing behavior. It says 'Scan and list' which implies a read-only operation, but does not explicitly state that no modifications occur, 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.

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

The description is a single, concise sentence that immediately states the action and target, with no unnecessary wording or structure issues.

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?

Without an output schema, the description sufficiently implies the return type (a list of character tags) and the scope (current project). It is complete enough for a simple listing operation, though it could explicitly mention the output format for extra clarity.

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

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

The tool has no parameters, so schema coverage is trivially 100%. The description does not add any parameter-specific information, but none is needed; the baseline 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 a specific action (list) and resource (character tags in the currently open Google Flow project), making it unambiguous and distinct from sibling tools like autoflow_status or autoflow_get_recent_assets.

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 is provided about when to use this tool versus its alternatives. The description simply states what it does without any conditional 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?

With no annotations provided, the description carries the full burden of disclosure. It adequately describes the core behavior: instructing the Autoflow extension to open a specific URL in the active browser tab. While it does not mention side effects like navigation history or page load failure, the described action is simple and low-risk.

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 a single, information-dense sentence. It states the action, the target resource, the exact URL, and the browsing context without any filler or redundant 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?

Given the tool has zero parameters, no output schema, and no annotations, the description is fully sufficient for an agent to invoke it correctly. There are no remaining behavioral or contextual details needed for successful execution.

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

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

The tool has zero parameters, so there is no parameter ambiguity to resolve. Per the baseline for 0-parameter tools, the description needs to explain no schema fields, and it does not introduce any confusion. The lack of parameter detail is not a gap here.

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 a specific verb ('open'), a specific resource ('Google Flow'), and includes the exact URL. It also disambiguates the navigation context ('in an active browser tab'), making it distinct from sibling tools like reload_tab or clear_queue.

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 gives clear context for when to use the tool: when the user wants Google Flow opened in the active browser tab. It does not explicitly name alternatives or exclusion cases, but the intended use case is unambiguous enough for an agent to select it appropriately.

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?

No annotations are provided, so the description carries the burden of explaining behavior. It does so by disclosing that the action is a forced reload and that the extension bridge is re-mounted, which implies a non-graceful reset of the tab state. It could mention potential disruption to in-progress operations, but 'force-reload' already signals that.

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 a single, tightly written sentence that front-loads the action and then provides the triggering condition. Every word earns its place, with no redundant phrasing or filler.

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

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

For a zero-parameter recovery action with no output schema, the description is complete: it states what the tool does, what it re-mounts, and when to invoke it. No additional context is needed for an agent to call it correctly.

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

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

The tool has zero parameters and the schema is empty, so there are no parameter ambiguities to resolve. Per the baseline for zero-parameter tools, the description need not add parameter-level detail, and it appropriately focuses on the action and condition.

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 names a specific verb ('force-reload'), a specific resource ('the Google Flow project tab'), and a distinct secondary action ('re-mount the extension bridge'). This clearly separates it from siblings like autoflow_heal_flow or autoflow_status, which target different concerns.

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 a clear condition for use: 'if the web app appears frozen or unresponsive.' It does not explicitly name alternative tools or state when not to use it, but the triggering context is concrete enough for an agent to select it appropriately.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a non-mutating status check, which is helpful, but it does not describe what the status result looks like (e.g., connected/disconnected values, payload shape) or whether it actively pings the extension.

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 a single, front-loaded sentence that conveys the verb, object, and scope with no filler or repeated schema 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 parameterless status-check tool, the description is sufficient for an agent to know when and why to invoke it. The only gap is the lack of guidance about the returned status representation, and there is no output schema to cover that.

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

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

The tool takes zero parameters, so 100% schema coverage is vacuously true and there are no parameter semantics for the description to clarify. The baseline for zero-parameter tools is 4.

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?

Description names a specific action ('Check'), a clear object ('connection status'), and a scope ('Autoflow Chrome Extension and Google Flow tab'). This distinguishes it from the sibling tools, which all refer to operations on assets, queues, flows, or screenshots rather than a status probe.

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 use case is implied: call this when you need to verify connectivity of the extension or Google Flow tab before other Autoflow actions. However, the description provides no explicit when-to-use guidance, exclusions, or comparison to the listed sibling tools.

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