Fulcra MCP Server

Record Data

record_data

Store one data record for a chosen data type with value, tags, notes, and optional time range; use it to log measurements or events for later retrieval.

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.

Input Schema

TableJSON 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.
`start_time`	No	When the record occurred; defaults to now. Must include tz. ISO8601. Duration-style types require it.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Oct 7, 2026

TDQS

A3.8/5.0

Behavior3/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 behavioral burden. It usefully discloses the user-defined ID form ('<BaseType>/<uuid>') and the read-back path, but says nothing about failure modes, whether re-recording overwrites, or permission requirements.

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?

Three short sentences, front-loaded with the core action and then the prerequisite/read-back routing. Tight overall, with only mild redundancy in 'record a record'.

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?

With an output schema present, return values need not be explained, and the description covers the key prerequisite flow and ID conventions. It is nearly complete for a 7-parameter mutation tool, missing only edge-case behavior.

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 goes beyond it by explaining the '<BaseType>/<uuid>' ID form that the schema's data_type description omits, which is real added meaning for the required parameter.

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+resource ('Record a single record') and implicitly contrasts with the read-side sibling get_records mentioned later. The phrasing 'record a record for a recordable data type' is slightly circular, but an agent can still tell this is the write-side counterpart to get_records.

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?

Explicitly routes the agent: use get_data_catalog to find data types, create_data_type to make new ones, get_records to read data back. It gives clear context for the prerequisite lookup step, though it never states when NOT to use this tool.

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