Fetch Hive

Change a share page

update_share

Change a share page's copy or default inputs, set its private customer_label and campaign tags (no approval needed when that is all you change), republish it with the workflow or agent as it is now (republish: true), or turn it off (status: disabled) or on again (status: active; agent pages can also be paused). Turning a page off needs no approval. Anything that changes what visitors see: call without approved first, show the person the change, then call again with approved: true.

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": {
      "share_id": "<share_id>"
    },
    "name": "update_share"
  }
}

Input Schema

Name	Required	Description
`copy`	No	What visitors see on the page.
`status`	No
`approved`	No	true only after the person has agreed to the change.
`campaign`	No	The Campaign tag (e.g. GRO-264). Private: visitors never see it. A blank value clears it.
`share_id`	Yes	The share_id from list_shares.
`republish`	No	Publish the workflow's current version to the page.
`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 readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false — the description adds the non-obvious approval protocol (call without approved, show the person, call again with approved: true) and the exemptions, which the agent could never infer from the annotations or schema. It also discloses that 'paused' applies only to agent pages and that republish pushes the current version of the sibling entity onto the page.

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?

Every clause carries operational information — the operations, the approval exemptions, and the two-step flow — with no filler. It is, however, a single dense run-on with stacked parentheses, so the approval rule (arguably the most important part) sits at the end rather than being front-loaded.

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

Completeness3/5

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

For a 7-parameter mutation with a nested copy object and no output schema or return documentation, the biggest unaddressed question is whether supplying copy with only some fields merges or replaces the existing page copy, which materially affects how an agent should call it. The approval and status semantics are well covered, so the gap is narrow but real.

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?

With 86% schema coverage the baseline is 3, and the description earns above that by attaching operational meaning to parameters: republish: true means publish the workflow/agent as it is now, status: disabled/active is an on/off switch, and campaign/customer_label changes may skip approval. It still doesn't clarify the copy/patch merge semantics or the interaction between approved and status changes.

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

Purpose5/5

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

The description names a specific verb and resource (change a share page) and then enumerates the four distinct operations packed into it: copy/default-input edits, private tag updates, republishing the current workflow/agent version, and status toggling. A reader can distinguish it from get_share, run_share, and use_share, and the parenthetical 'republish it with the workflow or agent as it is now' implies the underlying agent/workflow itself is edited elsewhere.

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

Usage Guidelines4/5

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

It gives explicit when-approval-is-unnecessary conditions (tag-only changes, turning a page off) versus the when-required case (anything that changes what visitors see), plus a concrete two-step procedure. It does not name a specific alternative tool for editing the underlying workflow/agent, so it stops short of full 5-level routing guidance.

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?