nightscout-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools are mostly distinct, but 'glucose_history' and 'analyze' both support time ranges, which could cause misselection. However, descriptions clarify that one returns raw data and the other analyzes patterns.
Naming Consistency3/5
Tool names mix noun-based (glucose_current, treatments) and verb-based (analyze) conventions. There's no consistent verb_noun pattern, though names are still readable and predictable.
Tool Count5/5
7 tools is a well-scoped set for a Nightscout server, covering monitoring, analysis, and status without bloat.
Completeness4/5
The surface covers current glucose, history, analysis, treatments, devices, and status—core Nightscout interactions. Minor gaps like write operations or detailed alerts exist, but the read-only monitoring workflow is complete.
Average 3.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It implies a read operation via 'Get' but does not explicitly state read-only status, auth requirements, rate limits, or any side effects. No additional behavioral context is provided beyond the bare action.
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 a single, front-loaded sentence that conveys the essential purpose without any fluff. It is concise, readable, and appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description leaves significant gaps: it does not describe return format, sorting, pagination behavior, or error conditions. While the tool is simple, this level of completeness is insufficient for an agent to fully anticipate behavior.
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 coverage is 100% as both parameters (count, hours) have descriptions. The description does not add new parameter information; the mention of 'recent' aligns with the 'hours' parameter but adds no additional semantics beyond what the schema already clarifies.
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 clearly states the tool retrieves recent treatments with examples (insulin doses, carbs), which distinguishes it from sibling tools like glucose_history or analyze. It uses a specific verb ('Get') and resource ('treatments'), though it doesn't explicitly contrast with siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusions, prerequisites, or how it relates to glucose_current, glucose_history, or analyze tools. The usage context is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic function and lacks any mention of return format, pagination, limitations, or whether authentication is required. The read-only nature is inferable from 'get' but not explicitly disclosed.
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?
A single sentence that is front-loaded and contains no unnecessary words. It immediately conveys the core function and scope without filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no nested objects), the description is minimally adequate. It covers the basic purpose but omits details such as the format of returned readings or how count interacts with hours, which would improve completeness.
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?
The input schema already has descriptions for both parameters (count and hours) with ranges and defaults, achieving 100% coverage. The tool description adds minimal extra meaning beyond the schema, so a baseline of 3 is appropriate.
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 clearly states the action (Get) and the resource (blood glucose history) with a time-period scope. It is specific enough to distinguish from glucose_current, though it does not explicitly differentiate itself from sibling tools like analyze or analyze_monthly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used for retrieving historical glucose readings over a specified period, but it provides no explicit guidance on when to choose this instead of alternatives like glucose_current or analyze. No exclusions or usage scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. 'Get status' implies a read-only operation, but does not explicitly state it as safe or non-destructive. It also does not describe whether data is live or cached, or what specific device information is returned. The description is too minimal to provide meaningful transparency.
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 a single concise sentence that gets directly to the point. It is short, front-loaded with the action ('Get status'), and includes useful parenthetical detail. No unnecessary words or filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description is not sufficiently complete. It does not describe what 'status' contains (e.g., battery level, connection state) or what the return format looks like. For a tool with only one simple parameter, more context about the data would help the agent understand what to expect. The lack of clarity on return values makes this tool only minimally sufficient.
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?
The input schema has full coverage for the only parameter ('count'), with a clear description: 'Number of device status entries'. The tool description adds no additional meaning about parameters, so the baseline score of 3 applies because schema coverage is high and the description does not contradict or add confusion.
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?
The description clearly states what the tool does: 'Get status of connected devices' with specific examples (pump, CGM, phone). This verb+resource+example structure makes its purpose unmistakable and distinguishes it from sibling tools like glucose_current or analyze, which focus on other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention when not to use it or point to sibling tools for related needs. The only implied context is that it is for device status, but no exclusions or comparison to other tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full burden. The word 'Get' implies a read operation, but the description does not disclose what 'status and settings' includes, the response format, or any potential errors, leaving significant behavioral ambiguity.
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 a single, efficient sentence with no redundancy. It front-loads the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is marginally sufficient: it identifies the resource but omits any details about the response content or nuances. Given the minimal annotations and no output schema, a bit more context (e.g., what settings are returned) would improve completeness.
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?
The tool has zero parameters, and the schema is trivially complete. With no parameters to describe, the description need not add anything beyond what the schema provides, meeting the baseline for 0-parameter tools.
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?
The description uses a specific verb ('Get') and clearly identifies the resource ('Nightscout server status and settings'). This distinguishes it from sibling tools that focus on glucose data, treatments, devices, and analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or sibling tools that might be more appropriate for specific tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Analyze glucose patterns' without explaining what the output looks like, whether it is a read-only operation, or what types of analyses are performed. It does not describe the return format or any side effects, making it inadequate for an agent to anticipate the tool's behavior.
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 two sentences, front-loaded with the action, and wastes no words. It efficiently conveys the core functionality and supported date formats. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description must explain what the tool returns or accomplishes. It only states 'Analyze glucose patterns' without detailing the nature of the analysis or the result format. This is a significant gap for a tool with minimal structured metadata, leaving the agent uncertain about the tool's output.
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 coverage is 100%, so the schema already documents all parameters. The description repeats the date formats (YYYY-MM-DD, YYYY-MM, relative periods) already present in the 'from' description. It adds a slight ambiguity by suggesting 'any date range' supports relative periods, while the 'to' schema only allows absolute dates. It provides marginal value but doesn't fully compensate for the schema's clarity.
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?
The description clearly states the tool's purpose: 'Analyze glucose patterns for any date range.' The verb 'Analyze' and resource 'glucose patterns' are specific, and 'any date range' distinguishes it from the sibling tool 'analyze_monthly' which is likely month-specific. This is a specific verb+resource+scope statement.
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?
The description implies usage for arbitrary date ranges with support for dates, months, and relative periods. However, it does not explicitly state when NOT to use this tool or name alternatives. The sibling tool 'analyze_monthly' is not mentioned, though the contrast is clear. This provides clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the purpose and a use case but does not disclose whether the tool is read-only, what data it covers, or what the output looks like. This is a significant gap for a tool with no other behavioral hints.
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 two short sentences with no filler. It succinctly states the purpose and a key use case, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents the parameters, and the description gives a clear purpose. However, since there is no output schema, the description should ideally hint at what the analysis produces. The current description leaves the output unspecified, which is a notable omission.
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?
The input schema provides descriptions for all four parameters (year, tirGoal, toMonth, fromMonth), covering 100% of the schema. The description adds no additional parameter semantics beyond the monthly breakdown, so the baseline of 3 applies.
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?
The description names a specific verb ('Analyze') and resource ('glucose data') with a clear scope ('by month'), and the phrase 'Great for yearly reviews' adds a use case. This distinguishes it from the sibling 'analyze' tool, which presumably does broader analysis.
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 explicitly suggests the tool is suitable for yearly reviews, giving a clear context for when to use it. However, it doesn't mention when not to use it or point to alternatives like 'analyze' or 'glucose_history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety and behavior. It correctly indicates a read operation but offers no detail on error conditions, units, or whether data might be missing. This is adequate but minimal.
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 a single, efficient sentence with no filler. It conveys the essential information without redundancy.
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?
Given zero parameters and no output schema, the description is mostly complete for selection and invocation. However, it does not specify units or timestamp behavior of the returned reading, which could be relevant in a medical context.
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?
The tool accepts zero parameters, so parameter guidance is not needed. The description appropriately focuses on what the tool does. Baseline 4 is applied.
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?
The description uses a specific verb ('Get') and identifies a concrete resource ('current blood glucose reading from Nightscout'). It clearly differentiates from sibling 'glucose_history' by specifying 'current'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the latest glucose value but provides no explicit guidance on when to choose it over glucose_history or other siblings. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![nightscout-mcp MCP server](https://glama.ai/mcp/servers/vgmakeev/nightscout-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vgmakeev/nightscout-mcp)

Score Badge

Copy to your README.md:

[![nightscout-mcp MCP server](https://glama.ai/mcp/servers/vgmakeev/nightscout-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vgmakeev/nightscout-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vgmakeev/nightscout-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server