Provides read-only access to Grafana, allowing listing and health-checking of data sources, searching and analyzing dashboards, and executing data source queries.
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., "@Grafana Context MCP Investigate the recent 5xx spike on the Demo Application Overview dashboard"
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.
A Python FastMCP server that gives assistants read-only access to Grafana and the context needed to interpret what they find. It exposes static guidance and live objects as resources, Grafana API operations as tools, and repeatable investigation workflows as prompts.
For a concise start, load-injection, architecture, MCP Inspector, and shutdown guide, see
DEMO-RUNBOOK.md.
The repository includes a Docker Compose demo with an instrumented Python application, a synthetic
traffic generator, Prometheus, and a pre-provisioned Grafana dashboard. All services run on one VM
and communicate over a private Compose network. Prometheus uses its normal pull model to scrape the
application's /metrics endpoint every five seconds.
Install Docker Engine with the Compose plugin on the VM, clone or copy this project, and run:
docker compose up --build -d
docker compose psOpen these endpoints from a browser that can reach the VM:
Service | Default URL | Credentials/purpose |
Demo app |
| Public demo endpoint |
Prometheus |
| Query and target inspection |
Grafana |
|
|
Grafana opens with the MCP Demo / Demo Application Overview dashboard already available. The load generator makes one normal request per second and injects occasional failures, producing useful request-rate, latency, error-ratio, job-outcome, and process-memory signals.
The application always writes one structured JSON record per request to stdout. When Azure Monitor
settings are supplied, it also batches those records to a Log Analytics workspace using the current
Azure Monitor Logs Ingestion API and DefaultAzureCredential. On an Azure VM, use a managed
identity so no client secret is stored in Compose or source control.
In the Log Analytics workspace, create a custom table named DemoApplicationLogs_CL. Use
demo\azure\sample-log.json as the sample schema.
Create a Direct data collection rule (DCR) in the same region. Its input stream should be
Custom-DemoApplicationLogs, its destination should be the workspace, and its output stream
should be Custom-DemoApplicationLogs_CL. Use source as the transformation when the schemas
match.
Enable a system-assigned managed identity on the VM. On the DCR's Access Control (IAM) page,
grant that identity the Monitoring Metrics Publisher role. For a user-assigned identity, also
set AZURE_CLIENT_ID to its client ID.
Obtain the DCR's immutable ID and logsIngestion endpoint from its JSON view, then configure:
$env:AZURE_MONITOR_ENDPOINT = "https://<endpoint>.<region>-1.ingest.monitor.azure.com"
$env:AZURE_MONITOR_DCR_RULE_ID = "dcr-<immutable-id>"
$env:AZURE_MONITOR_STREAM_NAME = "Custom-DemoApplicationLogs"
docker compose up --build -dFor local testing outside Azure, DefaultAzureCredential also supports Azure CLI credentials or the
AZURE_TENANT_ID, AZURE_CLIENT_ID, and AZURE_CLIENT_SECRET service-principal variables. Do not
commit a client secret. A DCE is only required for private-link scenarios or older DCRs without a
direct ingestion endpoint.
Allow several minutes for records to become queryable, then use:
DemoApplicationLogs_CL
| where TimeGenerated > ago(15m)
| summarize Requests=count(), Errors=countif(StatusCode >= 500), P95=percentile(DurationMs, 95)
by bin(TimeGenerated, 1m)
| order by TimeGenerated ascApplication lifecycle events and unhandled exceptions are written separately to
DemoApplicationEvents_CL. Generate a controlled exception with GET /api/crash, then query:
DemoApplicationEvents_CL
| where TimeGenerated > ago(15m)
| project TimeGenerated, Level, EventType, Message, ExceptionType, RequestId, StackTrace
| order by TimeGenerated descThe application captures startup events and unhandled Python exceptions, including their stack
traces. An immediate process or host termination (SIGKILL, power loss, or kernel failure) cannot
reliably upload its own final event; use Docker/runtime logs and an external availability check for
those failures.
Start the stack, open the Demo Application Overview dashboard with a 15-minute time range, and run:
.\scripts\invoke-crash-spike.ps1 -Count 30 -DelayMilliseconds 100Each call raises a controlled, unhandled RuntimeError. The application returns HTTP 500, increments
the Prometheus request counter, and sends a correlated UnhandledException record with its stack
trace to DemoApplicationEvents_CL. Within the next Prometheus scrape intervals, the dashboard's
HTTP 5xx spike by route panel shows a /api/crash spike. Log Analytics ingestion can take several
minutes; find records from the latest scenario with:
DemoApplicationEvents_CL
| where TimeGenerated > ago(15m)
| where EventType == "UnhandledException"
| summarize Exceptions=count() by bin(TimeGenerated, 1m), ExceptionType
| order by TimeGenerated ascThis is an application-exception simulation, not a forced process termination. A process killed with
SIGKILL cannot execute its own logging or flush logic.
Grafana provisions Demo Log Analytics (UID log-analytics-demo) using the built-in Azure
Monitor data source. For this local demo, the application and Grafana use a dedicated Microsoft
Entra service principal. Its client secret is stored only in the git-ignored .env file. The
service principal needs Monitoring Metrics Publisher on the DCR and Log Analytics Reader on
law-grafana-mcp-demo.
In Grafana Explore, select Demo Log Analytics, choose Logs, select workspace
law-grafana-mcp-demo, and run:
DemoApplicationLogs_CL
| where TimeGenerated > ago(15m)
| project TimeGenerated, Level, Method, Route, StatusCode, DurationMs, RequestId
| order by TimeGenerated descUpload failures are written as errors to container logs; they do not fail user requests. The exporter uses a bounded queue and batches records so request handling does not wait on Azure network calls.
Set a non-default password before exposing the VM beyond a private demo network:
$env:GRAFANA_ADMIN_PASSWORD = "replace-with-a-strong-password"
docker compose up --build -dLimit VM firewall access to trusted source addresses. The application, Grafana, and Prometheus ports are published for demo convenience and are not a production security configuration.
Create a Grafana service account with the Viewer role and a one-time token:
.\scripts\create-grafana-token.ps1 -AdminPassword $env:GRAFANA_ADMIN_PASSWORD
$env:GRAFANA_URL = "http://localhost:3000"
$env:GRAFANA_SERVICE_ACCOUNT_TOKEN = "paste-the-returned-token"
.venv\Scripts\grafana-mcp.exeIf the MCP process runs on a different machine, replace localhost with the VM address. The demo
dashboard UID is demo-app-overview, which can be passed directly to analyze_dashboard or the
investigate_dashboard prompt. Stop the stack with docker compose down; add -v only when you
also want to delete all Prometheus and Grafana data.
Related MCP server: Prometheus MCP Server
MCP primitive | Included |
Resources | Data source guide, dashboard-reading guide, querying guide, live data source inventory, dashboard-by-UID |
Tools | List/get/health-check data sources, search/get/analyze dashboards, execute data source queries |
Prompts | Investigate a dashboard, troubleshoot a data source, explain a panel |
The dashboard analyzer extracts panel queries, data source usage, variables, units, transformations, thresholds, and interpretation caveats. Its insights are structural hypotheses; they must be validated against live values and operational context.
Requires Python 3.10+ and a Grafana service-account token with only the permissions you want the
assistant to use. Typical read access includes datasources:read and dashboards:read; data source
query permissions depend on your Grafana edition and RBAC configuration.
python -m venv .venv
.venv\Scripts\python -m pip install -e ".[dev]"
$env:GRAFANA_URL = "https://grafana.example.com"
$env:GRAFANA_SERVICE_ACCOUNT_TOKEN = "glsa_..."
.venv\Scripts\grafana-mcp.exeOptional variables are GRAFANA_ORG_ID, GRAFANA_TIMEOUT_SECONDS (default 30), and
GRAFANA_VERIFY_SSL (default true). Do not disable TLS verification outside a controlled local
environment.
After installing the package, configure a stdio server in your MCP client. Use an absolute path to the virtual environment executable:
{
"servers": {
"grafana": {
"type": "stdio",
"command": "E:\\AI\\repos\\TestProject\\.venv\\Scripts\\grafana-mcp.exe",
"env": {
"GRAFANA_URL": "https://grafana.example.com",
"GRAFANA_SERVICE_ACCOUNT_TOKEN": "${input:grafana-token}"
}
}
},
"inputs": [
{
"id": "grafana-token",
"type": "promptString",
"description": "Grafana read-only service account token",
"password": true
}
]
}The exact secret-input syntax varies by MCP client. Prefer its secure secret store over saving a token directly in configuration.
query_datasource forwards native query objects to Grafana's POST /api/ds/query. Query models
are plugin-specific, so inspect a known dashboard panel and reuse its target shape. Every query
should include refId and datasource.uid. Start with a narrow range such as now-15m to now.
The server exposes no Grafana create, update, or delete APIs and does not log the token. Tool annotations describe operations as read-only, but actual security comes from a least-privilege Grafana service account.
.venv\Scripts\python -m pytestRun interactively with MCP Inspector using mcp dev src\grafana_mcp\server.py after installing the
development dependencies, or run the server directly through FastMCP:
.venv\Scripts\fastmcp.exe run src\grafana_mcp\server.py:mcpExplain dashboard structure, queries, data sources, variables, semantics, and interpretation risks.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Grafana dashboard UID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Run the Grafana plugin health check for one data source.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Grafana data source UID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Get the complete dashboard JSON and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Grafana dashboard UID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Get configuration metadata for one data source by UID.
| Name | Required | Description | Default |
|---|---|---|---|
| uid | Yes | Grafana data source UID |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
List configured data sources without exposing stored credentials.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Run bounded, read-only native plugin queries through Grafana's data source query API.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Grafana /api/ds/query query objects; include refId and datasource.uid | |
| to_time | No | End time, e.g. now or epoch milliseconds | now |
| from_time | No | Start time, e.g. now-1h or epoch milliseconds | now-1h |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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.
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.
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.
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.
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.
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.
Search dashboards by title and optional tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional exact dashboard tag | |
| limit | No | Maximum results | |
| query | No | Dashboard title search text |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_dashboardcheck_datasource_healthget_dashboardget_datasourcelist_datasourcesquery_datasourcesearch_dashboardsEach 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.
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.
Seven tools is a well-scoped size for a Grafana context server. Each tool covers a distinct, necessary operation without bloat or redundancy.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Read-only finance and operations controls for AI agents with evidence and safe next actions.
Discover Frontier inference capabilities and read sanitized usage through read-only tools.
Provides read access to your GKE and Kubernetes resources.
Read-only access to your Citlyze workspace: AI search visibility, citations, and recommendations.
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
