Run a named Kitsune workflow from the bridge workflow directory, passing optional template variables, to automate browser tasks through an existing Firefox session.
Execute a named Kitsune workflow from the bridge workflow directory.
Args: name: Workflow file name without .md variables: Optional template variables for the workflow
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| variables | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations the description carries the full burden, and it discloses little beyond the directory location and the .md naming convention. It does not say whether execution is blocking, what happens on missing/invalid workflow names, whether template variable failures abort the run, or what is returned.
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?
One purpose sentence followed by a compact Args block; front-loaded and free of filler. The docstring-style formatting is functional rather than tightly prose-optimized, but nothing is wasted.
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?
No annotations and no output schema, so the description should carry more for a tool that triggers a multi-step browser workflow. It covers the two parameters but omits runtime behavior (blocking vs. async, result/return shape, error handling), leaving an agent unsure what to expect after invoking it.
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%, so the description must compensate, and it does reasonably: it defines 'name' as the workflow file name without the .md extension and labels 'variables' as optional template variables. It still leaves the shape/keys of the variables object undefined, but for two params this adds real meaning beyond the empty 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?
States a specific verb (Execute) and resource (a named Kitsune workflow from the bridge workflow directory), which tells an agent what it gets. It stops short of explicitly differentiating from the sibling browser_workflows (plural), which presumably lists workflows, so the boundary is left to inference.
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 when-to-use or when-not-to-use guidance is given, and no alternative is named. The only implied context is that a workflow must already exist in the 'bridge workflow directory', but the agent is not told how to discover one or when to prefer this over chaining native browser tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.