Skip to main content
Glama

invite_user

Destructive
Invite someone to your Marcora account by email. An invitation email is sent automatically, and the response also returns the exact invite link (invite_link) so you can share it directly — e.g. paste it to the person in Slack.

Roles:
- "creator" — a full team member who can create and edit content.
- "admin" — a team administrator.
- "collaborator" — a project-scoped collaborator who only works inside a specific project.

Who can invite whom:
- You must be an ADMIN to invite someone as an "admin" or a "creator". Admins can invite any role.
- A "creator" can invite "collaborator"s only.
- Viewers cannot invite anyone.

project_id (a project UUID from list_projects):
- REQUIRED when role is "collaborator" — it is the project they will collaborate on.
- OPTIONAL for "creator" and "admin". It does NOT limit their access (creators and admins keep full team access); it simply also adds them to that project and makes their invite link drop them straight into it on first sign-in.

The invitee is emailed automatically: brand-new users get a sign-up link (returned in invite_link); existing users who still belong to an active team get a login link and will see the invitation in-app after they log in; existing users with no active team (e.g. a removed teammate) get a sign-up link to rejoin with their existing password. The call fails if the email is already an active team member (with no project to add them to), already has a pending invitation, or if you lack permission for the requested role.

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>",
      "role": "<role>"
    },
    "name": "invite_user"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleYesRole to grant: admin, creator, or collaborator
emailYesEmail address of the person to invite
project_idNoProject UUID (from list_projects). Required for collaborator; for creator/admin, optionally also adds them to this project and deep-links their invite to it.

Output Schema

NameRequiredDescriptionDefault
roleYesadmin | creator | collaborator
emailYes
emailedYesTrue when an invitation email was sent to the invitee
messageYesHuman-readable summary of what happened
outcomeYesinvited = an invitation email was sent; added_to_project = the email was already a team member and was added straight to the project
project_idNoProject the invitee was added to / pointed at, if any
invite_linkNoThe exact link to share directly. For new users this is the sign-up link (with the project deep-link when a project was given); for existing users it is the login URL. Null when no invitation was sent (added_to_project).
invite_tokenNoInvitation token, when an invitation was sent
existing_userNoTrue if the email already had a Marcora account (login link) vs a new sign-up link
invitation_idNoID of the created/reused team_invitation, when an invitation was sent

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say destructive/non-idempotent/open-world; the description adds far more: an email is dispatched automatically, the invite_link is returned for out-of-band sharing, and the invitee's experience differs by state (new user sign-up link, existing team member login link plus in-app notice, lapsed user re-sign-up link). It also enumerates the failure cases, which annotations cannot convey.

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?

The lead sentence is front-loaded with the action and the two outcomes, and the labeled sections (Roles, Who can invite whom, project_id) make it scannable. There is mild redundancy — the automatic email and the invite_link are each mentioned twice — and the invitee-state paragraph is long for a three-parameter tool, but nearly every sentence carries decision-relevant information.

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?

Given an output schema exists and annotations already flag the mutation profile, the remaining gaps an agent would face are permissions, conditional parameter requirements, and failure modes — all of which are covered. Nothing needed to call this tool 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 semantics are already partly documented, but the description adds real value by defining what each enum value means organizationally (creator = full team member, collaborator = project-scoped only) and by clarifying that project_id does NOT restrict creator/admin access, only deep-links the invite. It points to list_projects as the source of project_id, which the schema only implies.

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 opens with a concrete verb+resource pair: 'Invite someone to your Marcora account by email,' and immediately states the side effect (email sent, invite_link returned). No sibling tool performs invitations, so the agent can identify this tool unambiguously while reading the sibling list.

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?

It gives an explicit permission matrix for who may invite whom (admin invites any role, creator only collaborators, viewers none) plus the conditions that make the call fail (already an active member, already pending, insufficient permission). The project_id requirement is spelled out as conditional on role rather than left to inference.

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