Fetch Hive

Publish a workflow as a share page

share_workflow

Make a public link for a workflow, the dashboard's Share button: anyone with the link can run the workflow as it is now, with their own inputs, billed to this account (within the page's monthly limits). Steps that use connected accounts, knowledge bases or approvals cannot be shared; the call says which steps block it. Call it first without approved: it checks the workflow and returns the page copy it would publish (pass draft_copy: true to have the copy written for you). Show the person, then call again with approved: true and the copy they agreed to.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "workflow_id": "<workflow_id>"
    },
    "name": "share_workflow"
  }
}

Input Schema

Name	Required	Description
`copy`	No	What visitors see on the page.
`approved`	No	true only after the person has agreed to publish this page.
`campaign`	No	The Campaign tag (e.g. GRO-264). Private: visitors never see it. A blank value clears it.
`draft_copy`	No	Draft any copy fields you left out. Default false.
`workflow_id`	Yes	The workflow to share.
`customer_label`	No	The Customer label tag (e.g. the lead's company). Private: visitors never see it. A blank value clears it.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only say this is a non-read-only, open-world, non-idempotent, non-destructive call; the description goes well beyond that by disclosing the public exposure (anyone with the link can run it), the billing model (billed to this account within monthly limits), and the blocked-step conditions. It also explains the draft/approve gating behavior, which is the key safety-relevant trait of this mutation.

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?

Three sentences, front-loaded with the effect, then the constraints, then the procedure — nothing is redundant. It is dense to the point of being a single block, and the closing instruction is long, but every clause carries operative information.

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 six-parameter, nested-object mutation with no output schema, the description covers the effect, exposures, exclusions, and the required call sequence, and it says the pre-approval call returns the copy that would be published. It does not address what happens when a share already exists (create vs update), nor any permission requirements, which leaves a small gap for a tool with siblings like update_share.

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 schema baseline already carries the parameter meanings; the description nonetheless adds real semantics for the two behavioral flags — approved is a confirmation gate after human agreement, and draft_copy causes the server to write missing copy fields. The nested copy object itself is only alluded to as 'the page copy it would publish', leaving field-level meaning to the schema.

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

Purpose4/5

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

The description opens with a specific verb and resource ('Make a public link for a workflow') and grounds it in a familiar UI affordance ('the dashboard's Share button'), so the agent knows exactly what is produced. It does not name any sibling (update_share, publish_gateway, share_agent) to distinguish scope, so it stops short of the top mark.

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?

It prescribes a concrete two-pass workflow: call first without approved to get the copy, show the person, then call again with approved: true and the agreed copy. It also states the exclusion case (steps using connected accounts, knowledge bases or approvals cannot be shared) and that the call reports which steps block it. This is explicit when-and-how guidance rather than implied usage.

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

All Fetch Hive tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?