Fulcra MCP Server

Join Group

join_group

Join a Fulcra group at the user's explicit request, after showing details, to receive shares and optionally share listed read-only data types until leaving.

Instructions

Join a Fulcra group on the user's behalf, at their explicit request.

Members can receive shares made to the group. If the group lists data types (see get_groups), joining also shares those read-only with its owner until the user leaves (see leave_group). Show the user the group's details first. Anyone who knows a group's ID can join it.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`group_id`	Yes	The group to join, from `get_groups`.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Oct 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare destructiveHint=false, so the description carries the burden and delivers: joining may share the group's listed data types read-only until the user leaves, and anyone with the group ID can join. These side-effect and access-control disclosures are material and not found in the annotation.

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 key constraint (explicit user request) is front-loaded, and subsequent sentences each add distinct, necessary information: sharing side effects, prerequisite to show details, and the open-join warning. No filler.

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?

An output schema exists, so return values need not be explained. The description covers the consent prerequisite, side effects, parameter source, and a security caveat, leaving no critical gap for correct invocation.

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

Parameters3/5

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

Schema description coverage is 100% and the single `group_id` parameter is already documented as coming from `get_groups`. The description reinforces this but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 ('Join a Fulcra group') and immediately distinguishes it from related siblings like `get_groups` (source of IDs) and `leave_group` (the inverse operation). An agent can identify the tool's role 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 requires the action be 'at their explicit request' and directs the agent to 'Show the user the group's details first,' making the consent and prerequisite conditions clear. It also names `get_groups` as the source for the required ID.

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