Fulcra MCP Server

Create Group

create_group

Create a Fulcra user group for sharing data with multiple people at once. Optionally set data types members share read-only within a time range.

Instructions

Create a group of Fulcra users, e.g. to share with several people at once.

Without data_types joining shares nothing; members just use the group as a target for create_share. With data_types, every member shares those types (within the time range) read-only with the user until they leave; this cannot be changed later. Creating does not make the user a member: call join_group too, or shares made to the group never reach them. Anyone who learns the ID can join and the owner cannot remove members, so treat it like a password. Only create a group the user asked for.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	Yes	Group title shown to prospective members.
`time_end`	No	End of the shared-data range. Must include tz (ISO8601).
`data_types`	No	Data type IDs members will share (see `get_data_catalog`). Omit for a group that collects nothing.
`time_start`	No	Start of the shared-data range. Must include tz (ISO8601).
`description`	Yes	What the group is for.
`friendly_id`	No	Human-friendly ID (lowercase letters, digits, "-", "_").
`responsible_entity`	Yes	Person or organization responsible for the group.

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.8/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 most of the burden and delivers: sharing configured via `data_types` 'cannot be changed later', creating does not make the user a member, and the group ID is secret-like because anyone who learns it can join and the owner cannot remove members. That is security- and irreversibility-relevant behavior an agent needs before invoking.

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-loaded with purpose, then consequence of each mode. Six sentences for a tool with security implications is defensible, though the second paragraph is dense and could be tightened slightly without losing content.

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 two operating modes, the membership gap requiring join_group, immutability, and the security caveat — everything an agent needs to call and sequence this correctly.

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 baseline is 3, but the description adds genuine semantics: `data_types` triggers per-member read-only sharing bounded by the time range and is immutable afterward, and omitting it produces a group that 'collects nothing'. This goes beyond the schema's terse 'Data type IDs members will share'.

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+resource ('Create a group of Fulcra users') plus the motivating use case (sharing with several people at once), which distinguishes it from create_share and join_group in the sibling list. An agent can pick this tool 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 branches on the `data_types` parameter (omit → inert target for create_share; include → irrevocable read-only sharing), and names the follow-up action (`join_group`) required for shares to reach members. It even gives a when-not constraint: 'Only create a group the user asked for.'

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