Skip to main content
Glama

place_shared_item

Put a to-do, decision, open question or note into an AccountHub shared project (shared project) so every member and their AI can see it — NOT a Slack workspace. For a plain chat message to a person or group in AccountHub chat (「〇〇さんにチャットで送って」) use send_chat_message instead — it finds the chat by name. You own what you place (only you can edit it; you or whoever chooses its assignee can withdraw it). A note is shown as a chat message in the chat, so its text can be fixed only for 15 minutes after placing it, and then shows as edited (its due date stays editable). Naming an assignee (works for every kind) makes you the requester: a to-do arrives at them as a request they accept or decline; a decision / open question / note is simply assigned. Add assignee_agent to address one of their assistants — to hand work to your own ChatGPT, use your own email + 'chatgpt'. Any active member can place items, including for each other. Everything you write is visible to all members: place only text the user wants shared, never private mail/Slack content you were not asked to pass on. Returns the item and assignee_resolution ('none' | 'self' | 'member' | 'unresolved'). Not idempotent: a retry places a second copy.

Input Schema

NameRequiredDescriptionDefault
bodyNoDetails. Everything here is visible to every member — never paste private mail or Slack text you were not asked to share.
kindYes'todo' (something to do), 'decision' (already decided — stored as done), 'open_question', or 'insight' (a note).
titleYesOne line saying what to do or what was decided, written for the assignee.
assigneeNoEmail of the member who should do it. Your own email assigns it to you. If it matches no active member the item is placed unassigned and `assignee_resolution` says 'unresolved'.
due_dateNoDeadline, YYYY-MM-DD.
project_idYesThe shared project to put the item in (from list_shared_projects).
assignee_agentNoTo address a person's specific assistant, e.g. your own ChatGPT: 'chatgpt', 'claude' (claude.ai) or 'claude-code'. Needs `assignee`. Omit = all of the assignee's assistants. Only that assistant is notified.
reply_to_item_idNoReply to a visible item in this same project. The original item is quoted when available.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / reply_to_item_id
      Added value: +{
      +  "description": "Reply to a visible item in this same project. The original item is quoted when available.",
      +  "format": "uuid",
      +  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • addedInput schema / properties / assignee_agent
      Added value: +{
      +  "description": "To address a person's specific assistant, e.g. your own ChatGPT: 'chatgpt', 'claude' (claude.ai) or 'claude-code'. Needs `assignee`. Omit = all of the assignee's assistants. Only that assistant is notified.",
      +  "enum": [
      +    "chatgpt",
      +    "claude",
      +    "claude-code"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only supply destructiveHint=false, so the description carries the load and does: ownership and edit rights, withdrawal rights, the 15-minute text-edit window for notes versus permanently editable due dates, requester/accept-decline semantics for assignees, and an explicit non-idempotency warning ('a retry places a second copy'). It even declares the return field assignee_resolution and its value set, despite there being no output 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-loaded with purpose and the Slack exclusion before the details, and nearly every sentence carries operational information. It is dense and clause-heavy, and the privacy admonition ('Everything you write is visible to all members...') largely repeats the body parameter's schema description, costing a little tightness.

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?

Eight parameters with several subtle behaviors (agent targeting, assignee resolution, reply quoting) are all covered, and the return contract is stated even though no output schema exists. Nothing an agent needs to call this correctly — preconditions, side effects, retry hazard, visibility — 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, but the description adds real semantics the schema does not: naming an assignee makes the caller the requester, and assignee_agent should be paired with the caller's own email + 'chatgpt' to target their own assistant. The assignee_resolution outcome values are also explained behaviorally rather than just structurally.

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 — 'Put a to-do, decision, open question or note into an AccountHub shared project' — and enumerates the four item kinds, which map directly to the kind enum. It also draws a hard boundary against Slack ('NOT a Slack workspace'), so an agent can distinguish this from messaging and workspace tools without reading the 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?

Names the alternative explicitly (send_chat_message, with the user phrasing 「〇〇さんにチャットで送って」) and the condition that selects it, plus the inverse exclusion ('NOT a Slack workspace'). It also grants broad permission scope ('Any active member can place items, including for each other'), so the agent knows preconditions are lax.

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