AccountHub

get_shared_project_join_link

Destructive

Get the join link of an AccountHub shared project (shared project) — NOT a Slack workspace. Unlike invite_to_shared_project it is not tied to an email address: anyone who opens it, signs in to AccountHub and agrees joins the project as themselves. One link per project: the same url on every call until it expires (expires_at, 14 days), then a new one is made. regenerate: true replaces it and the old link stops working at once (people who already joined stay). Nothing is sent: give the url yourself (e.g. through send_message). Any active member can call it; not available for a 1:1 chat.

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": {
      "project_id": "<project_id>"
    },
    "name": "get_shared_project_join_link"
  }
}

Input Schema

Name	Required	Description	Default
`project_id`	Yes	The shared project (from list_shared_projects).
`regenerate`	No	true = replace the link: the current link stops working at once and a new one is returned. Omit to get the current link (made on first use).

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 25, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Goes well beyond the single destructiveHint annotation: it discloses link lifecycle (one stable url until expires_at at 14 days), the exact effect of regenerate (old link dies at once, existing joiners unaffected), and that no notification is sent. That fully explains why destructiveHint=true on an otherwise read-like tool, so there is no contradiction.

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 the core action and the sibling/workspace disambiguation, and every clause carries operational information. It is dense in a single long paragraph; splitting lifecycle vs. delivery into separate sentences would read slightly better.

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?

No output schema exists, yet the description names the returned fields (`url`, `expires_at`) and their behavior, plus the mutation side effects of regenerate and the permission model. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds consequences the schema lacks: `regenerate: true` invalidates the current link immediately while preserving existing members, and the returned `url`/`expires_at` semantics. `project_id` provenance is also covered by the sibling list_shared_projects reference.

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 ("get the join link of an AccountHub shared project") and immediately disambiguates it from a Slack workspace and from the sibling invite_to_shared_project. An agent can select it against dozens of neighbors without opening 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?

Explicitly contrasts with invite_to_shared_project (not email-bound), states the delivery path ("Nothing is sent: give the `url` yourself, e.g. through send_message"), the permission condition ("any active member can call it"), and an exclusion ("not available for a 1:1 chat"). When-to-use and when-not-to-use are both covered.

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

All AccountHub tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?