Skip to main content
Glama
Sign In
fulcradynamics

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Records

get_records
Read-only

Retrieve raw records for any catalog data type within a date range, or fetch a single v1 record without dates. Automatically selects the correct API endpoint, including user-defined types.

Instructions

Retrieve raw records in a range, or the latest v1 record without dates.

Set latest=true and omit both dates for a single latest v1 record.

Works with every type listed by get_data_catalog, including user-defined ones ("/" IDs); the correct API endpoint is chosen automatically. Records that cover a time range are included when any part of it intersects the requested window. Results are raw samples — they may come from multiple sources and can overlap; for calculated per-interval values of numeric data types, prefer get_time_series. Result timestamps include time zones; translate them to the user's local time zone when known.

Input Schema

NameRequiredDescriptionDefault
latestNoReturn one latest v1 record without a date range.
end_timeNoRange end (exclusive). Must include tz (ISO8601).
data_typeYesThe data type ID, as returned by `get_data_catalog`.
start_timeNoRange start (inclusive). Must include tz (ISO8601).
fulcra_useridNoRetrieve data for another Fulcra user (if shared); a shared type's get_data_catalog entry carries its owner's ID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.18.7
    • removedInput schema / properties / fulcra_userid / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
    • removedInput schema / properties / fulcra_userid / default
      Removed value: -null
    • addedInput schema / properties / fulcra_userid / type
      Added value: +"string"
    • addedInput schema / properties / latest
      Added value: +{
+  "default": false,
+  "description": "Return one latest v1 record without a date range.",
+  "type": "boolean"
+}
    • changedInput schema / required
      Previous value: -[
-  "data_type",
-  "start_time",
-  "end_time"
-]New value: +[
+  "data_type"
+]
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "type": "object",
-  "x-fastmcp-wrap-result": true
-}New value: +null
  2. Addedv1.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the readOnly/non-destructive annotations, it discloses that the API endpoint is chosen automatically per type, that overlap/intersection semantics apply to range-covering records, that results are raw samples possibly drawn from multiple sources and may overlap, and that timestamps carry time zones needing conversion. That is exactly the kind of behavior an agent cannot infer from annotations.

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 core behavior and the latest-mode rule are front-loaded in the first two sentences, with nuance (overlap, raw vs. calculated, timezone) following. No sentence is filler; each carries an operational constraint the agent would otherwise get wrong.

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?

There is no output schema, so the description carries return-value semantics itself — raw sample shape, possible multi-source overlap, and tz-bearing timestamps — and it does so. Combined with a fully documented input schema and read-only annotations, nothing needed to invoke this correctly is missing.

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 further by explaining the interaction between latest=true and omitting both dates, and by noting data_type accepts user-defined '<BaseType>/<uuid>' IDs — detail the schema only alludes to. It does not restate start/end exclusivity or the timezone format requirement, so it stops short of a 5.

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 ('retrieve raw records') plus two distinct modes (date range vs. latest-only), and explicitly contrasts itself with get_time_series for calculated values. An agent can distinguish it from get_time_series and get_data_updates without opening a 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?

Gives explicit when-to-use rules: 'Set latest=true and omit both dates for a single latest v1 record' and 'for calculated per-interval values of numeric data types, prefer get_time_series'. It also names get_data_catalog as the prerequisite for the data_type value, so the call ordering is unambiguous.

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

Deploy Server

Other Tools