Fulcra MCP Server

Create Share

create_share

Share files or data types read-only with other Fulcra users or groups, enabling agent-to-agent coordination via paired shared folders.

Instructions

Share files or data types from this account with other Fulcra users (read-only).

Recipients read them by passing this user's ID as fulcra_userid to the file and data tools; they can never write here. For agent-to-agent coordination, share a folder like "/shared//" and have the other user share one back; each agent writes to its own account and reads the other's. Only share what the user asked to share.

Input Schema

Name	Required	Description
`name`	Yes	A short label for the share, shown to recipients.
`time_end`	No	Only share data records before this time. Must include tz. ISO8601. Not allowed with file_paths.
`data_types`	No	Data type IDs to share (see `get_data_catalog`). Also accepts "calendars" and "calendar_events".
`file_paths`	No	Files or folders to share; a folder path must end with "/".
`time_start`	No	Only share data records from this time on. Must include tz. ISO8601. Not allowed with file_paths: file shares are never time-bounded.
`with_user_ids`	No	Fulcra user IDs to share with.
`share_all_data`	No	Share the entire account, only on explicit request. Excludes file_paths and data_types.
`with_group_ids`	No	Group IDs (from `get_groups`) to share with all members of.
`include_file_history`	No	Also share earlier versions of the files.

Schema Changelog

Changes observed during successful MCP inspections.

Changed25 schema fields changedv1.18.7Oct 23, 2026

removedInput schema / properties / data_types / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / data_types / default
```
Removed value: -null
```
addedInput schema / properties / data_types / items
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / data_types / type
```
Added value: +"array"
```

removedInput schema / properties / file_paths / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / file_paths / default
```
Removed value: -null
```
addedInput schema / properties / file_paths / items
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / file_paths / type
```
Added value: +"array"
```

removedInput schema / properties / time_end / anyOf

Removed value: -[
-  {
-    "format": "date-time",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / time_end / default
```
Removed value: -null
```
addedInput schema / properties / time_end / format
```
Added value: +"date-time"
```
addedInput schema / properties / time_end / type
```
Added value: +"string"
```

removedInput schema / properties / time_start / anyOf

Removed value: -[
-  {
-    "format": "date-time",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / time_start / default
```
Removed value: -null
```
addedInput schema / properties / time_start / format
```
Added value: +"date-time"
```
addedInput schema / properties / time_start / type
```
Added value: +"string"
```

removedInput schema / properties / with_group_ids / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / with_group_ids / default
```
Removed value: -null
```
addedInput schema / properties / with_group_ids / items
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / with_group_ids / type
```
Added value: +"array"
```

removedInput schema / properties / with_user_ids / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / with_user_ids / default
```
Removed value: -null
```
addedInput schema / properties / with_user_ids / items
```
Added value: +{
+  "type": "string"
+}
```
addedInput schema / properties / with_user_ids / type
```
Added value: +"array"
```

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null

Addedv1.1.0Oct 7, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, the description explains recipient behavior: recipients read by passing this user's ID as `fulcra_userid`, they can never write here, and each agent can write to its own account while reading the other's. This adds meaningful access-model context for a non-destructive but open-world mutation tool.

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 the core purpose and then adds only relevant operational context. Its four sentences are compact and each contributes to understanding scope, access, or safe use.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter mutation tool with rich schema coverage, the definition is mostly complete: it covers the access model, recipient semantics, and agent-to-agent workflow. It stops short of explaining share lifecycle or return behavior, and does not mention group shares or time-bounded shares, though the schema covers those details.

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%, so the schema already documents all nine parameters. The description adds a useful folder-path example for agent coordination, but it does not meaningfully explain most parameters such as time bounds, group IDs, or share_all_data beyond what the schema provides.

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 states a specific verb and resources: share files or data types from this account with other Fulcra users. It also states the access mode, read-only, making it easy to distinguish from siblings like list_shares and delete_share.

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?

It gives a clear usage pattern for agent-to-agent coordination, including sharing a reciprocal folder, and cautions to only share what the user asked to share. It does not explicitly name when to prefer create_agent_invitation or group-oriented alternatives, so it falls short of full when/when-not guidance.

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

Deploy Server

Create Share

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools