twelvebit Analytics

Invite someone to the site

invite_team_member

Destructive

Invite a person by email (owner only). viewer = read only; member = read and change the setup. They get an email with a link to the invite page, where they create an account or sign in with that address and join in one step. The result has invite_url, the same page for the user to share in another channel (it works only for that address). Invites expire after 14 days. Inviting an existing member changes only the role. Confirm the address with the user first. Pass idempotency_key so that a retry does not send a second email.

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": {
      "email": "<email>"
    },
    "name": "invite_team_member"
  }
}

Input Schema

Name	Required	Description	Default
`role`	No		viewer
`site`	No	Site domain (example.com), id or public id (tb_…). Optional with a site key, or when the account has one site.
`email`	Yes
`idempotency_key`	No	A fresh UUID for this create. Send the same value when you retry the same call: the first result comes back and nothing is created twice.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds rich behavior well beyond the annotations: an email is sent, the link works only for that address, invites expire after 14 days, and re-inviting an existing member mutates only the role. The idempotency_key advice is consistent with idempotentHint=false – it explains that the retry guarantee must be opted into rather than contradicting it.

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 action, role mapping, and access restriction; all six sentences carry operational information. The invite-page/link concept is explained twice (email flow, then invite_url), which is mild redundancy but arguably reinforcing.

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, and the description covers the return value (invite_url), delivery side effects, expiry, re-invite semantics, permission gate, and retry safety. An agent has everything needed to call it correctly and warn the user about what will happen.

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 50% schema coverage, the description compensates by defining 'viewer = read only; member = read and change the setup' (the enum has no schema description) and by explaining what idempotency_key does in operation. The 'site' parameter is left entirely to the schema description, which is the one remaining gap.

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 ('Invite a person by email') plus scope ('owner only') and spells out what each role actually grants. 'Inviting an existing member changes only the role' separates it from update_team_member without needing 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 Guidelines4/5

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

Gives a precondition ('Confirm the address with the user first'), an ownership restriction, idempotency guidance for retries, and a fallback channel via invite_url. It stops short of naming sibling alternatives (e.g. update_team_member vs re-invite) explicitly, so the agent must infer the routing.

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

All twelvebit Analytics 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?