Grafana Context MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clear and distinct responsibility: listing vs. getting vs. health-checking datasources, searching vs. getting vs. analyzing dashboards, and running queries. There is no meaningful overlap between tools that would cause an agent to select the wrong one.
Naming Consistency5/5
All tools follow the same verb_noun snake_case pattern (e.g., list_datasources, get_dashboard, analyze_dashboard, query_datasource). Naming is predictable and makes the toolset easy to navigate.
Tool Count5/5
Seven tools is a well-scoped size for a Grafana context server. Each tool covers a distinct, necessary operation without bloat or redundancy.
Completeness5/5
The toolset covers the full read-only context workflow: discovering datasources, checking their health, finding dashboards, retrieving dashboard JSON, understanding dashboard structure, and querying datasources. For the stated purpose of providing Grafana context, there are no significant gaps.
Average 3.9/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
- 5 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns 'complete dashboard JSON and metadata,' which gives some insight into the response shape. No additional behavioral context such as error cases, size limits, or auth requirements is disclosed, but the annotations keep this dimension at an adequate level.
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 sentence that directly states the operation and its expected output. It contains no filler or redundancy, and the key purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple fetch-by-UID tool with one documented required parameter, strong safety annotations, and an output schema present, the description is sufficient. There is no need to describe return values in prose because the output schema exists, and no additional operational context seems necessary for correct invocation.
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%: the only paramter, uid, is documented as 'Grafana dashboard UID'. The description does not add extra meaning beyond the schema, such as where the UID comes from or how to find it. With complete schema documentation, baseline 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 states a specific verb and resource: 'Get the complete dashboard JSON and metadata.' It clearly identifies what the tool does and distinguishes it from search_dashboards and analyze_dashboard by emphasizing the complete dashboard object. However, it does not explicitly name any sibling or contrast itself with them, so it stops short of full differentiation.
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 provides no guidance on when to use this tool versus alternatives like search_dashboards or get_datasource. There is no mention of using a dashboard UID or that search should be used first to find the UID. The appropriate usage context must be inferred entirely from the tool name and parameter schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds meaningful context beyond annotations by specifying that the tool produces an explanation covering queries, data sources, variables, semantics, and interpretation risks, which tells the agent what kind of analysis to expect. No contradiction with annotations exists.
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 one concise sentence with no filler. The six listed analysis dimensions are dense but all materially describe the tool's behavior, so every word earns its place and the information is front-loaded.
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?
For a single-parameter, read-only analysis tool with an output schema present, the description covers the essential purpose and analysis scope. It could be slightly more complete by mentioning that get_dashboard should be used when raw dashboard JSON is needed, but the combination of annotations, schema, and description is sufficient for an agent to invoke it correctly.
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 describes the single required parameter 'uid' as the Grafana dashboard UID at 100% coverage. The description adds no further parameter-level detail, such as how the UID is structured or where it can be found, so the schema carries the full burden.
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 the specific verb 'Explain' against the resource 'dashboard' and enumerates the analysis dimensions: structure, queries, data sources, variables, semantics, and interpretation risks. This clearly distinguishes it from fetch-oriented siblings like get_dashboard, which would retrieve raw dashboard data rather than explain it.
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 states what the tool does but never says when to use it instead of a sibling. It does not mention get_dashboard as the alternative for raw retrieval, nor does it note that this tool is for interpretation and semantic understanding rather than data access.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructivedHint=false, so the safety profile is well covered. The description adds no behavioral context beyond the basic operation (e.g., output behavior, error cases, or implications of a health check), but it does not contradict the annotations.
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, front-loaded sentence communicates the entire tool purpose with zero filler. Every word earns its place, and the key scope ('one data source') is immediately clear.
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?
For a low-complexity, single-parameter tool with rich annotations and an output schema, the description covers the essential operational intent. It could mention what a health check result means or when to prefer it over query/get, but nothing critical is misising for a correct call.
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%, and the single parameter 'uid' is adequately documented as 'Grafana data source UID'. The description does not need to add parameter detail, and adding none is acceptable given the schema already carries the semantic load.
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 states a specific verb ('Run'), a specific resource ('the Grafana plugin health check'), and a clear scope ('for one data source'). This clearly distinguishes it from siblings like get_datasource (metadata retrieval), query_datasource (querying), and list_datasources (enumerating).
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 usage on a single data source via a UID, which is clear context. However, it does not explicitly state when to choose this tool over alternatives such as get_datasource or query_datasource, and offers no when-not-to-use guidance.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'read-only' matches that. It adds 'bounded' and 'native plugin queries' as useful context, but does not disclose details like result limits, pagination, or error behavior. No contradiction with annotations.
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, tightly-worded sentence that front-loads the core behavior and key constraints. There is no fluff or repetition of schema details.
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 a read-only annotation, a rich output schema, and a 100%-described input schema, the description does not need to repeat parameter details. It gives enough context to distinguish the tool from siblings and to signal safety, though a brief note on datasource UID resolution 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?
Schema description coverage is 100%, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema, which already explains the query objects and time range fields.
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 states a specific verb ('Run') and resource ('native plugin queries through Grafana's data source query API'), clearly distinguishing this from sibling metadata tools like list_datasources or check_datasource_health. It names the exact API pathway and adds 'bounded, read-only' to characterize the operation.
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 when to use the tool through 'query' against the data source API, and the sibling names make the distinction obvious. However, it does not explicitly name alternatives, state when not to use it, or mention prerequisites such as resolving a datasource UID first.
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?
Annotations already provide a strong safety profile: readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds only the search predicate; it does not disclose return behavior, pagination, or open-world aspects beyond what annotations already signal. This is acceptable given the annotation coverage.
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, front-loaded sentence containing only essential information: what the tool searches and the filtering dimension. Every phrase earns its place, with no redundant modifiers or filler."
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All parameters are optional with defaults documented in the schema, and an output schema exists. The description plus structured data is sufficient for an agent to call this read-only search tool correctly; no critical invocation details are missing.
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% and the description restates the schema's query and tag parameters without adding extra semantics. The baseline of 3 applies because the schema carries the load and the description does not introduce additional meaning or edge cases."
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 ('Search') with a clear resource ('dashboards') and scope ('by title and optional tag'). This distinguishes it from sibling tools like get_dashboard and analyze_dashboard, which target individual dashboards rather than discovery.
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 intended use is implied by the name and description: find dashboards when you only have a title or tag rather than an ID. However, there is no explicit guidance about when not to use it or how it relates to get_dashboard or analyze_dashboard, so the agent must infer the selection logic.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds 'configuration metadata' as a scope cue but does not disclose additional behavioral traits such as authentication requirements, rate limits, or what happens if the UID does not exist. This is acceptable given existing annotations.
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 with no filler. Every word contributes to identifying the action, the target resource, and the selection key.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), rich annotations, and the presence of an output schema, the description adequately covers what an agent needs to know to invoke the tool correctly. No critical information appears missing.
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 fully documents the single parameter 'uid' with its description 'Grafana data source UID', and schema coverage is 100%. The description adds no parameter-level meaning beyond what the schema provides, so the baseline score 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 uses a specific verb ('Get'), a clear resource ('configuration metadata for one data source'), and a precise identifier ('by UID'). It distinguishes itself from siblings like list_datasources and check_datasource_health by scoping to a single data source's metadata.
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 phrase 'one data source by UID' clearly indicates the tool is for retrieving a specific data source's configuration when the UID is known. It does not explicitly mention alternatives or exclusions, but the context is strong enough for an agent to infer when to use it versus listing or health-checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds meaningful behavioral context by explicitly promising that stored credentials are not exposed, which is a security-relevant guarantee beyond the annotations.
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, well-constructed sentence that states the core action and a key behavioral guarantee. There is no filler, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with rich annotations and an output schema, the description is complete. It tells the agent what the tool does and a key security boundary, while the annotations cover read-only and idempotent behavior.
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, so there is nothing for the description to explain about inputs. The baseline for zero-parameter tools is 4, and the description does not need to compensate for schema gaps.
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 states a specific verb ('List'), a clear resource ('configured data sources'), and an important boundary ('without exposing stored credentials'). This distinguishes it from sibling tools like get_datasource, which retrieves a single data source, and query_datasource, which is for querying rather than listing.
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 clearly indicates the tool is for enumerating configured data sources, which is a clear usage context. It does not explicitly name alternatives or say when not to use it, but the intent is obvious enough given the sibling tool names.
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:

[![grafana-context-mcp MCP server](https://glama.ai/mcp/servers/tamalkarm/grafana-context-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tamalkarm/grafana-context-mcp)

Score Badge

Copy to your README.md:

[![grafana-context-mcp MCP server](https://glama.ai/mcp/servers/tamalkarm/grafana-context-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tamalkarm/grafana-context-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/tamalkarm/grafana-context-mcp'

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