mcp-freestyle
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LIBRELINKUP_EMAIL | Yes | Your LibreLinkUp follower account email (not the primary LibreLink one). | |
| LIBRELINKUP_PRODUCT | No | Product identifier for the LibreLinkUp client. | llu.android |
| LIBRELINKUP_VERSION | No | Pinned client version. Upstream rejects stale values — if requests start failing, set this to the current LibreLinkUp app version. | 4.16.0 |
| LIBRELINKUP_BASE_URL | No | Entry point URL for the LibreLinkUp API; the regional host is discovered at login. | https://api.libreview.io |
| LIBRELINKUP_PASSWORD | No | Password for the LibreLinkUp follower account. Overrides the OS keychain. For CI or one-off runs. | keychain |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_current_glucoseA | Read the most recent glucose measurement from the FreeStyle sensor, with the instant it was actually measured. The value is the latest one upstream holds, not a live reading — always report |
| get_glucose_historyA | Glucose readings over the last N hours (max 12), with time-in-range computed against the account's own target band. Upstream holds only about 12 hours of detailed data and ignores any longer request, so the response always states the range it actually covered and sets |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The two tools have clearly distinct purposes: one returns the most recent glucose reading, while the other returns a historical series over a requested time range. There is no overlap or ambiguity between them.
Both tool names follow the same 'get_' prefix followed by a descriptive noun (current_glucose, glucose_history). The naming pattern is consistent and predictable.
With only two tools, the server feels thin, but the domain is narrow (reading glucose data from a sensor). The two tools cover the essential operations, making the count borderline but not unreasonable.
The server provides access to both current and historical glucose data, which covers the core read-only functionality for the domain. Minor gaps exist (e.g., no health/sensor status), but the available tools are sufficient for the stated purpose.