Skip to main content
Glama
fulcradynamics

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Get Location

get_location
Read-only

Retrieve the user's location at a specific time or across a time range sampled at a set interval, optionally returning addresses. Use it to reconstruct where someone was during a moment or period.

Instructions

Get where the user was: at one moment (time), or over a range (start_time and end_time) as one location per sample_rate seconds.

Result timestamps include time zones. Always translate them to the user's local time zone when this is known.

Input Schema

NameRequiredDescriptionDefault
timeNoThe moment to locate the user at. Must include tz (ISO8601). Without a sample at that exact time, the closest one within window_size seconds before or after is used.
end_timeNoRange end (exclusive). Must include tz (ISO8601).
start_timeNoRange start (inclusive). Must include tz (ISO8601).
sample_rateNoRange only: seconds per sample (default 900).
window_sizeNoMoment only: seconds around `time` to search for a sample (default 14400).
change_metersNoRange only: drop samples fewer than this many meters from the previous one.
fulcra_useridNoRetrieve data for another Fulcra user (if shared).
include_afterNoMoment only: allow the closest sample to be after `time` (default true); false finds where the user last was at or before it.
reverse_geocodeNoInclude the address (default: true for a moment, false for a range).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.18.7

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare this as a safe read-only operation with no destructive behavior. The description adds useful behavioral context beyond annotations: result timestamps include time zones, and agents should translate them to the user's local time zone when known. It does not cover pagination or error behavior, but that is less critical for a read-only lookup 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, compact, and free of filler. Every sentence contributes either mode clarification or time-zone handling guidance.

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 nine parameters but complete schema descriptions and read-only annotations, the description is largely sufficient. It covers the moment/range distinction and timestamp time-zone handling, though without an output schema it could say a bit more about the returned location payload.

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 thoroughly. The description reinforces the meaning of `time`, `start_time`, `end_time`, and `sample_rate`, but adds little parameter-level detail beyond what the schema provides.

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?

The description states a specific verb and resource ("Get where the user was") and clearly distinguishes the two supported modes: a single moment versus a range. It does not explicitly contrast itself with neighboring retrieval tools such as get_time_series or get_records, so it stops short of full sibling differentiation.

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 clearly explains the two usage modes: use `time` for a moment and `start_time`/`end_time` for a range sampled every `sample_rate` seconds. It does not name alternatives or when-not conditions, but the mode selection context is explicit.

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