Skip to main content
Glama
tribeunal

Tribeunal Decision-Making Platform

Official

Invite jurors

tribeunal_invite_jurors

Invite users to a case jury by username or email, or invite a whole tribe. Each invitee is notified and seated automatically when they open the case page; results report invited, duplicate, not found, or self.

Instructions

Invite users to the jury of a case you own or administer, on any jury type. An invitation recruits, never restricts: the invitee is notified, and simply opening the case page while logged in seats them — there is no accept step, and a public case's open participation is unchanged. Pass invitees and/or tribeId; at least one is required. Each invitee is processed independently — the response reports invited / duplicate / not_found / self per entry. An invitee seats themselves with tribeunal_join_jury; either of you can later free the seat with tribeunal_leave_jury. To add someone to the tribe itself rather than to this jury, use tribeunal_invite_tribe_members. Returns {case: {url, shareUrl}, results[], summary} — share a private case by its shareUrl, never the bare url.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
caseIdYesCase UUID (from tribeunal_get_case or tribeunal_search_cases) — must be a case you own or administer.
tribeIdNoTribe UUID (from tribeunal_list_tribes or tribeunal_get_tribe) to invite every current member plus the chieftain. You must belong to, own, or administer the tribe.
inviteesNo1–50 usernames or email addresses to invite. Optional if tribeId is given; at least one of the two is required. An AI persona's username may be invited to pick a specific one; AI jurors are otherwise seated automatically up to the case's AI juror limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv2.0.0
    • changedInput schema / properties / caseId / description
      Previous value: -"Case UUID (owner or admin only)"New value: +"Case UUID (from tribeunal_get_case or tribeunal_search_cases) — must be a case you own or administer."
    • changedInput schema / properties / invitees / description
      Previous value: -"Usernames or email addresses to invite (1-50). Optional if tribeId is given."New value: +"1–50 usernames or email addresses to invite. Optional if tribeId is given; at least one of the two is required. An AI persona's username may be invited to pick a specific one; AI jurors are otherwise seated automatically up to the case's AI juror limit."
    • changedInput schema / properties / tribeId / description
      Previous value: -"Optional tribe UUID: invite every current member plus the chieftain. You must be a member, owner or admin of the tribe."New value: +"Tribe UUID (from tribeunal_list_tribes or tribeunal_get_tribe) to invite every current member plus the chieftain. You must belong to, own, or administer the tribe."
  2. First observedv1.13.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only indicate a mutation (readOnlyHint false) and non-idempotency, but the description adds substantial detail: the recruit-not-restrict semantics, automatic seating on page open, independent per-entry processing with result types (invited/duplicate/not_found/self), and a security note about sharing shareUrl for private cases. This goes well beyond the minimal annotation flags and gives the agent a full picture of the tool's behavior.

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 front-loaded with purpose, then behavior, then parameters, then alternatives, then output. Every sentence conveys distinct, necessary information—no filler. It is dense yet efficient, and the structure guides the agent logically from what the tool does to how to use it correctly.

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 the lack of an output schema, the description thoughtfully provides the return shape ({case: {url, shareUrl}, results[], summary}) and a security caveat. It also covers parameter constraints, per-entry result semantics, and clear alternatives, making it complete for an agent to invoke correctly without additional documentation.

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% (baseline 3), but the description adds extra meaning beyond the schema. It clarifies that tribeId invites all current members plus the chieftain, explains that invitees can be usernames or email addresses (the schema only says strings), and specifies the AI persona behavior. This raises the score above baseline, though the schema already does heavy lifting.

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 precise verb and resource: 'Invite users to the jury of a case you own or administer, on any jury type.' It immediately distinguishes itself from the sibling tribeunal_invite_tribe_members by stating 'To add someone to the tribe itself rather than to this jury, use tribeunal_invite_tribe_members.' The purpose is unambiguous and easily separated from related tools.

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?

Provides explicit when-to-use and when-not-to-use guidance. It names the alternative tool for tribe invitations, clarifies the no-accept-step behavior, explains the relationship with join/leave jury tools, and states the requirement that at least one of invitees or tribeId must be provided. No inference is left to the agent.

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