Skip to main content
Glama

reassign_shared_item

Destructive

Change who is responsible for an item in an AccountHub shared project (shared project) — NOT a Slack workspace. Anyone may choose the first assignee of an unassigned to-do (for a decision / open question / note: its placer) and becomes its requester. After that only the REQUESTER changes the assignee or chooses again after a decline (the person taken off it is notified). The CURRENT assignee may hand it back with to: null and a reason (the requester is notified); use respond_to_shared_item to accept. The target must be an active member — someone still invited cannot be chosen. assignee_agent addresses one of the target's assistants (e.g. your own email + 'chatgpt' hands it to your ChatGPT).

Input Schema

NameRequiredDescriptionDefault
toYesEmail of the ACTIVE member (or yourself) who should do it — chooses the first assignee, changes it, or chooses again after a decline. null = you, the current assignee, hand it back to the requester (decline while it is still only sent to you, hand back once accepted; needs `reason`).
reasonNoWhy, one line (max 200 characters). Required when handing it back; shown to the requester.
item_idYesThe item id (from list_shared_items).
assignee_agentNoWith `to`: to address a person's specific assistant, e.g. your own ChatGPT — 'chatgpt', 'claude' (claude.ai) or 'claude-code'. Omit = all of their assistants. Same person + another assistant = only the address changes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / to / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / to / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed1 schema field changed
    • addedInput schema / properties / assignee_agent
      Added value: +{
      +  "description": "With `to`: to address a person's specific assistant, e.g. your own ChatGPT — 'chatgpt', 'claude' (claude.ai) or 'claude-code'. Omit = all of their assistants. Same person + another assistant = only the address changes.",
      +  "enum": [
      +    "chatgpt",
      +    "claude",
      +    "claude-code"
      +  ],
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / properties / reason / description
      Previous value: -"Why — shown to the placer on the item (max 200 characters)."New value: +"Why, one line (max 200 characters). Required when handing it back; shown to the requester."
    • changedInput schema / properties / to / description
      Previous value: -"Email of the active member to give it to. null = decline (the assignee hands it back to the person who placed it) or clear the assignee (placer)."New value: +"Email of the ACTIVE member (or yourself) who should do it — chooses the first assignee, changes it, or chooses again after a decline. null = you, the current assignee, hand it back to the requester (decline while it is still only sent to you, hand back once accepted; needs `reason`)."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the destructiveHint annotation by disclosing the side effects: the person removed is notified, the requester is notified on a hand-back, and the reason is shown to the requester. It also documents the notification/permission model and the active-member constraint, which are not derivable from annotations or schema.

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?

Front-loads the core action and the Slack disambiguation, and every sentence carries rule information. It is dense with nested parentheticals ('for a decision / open question / note: its placer') that slow parsing, but nothing is genuinely redundant.

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

Completeness5/5

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

For a mutation tool with no output schema and a non-obvious permission/notification model, the description covers who may act, when, what side effects fire, and how handing back works. Nothing an agent needs to call it correctly is missing.

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 baseline is 3; the description adds real value by tying `to: null` to the decline/hand-back flow with a required `reason`, and by giving a composite example for `assignee_agent` (your email + 'chatgpt'). It stops short of covering all parameter interactions, but the semantics are clearer than the schema alone.

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?

States a specific verb and resource ('Change who is responsible for an item in an AccountHub shared project') and explicitly disambiguates from the Slack-workspace siblings that dominate the tool list ('NOT a Slack workspace'). An agent can distinguish it from update_shared_item, complete_shared_item, and withdraw_shared_item without opening a schema.

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?

Gives an explicit authorization model: anyone may set the first assignee and becomes requester, after which only the requester may change it or re-choose after a decline. It names the alternative path explicitly ('use respond_to_shared_item to accept') and states a hard precondition (the target must be an active member, not a pending invite).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources