Skip to main content
Glama

Invite someone

invite_member

Add someone to the account by email. They appear in the team list immediately with status invited, and become active the first time they sign in with that address. Ask for their name — without it the team list shows an address where a person should be.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNomember reads; admin also creates, renames and deletes MCPs and manages the team; owner also deletes the account.member
emailYesWhere the invitation goes, and the handle they are matched on when they first sign in. Re-inviting someone still waiting refreshes their invite; re-inviting someone already here is refused.
full_nameNoAsk for it. Without a name the team list shows an address where a person should be, until they sign in and fill in their own profile.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesThe membership row's id, not the user's — an invited person has no user yet.
roleYes`member` reads; `admin` also creates, renames and deletes MCPs and manages the team; `owner` also deletes the account.
emailYes
statusYes`invited` means asked but not yet signed in. Not a separate kind of thing — the same row in the same table.
user_idYesNull until they first sign in.
full_nameYes
joined_atYes
invited_atYes
last_sign_in_atYes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The description goes beyond the annotations by explaining immediate effects (status becomes 'invited'), future effects (becomes 'active' on first sign-in), and edge cases (re-inviting a pending invite refreshes it, re-inviting an active member is refused). This gives the agent valuable expectations for side effects and failure modes, while the annotations already note it is not read-only or destructive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose, then covers status transitions and the important name requirement in just a few sentences. Every sentence earns its place, and it avoids unnecessary detail.

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?

The description, combined with the rich schema and annotations, covers the purpose, parameter semantics, side effects, and edge cases. With no unresolved ambiguity, the agent has everything needed to invoke the tool correctly and predict its consequences.

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 schema already documents all parameters. The description adds meaningful guidance for 'full_name' by explaining why it matters (otherwise the team list shows an address) and for 'email' by explaining re-invite behavior. This enriches the semantics beyond the raw schema.

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 clearly states the action ('Add someone to the account by email'), the resource, and the result, distinguishing it from sibling tools like remove_member and change_member_role. It also explains the invited vs active status, which clarifies exactly what the tool does.

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?

The description explains when to use the tool (to invite a new user by email) and implies the alternative context, e.g. changing an existing member's role would use change_member_role. It doesn't explicitly mention when not to use it or name alternatives, but the context is clear enough.

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