This server provides access to personal health, fitness, and location data from the Fulcra Context platform. Here's what you can do:
Get Workouts – Retrieve details about workouts completed during a specified time period.
Get Metrics Catalog – Browse all available time-series health/activity metrics.
Get Metric Time Series – Fetch time-series data for a specific metric (e.g., heart rate, steps) with options for sample rate, null handling, and calculations (max, min, delta, mean, etc.).
Get Metric Samples – Retrieve raw, unprocessed samples for a given metric over a time range.
Get Sleep Cycles – Retrieve summarized sleep cycle data derived from sleep stage samples, with configurable stage filtering and cycle gap thresholds.
Get Location at Time – Look up the user's geographic location at a specific point in time, with a configurable look-back window and optional reverse geocoding.
Get Location Time Series – Retrieve a time series of the user's locations over a period, with options for distance filtering and reverse geocoding.
Get User Info – Retrieve general user metadata such as time zone, calendar IDs, and other profile information.
Mentioned as a communication channel for support, but not explicitly identified as an integration target for the MCP server.
Provides access to GitHub through the Fulcra API, allowing interaction with GitHub repositories. The MCP server maintains OAuth2 authentication for secure GitHub access without exposing tokens to MCP clients.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Fulcra Context MCP show me my recent heart rate data"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This is an MCP server that provides tools and resources to call the Fulcra API using fulcra-api.
There is a public instance of this server running at https://mcp.fulcradynamics.com/mcp. See https://docs.fulcradynamics.com/ to get started quickly. This repo is primarily for users who need to run the server locally, want to see under the hood, or want to help contribute.
When run on its own (or when FULCRA_ENVIRONMENT is set to stdio), it acts as a local MCP server using the stdio transport. Otherwise, it acts as a remote server using the Streamble HTTP transport. It handles the OAuth2 callback, but doesn't leak the exchanged tokens to MCP clients. Instead, it maintains a mapping table and runs its own OAuth2 service between MCP clients.
There is a public instance of this server running at https://mcp.fulcradynamics.com/. Point your OAuth2-capable MCP clients at that.
Example Claude Desktop config using uvx:
{
"mcpServers": {
"fulcra_context": {
"command": "uvx",
"args": [
"fulcra-context-mcp@latest"
]
}
}
}Both the MCP Inspector and mcp-remote tools can be useful in debugging.
Every MCP client is different, but many abbreviate abbreviate tool and parameter descriptions for summaries. To avoid confusing client models, keep the initial descriptions short (full description in one line, around 80 characters).
While developing locally, the scripts/simulate_tools.py script simulates what this might look like to an MCP client:
FULCRA_ENVIRONMENT=stdio uv run python scripts/simulate_tools.py --command "uv run fulcra-context-mcp"Related MCP server: Oura MCP Server
Please feel free to reach out via the GitHub repo for this project or join our Discord to reach out directly. Email also works (support@fulcradynamics.com).
Gets the user's location at the given time.
If no sample is available for the exact time, searches for the closest one up to window_size seconds back.
Result timestamps will include time zones. Always translate timestamps to the user's local time zone when this is known.
Args: time: The point in time to get the user's location for. Must include tz (ISO8601). window_size: Optional. The size (in seconds) to look back (and optionally forward) for samples. Defaults to 14400. include_after: Optional. When true, a sample that occurs after the requested time may be returned if it is the closest one. Defaults to False. Returns: A JSON string representing the location data.
| Name | Required | Description | Default |
|---|---|---|---|
| time | Yes | ||
| window_size | No | ||
| reverse_geocode | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: searching for closest samples within a window, handling time zones, and returning JSON data. It doesn't cover aspects like error handling, rate limits, or authentication needs, but it provides sufficient operational context for basic use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, starting with the core purpose. Each sentence adds value: explaining sample search logic, time zone handling, and parameter/return details. There's no redundant or wasted text, making it efficient and easy to parse for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (time-based location querying) and lack of annotations, the description is mostly complete. It covers purpose, key behaviors, and most parameters, and an output schema exists, so return values don't need explanation. The main gap is the undocumented 'reverse_geocode' parameter, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for 'time' (must include tz in ISO8601), 'window_size' (seconds to look back, with default), and 'include_after' (optional behavior). However, it doesn't mention 'reverse_geocode' from the input schema, leaving one parameter undocumented. This partial coverage slightly reduces the score from a perfect 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets the user's location at the given time.' It specifies the verb ('Gets') and resource ('user's location'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_location_time_series' or 'get_metric_samples,' which could provide similar location-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning how the tool handles missing samples and time zone translation, but it doesn't explicitly state when to use this tool versus alternatives like 'get_location_time_series.' It provides some context on behavior (e.g., searching for closest samples) but lacks clear guidance on scenarios or prerequisites for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a time series of locations that the user was at. Result timestamps will include time zones. Always translate timestamps to the user's local tz when this is known.
Args: start_time: The start of the time range (inclusive), as an ISO 8601 string or datetime object. end_time: The end of the range (exclusive), as an ISO 8601 string or datetime object. change_meters: Optional. When specified, subsequent samples that are fewer than this many meters away will not be included. sample_rate: Optional. The length (in seconds) of each sample. Default is 900. reverse_geocode: Optional. When true, Fulcra will attempt to reverse geocode the locations and include the details in the results. Default is False. Returns: A JSON string representing a list of location data points.
| Name | Required | Description | Default |
|---|---|---|---|
| start_time | Yes | ||
| end_time | Yes | ||
| change_meters | No | ||
| sample_rate | No | ||
| reverse_geocode | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: result timestamps include time zones with translation guidance, and it explains optional filtering ('change_meters') and enhancement ('reverse_geocode'). However, it misses details like rate limits, error handling, or data freshness, which could be important for a location-tracking tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, args, returns) and uses bullet-like formatting for parameters. It's appropriately sized, but the first sentence could be more front-loaded with key details, and some phrasing (e.g., 'Always translate...') might be slightly verbose without adding critical info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no annotations, and an output schema, the description is mostly complete. It covers purpose, parameters, and return format adequately. However, it lacks context on permissions, data sources, or sibling tool differentiation, which could enhance usability given the server's other location/metric tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description compensates fully by providing detailed semantics for all 5 parameters. It explains each parameter's purpose, format (e.g., ISO 8601), optionality, defaults, and effects (e.g., 'reverse_geocode' adds details). This adds significant value beyond the bare schema, making parameters well-understood.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve a time series of locations that the user was at.' This specifies the verb ('retrieve') and resource ('time series of locations'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_location_at_time' or 'get_metric_time_series', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some implicit guidance by mentioning 'Always translate timestamps to the user's local tz when this is known,' suggesting usage when timezone-aware location data is needed. However, it lacks explicit when-to-use instructions, alternatives (e.g., vs. 'get_location_at_time'), or exclusions, leaving gaps in practical application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the raw samples related to a given metric for the user during a specified period.
In cases where samples cover ranges and not points in time, a sample will be returned if any part of its range intersects with the requested range. For example, if start_time is 14:00 and end_time is 15:00, a sample covering 13:30-14:30 will be included. Result timestamps will include time zones. Always translate timestamps to the user's local time zone when this is known.
Args:
metric_name: The name of the metric to retrieve samples for. Use get_metrics_catalog to find available metrics.
start_time: The start of the time range (inclusive), as an ISO 8601 string or datetime object.
end_time: The end of the time range (exclusive), as an ISO 8601 string or datetime object.
Returns:
A JSON string representing a list of raw samples for the metric.
| Name | Required | Description | Default |
|---|---|---|---|
| metric_name | Yes | ||
| start_time | Yes | ||
| end_time | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job disclosing key behavioral traits: it explains the range intersection logic for samples covering time ranges, specifies that result timestamps include time zones, and instructs to translate to user's local time zone when known. It also clarifies the inclusive/exclusive nature of the time boundaries. The only minor gap is lack of information about pagination, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and appropriately sized. It begins with a clear purpose statement, follows with important behavioral details, then provides organized parameter documentation in an Args/Returns format. Every sentence earns its place by adding essential information, with no redundant or verbose content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (time-based querying with specific behavioral rules), no annotations, and the presence of an output schema (which handles return value documentation), the description is remarkably complete. It covers purpose, usage context, detailed parameter semantics, and important behavioral characteristics like range intersection logic and time zone handling. The output schema will document the return structure, so the description appropriately focuses on operational aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics in the Args section. It explains what metric_name represents and references get_metrics_catalog for finding available metrics. It clarifies the format requirements for start_time and end_time (ISO 8601 or datetime object) and specifies their inclusive/exclusive behavior. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('retrieve raw samples'), target resource ('a given metric'), and scope ('for the user during a specified period'). It distinguishes from siblings like get_metric_time_series (which likely returns aggregated/processed data rather than raw samples) and get_metrics_catalog (which lists available metrics rather than retrieving samples).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (retrieving raw samples for a specific metric within a time range) and explicitly references get_metrics_catalog as a prerequisite for finding available metric names. However, it doesn't explicitly state when NOT to use it or compare alternatives like get_metric_time_series, which would be helpful for sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the catalog of available metrics that can be used in time-series API calls
(metric_time_series and metric_samples).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Get'), but doesn't specify whether authentication is required, rate limits, error conditions, or what format the catalog returns. While adequate for a simple catalog tool, it lacks details about behavioral traits beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently communicates the tool's purpose, resource, and usage context. Every word earns its place, with no wasted text or redundancy. It's front-loaded with the core purpose and provides necessary context in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists, the description is reasonably complete. It explains what the tool does and when to use it, though it could benefit from mentioning what the catalog contains (metric definitions, types, etc.) or how the output is structured. The existence of an output schema reduces the need to describe return values in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the baseline for no parameters is 4. The description appropriately doesn't discuss parameters since none exist, and instead focuses on the tool's purpose and usage context, which is the correct approach for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('catalog of available metrics'), and explicitly distinguishes it from sibling tools by mentioning which specific tools the metrics can be used with (metric_time_series and metric_samples). This provides clear differentiation from other siblings like get_location_time_series or get_workouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to get metrics that can be used in time-series API calls, and specifically names the two sibling tools (metric_time_series and metric_samples) where these metrics are applicable. This provides clear guidance on usage context and distinguishes it from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user's time-series data for a single Fulcra metric.
Covers the time starting at start_time (inclusive) until end_time (exclusive). Result timestamps will include tz. Always translate timestamps to the user's local tz when this is known.
Args:
metric_name: The name of the time-series metric to retrieve. Use get_metrics_catalog to find available metrics.
start_time: The starting time period (inclusive). Must include tz (ISO8601).
end_time: The ending time (exclusive). Must include tz (ISO8601).
sample_rate: Optional. The number of seconds per sample. Default is 60. Can be smaller than 1.
replace_nulls: Optional. When true, replace all NA with 0. Default is False.
calculations: Optional. A list of additional calculations to perform for each
time slice. Not supported on cumulative metrics. Options: "max", "min", "delta", "mean", "uniques", "allpoints", "rollingmean".
Returns:
A JSON string representing a list of data points for the metric.
For time ranges where data is missing, the values will be NA unless replace_nulls is true.
| Name | Required | Description | Default |
|---|---|---|---|
| metric_name | Yes | ||
| start_time | Yes | ||
| end_time | Yes | ||
| sample_rate | No | ||
| replace_nulls | No | ||
| calculations | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: time range handling (inclusive start, exclusive end), timezone translation behavior, data format (JSON string), missing data handling (NA values), and constraints ('Not supported on cumulative metrics'). It lacks rate limit or authentication details, but provides substantial operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear purpose statement, time range explanation, and organized parameter documentation. Every sentence adds value, though the parameter explanations could be slightly more concise. The structure is logical with purpose first, then behavior, then detailed args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, time-series data), no annotations, and the presence of an output schema, the description is remarkably complete. It covers purpose, usage guidance, parameter semantics, behavioral constraints, and return format. The output schema handles return value details, so the description appropriately focuses on operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed semantic explanations for all 6 parameters. It clarifies metric_name usage with sibling reference, explains time format requirements (ISO8601 with tz), provides defaults for optional parameters, enumerates calculations options, and explains parameter interactions (replace_nulls effect on NA values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Get user's time-series data'), resource ('for a single Fulcra metric'), and scope ('Covers the time starting at start_time...'). It distinguishes from siblings like 'get_metric_samples' and 'get_metrics_catalog' by focusing on time-series retrieval rather than catalog or sample-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (time-series data retrieval) and references 'get_metrics_catalog' to find available metrics. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like 'get_metric_samples' or 'get_location_time_series'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return sleep cycles summarized from sleep stages.
Processes raw sleep data samples into sleep cycles by finding gaps in the sleep sample data within a specified time interval. Result timestamps will include time zones. Always translate timestamps to the user's local time zone when this is known.
Args: start_time: The starting timestamp (inclusive), as an ISO 8601 string or datetime object. end_time: The ending timestamp (exclusive), as an ISO 8601 string or datetime object. cycle_gap: Optional. Minimum time interval separating distinct cycles (e.g., "PT2H" for 2 hours). Defaults to server-side default if not provided. stages: Optional. Sleep stages to include. Defaults to all stages if not provided. gap_stages: Optional. Sleep stages to consider as gaps in sleep cycles. Defaults to server-side default if not provided. clip_to_range: Optional. Whether to clip the data to the requested date range. Defaults to True. Returns: A JSON string representing a pandas DataFrame containing the sleep cycle data.
| Name | Required | Description | Default |
|---|---|---|---|
| start_time | Yes | ||
| end_time | Yes | ||
| cycle_gap | No | ||
| stages | No | ||
| gap_stages | No | ||
| clip_to_range | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: processing logic (finding gaps in sleep data), timestamp handling (includes time zones, translation guidance), and output format (JSON string representing pandas DataFrame). However, it doesn't mention performance characteristics, error conditions, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose statement, processing explanation, timestamp guidance, parameter documentation, and return format. The information is front-loaded and organized, though the parameter section is lengthy (necessary given 0% schema coverage). Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, processing logic) and the presence of an output schema, the description is quite complete. It explains the transformation logic, parameter semantics, and timestamp handling. The output schema handles return value details, so the description appropriately focuses on behavior and parameters. Minor gaps exist in error handling and performance context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation in the Args section. Each of the 6 parameters is clearly explained with purpose, format examples, defaults, and optionality. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return sleep cycles summarized from sleep stages' and explains the processing logic: 'Processes raw sleep data samples into sleep cycles by finding gaps in the sleep sample data within a specified time interval.' This is specific (verb+resource+processing method) and distinguishes it from sibling tools like get_metric_samples or get_workouts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage context through the processing explanation and timestamp handling guidance, but doesn't explicitly state when to use this tool versus alternatives. No sibling tool comparisons or explicit when-not-to-use guidance is provided, leaving usage decisions to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return general info about the Context by Fulcra user.
Returns user references such as time zone, calendar ids, and other metadata.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a read operation ('Return general info'), but doesn't mention authentication requirements, rate limits, error conditions, or whether the data is real-time vs cached. For a user info tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly address purpose and return values. The first sentence states the core function, and the second provides concrete examples. There's no wasted verbiage, though it could be slightly more structured by front-loading the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, 100% schema coverage, and an output schema exists, the description provides adequate basic information about what the tool returns. However, for a user info tool with no annotations, it should ideally mention authentication requirements or data freshness. The existence of an output schema means the description doesn't need to detail return format, but behavioral context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (schema coverage 100%), so there are no parameters to document. The description appropriately doesn't waste space discussing nonexistent parameters. A perfect 5 would require the description to explicitly state 'no parameters required' or similar, but 4 is appropriate given the empty parameter set.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Return general info about the Context by Fulcra user' with specific examples of what's returned ('user references such as time zone, calendar ids, and other metadata'). However, it doesn't explicitly differentiate this user info tool from sibling tools that return location, metrics, sleep, or workout data, which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, timing considerations, or comparison to sibling tools that return different types of user data. The agent must infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about the workouts that the user has done during a period of time. Result timestamps will include time zones. Always translate timestamps to the user's local time zone when this is known.
Args: start_time: The starting time of the period. Must include tz (ISO8601). end_time: the ending time of the period. Must include tz (ISO8601).
| Name | Required | Description | Default |
|---|---|---|---|
| start_time | Yes | ||
| end_time | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond the input schema: it specifies that 'Result timestamps will include time zones' and instructs to 'Always translate timestamps to the user's local time zone when this is known.' This clarifies output behavior and user-facing considerations, though it doesn't cover aspects like rate limits, authentication needs, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with the core purpose stated first, followed by behavioral notes and a dedicated 'Args:' section for parameters. Every sentence adds value: the first defines the tool, the second explains timestamp handling, and the parameter descriptions are essential given the schema gaps. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 required parameters, no annotations, but with an output schema), the description is largely complete. It covers purpose, behavioral traits (timestamp handling), and parameter semantics. Since an output schema exists, it doesn't need to explain return values. However, it could improve by addressing potential limitations (e.g., data availability) or sibling tool differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides significant semantic value beyond the input schema, which has 0% description coverage. It explicitly defines both parameters ('start_time' and 'end_time'), specifies they 'Must include tz (ISO8601)', and contextualizes them as 'The starting time of the period' and 'the ending time of the period.' This fully compensates for the schema's lack of descriptions, making the parameters clear and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get details about the workouts that the user has done during a period of time.' This specifies the verb ('Get details'), resource ('workouts'), and scope ('during a period of time'). However, it doesn't explicitly differentiate from sibling tools like 'get_metric_samples' or 'get_sleep_cycles', which might also retrieve user activity data, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'during a period of time' and providing time-based parameters, suggesting it's for retrieving historical workout data. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_metric_samples' or 'get_sleep_cycles', and doesn't mention prerequisites or exclusions (e.g., whether the user must have workouts logged).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
get_location_at_timeget_location_time_seriesget_metric_samplesget_metric_time_seriesget_metrics_catalogget_sleep_cyclesget_user_infoget_workoutsEvery tool has a clearly distinct purpose targeting specific data types or operations: location retrieval (get_location_at_time, get_location_time_series), metric data (get_metric_samples, get_metric_time_series), metadata (get_metrics_catalog, get_user_info), and specialized analyses (get_sleep_cycles, get_workouts). There is no functional overlap between tools, making selection unambiguous.
All eight tools follow a consistent 'get_*' verb_noun pattern with snake_case throughout. The naming convention is perfectly uniform, making the tool set predictable and easy to understand at a glance.
With 8 tools, this server is well-scoped for its purpose of retrieving user context data (location, metrics, sleep, workouts, and metadata). Each tool serves a distinct and necessary function without redundancy, making the count ideal for the domain.
The tool set provides comprehensive read-only coverage for retrieving user context data across multiple domains (location, metrics, sleep, workouts, and user info). A minor gap exists in the lack of update or delete operations, but this is reasonable for a context retrieval server focused on data access rather than modification.
Collect Apple Health data from your wearables through the Context app and query it via MCP
Private Apple Health metrics and workout detail for ChatGPT, Claude, and any MCP client.
Zero-setup MCP gateway securely connecting AI to your tools with authentication and workflows
Let AI agents query data and act across all your business apps via MCP.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/fulcradynamics/fulcra-context-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
