Dexcom Share MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DEXCOM_REGION | No | Region for Dexcom server: 'us' for US, 'ous' for outside US | us |
| DEXCOM_PASSWORD | Yes | Your Dexcom account password | |
| DEXCOM_USERNAME | Yes | Your Dexcom account username |
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_glucose_readingsA | Get recent glucose values within the last 24 hours. IMPORTANT: This uses the unofficial Share API which only provides real-time monitoring data. Both startDate and endDate MUST be within the last 24 hours from the current time. Cannot retrieve historical data beyond 24 hours. |
| get_latest_readingA | Get the most recent glucose reading (typically from the last 5-15 minutes). This is the fastest way to check current glucose levels. |
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 a set of recent readings over a time window, while the other returns only the single most recent reading. There is no ambiguity about which to use for a given scenario.
Both tool names use a consistent 'get_adjective_noun' pattern (get_glucose_readings and get_latest_reading), making the naming predictable and easy to understand.
With only two tools, the surface feels thin for a glucose monitoring server, but it covers the essential use cases of retrieving current and recent data. The count is reasonable for a focused utility, though it leaves little room for additional functionality.
The server covers the primary use case of retrieving real-time glucose data. However, it lacks tools for historical retrieval (beyond 24 hours), setting alerts, managing device status, or user authentication, which are common interactions for a Dexcom integration.