Fulcra MCP Server

Record Data

record_data

Log a single entry for a chosen data type, storing its value, fields, tags, and note so the record can be read back later.

Instructions

Record a single record for a recordable data type.

Use get_data_catalog to find data types; user-defined ones use the "/" ID form (create new ones with create_data_type). Recorded data can be read back with get_records. For v1 types (including user-defined Event and Metric types), the response gives the new record's id, which get_records returns as the record's id and delete_records takes.

Input Schema

Name	Required	Description
`note`	No	Free-text note stored with the record.
`tags`	No	Tag names to attach; missing tags are created automatically.
`value`	No	The value to record, for types that take one. E.g. "75.5" for numeric, "true" for boolean, "3" for scale.
`fields`	No	Values for the data type's own fields, e.g. {"mood": "calm", "energy": 7}. get_data_catalog with data_type set lists a user-defined type's fields.
`end_time`	No	When the recorded range ended. Must include tz (ISO8601). Only for duration-style types, where it is required.
`data_type`	Yes	The ID of the data type to record to.
`record_id`	No	v1 types only. The id (a UUID) to give the record. Leave it out and one is generated. To retry a send whose outcome is unknown, pass the id from the first attempt: a record sent again with the same id is stored as the same record, not a second one.
`start_time`	No	When the record occurred; defaults to now. Must include tz. ISO8601. Duration-style types require it.

Schema Changelog

Changes observed during successful MCP inspections.

Changed26 schema fields changedv1.18.7Oct 23, 2026

removedInput schema / properties / end_time / anyOf

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

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

removedInput schema / properties / fields / anyOf

Removed value: -[
-  {
-    "additionalProperties": true,
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / fields / default
```
Removed value: -null
```
addedInput schema / properties / fields / type
```
Added value: +"object"
```

removedInput schema / properties / note / anyOf

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

removedInput schema / properties / note / default
```
Removed value: -null
```
addedInput schema / properties / note / type
```
Added value: +"string"
```

removedInput schema / properties / record_id / anyOf

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

removedInput schema / properties / record_id / default
```
Removed value: -null
```
addedInput schema / properties / record_id / type
```
Added value: +"string"
```

removedInput schema / properties / start_time / anyOf

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

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

removedInput schema / properties / tags / anyOf

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

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

removedInput schema / properties / value / anyOf

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

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

changedOutput schema / (root)

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

Changed1 schema field changedv1.2.4Oct 14, 2026

addedInput schema / properties / record_id

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "v1 types only. The id (a UUID) to give the record. Leave it\nout and one is generated. To retry a send whose outcome is\nunknown, pass the id from the first attempt: a record sent again\nwith the same id is stored as the same record, not a second one."
+}

Addedv1.1.0Oct 7, 2026

TDQS

A4/5.0

Behavior4/5

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

With destructiveHint=false and readOnlyHint=false, the annotations already say this is a non-destructive write. The description adds genuine behavioral context beyond that: v1 types (including user-defined Event/Metric) return the new record's id, which get_records exposes as `id` and delete_records consumes. It does not mention auth or rate limits, but for a simple append-style write this is adequate.

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 the action, then the workflow routing, then return-value semantics. Four short sentences with no padding, though the opening line repeats the tool name awkwardly.

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?

No output schema exists, and the description fills that gap by explaining what comes back (the record id for v1 types) and how downstream tools use it. For an 8-parameter tool at full schema coverage, the only real omission is error/retry behavior, which the `record_id` schema field already handles.

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; the description earns above baseline by specifying the '<BaseType>/<uuid>' ID form for user-defined types, which the `data_type` schema field does not say. It does not add anything about note, tags, or start/end_time beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (record) and resource (a single record of a data type), which an agent can distinguish from read/write siblings like get_records or write_file. The phrasing 'record a single record for a recordable data type' is slightly circular but the scope (single record, write) is unmistakable.

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?

Routes the agent through the workflow explicitly: get_data_catalog to find types, create_data_type for new ones, get_records to read back, delete_records for the returned id. It gives no condition for when NOT to use it (e.g., bulk vs single, versus write_file), so the exclusions are implicit.

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

Deploy Server

Record Data

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools