Grafana Cloud MCP

Add a note (userNote activity) to an existing incident's timeline using its ID. The note body can include URLs which will be attached as context. Use this to add context to an incident.

Read the agent catalog of Grafana Agent Observability (the grafana-agento11y-app plugin): which agents send telemetry, what their system prompts and tools are, how their prompt versions evolved, and how each version scored. The catalog is derived from ingested telemetry, not from a registration step: an agent exists here once its generations have been seen. It answers "what is this agent" while agento11y_manage_conversations and agento11y_manage_generations answer "what did it do". Operations: - 'list': agents in this tenant, newest activity first. Each row carries the latest effective version, first and latest seen times, generation and version counts, tool count, a system prompt prefix, and token_estimate. Paginated via limit and cursor - 'get': one agent version in full: the complete system prompt, every tool with its JSON schema, and the models it ran on. Returns the latest version unless 'version' is set - 'list_versions': the version history of one agent, one row per effective version with its seen window, generation count, tool count, and token_estimate. Paginated - 'list_version_scores': evaluation score aggregates per version, with per-evaluator score_key, pass and fail counts, and mean_score. Use it to compare how versions scored Versions: an effective version is always 'sha256:<64 lowercase hex>', and only that form is accepted by 'get'; a declared version such as '1.4.2' is reported in the declared_version fields but cannot be looked up. The plugin derives the effective version from the first of these the telemetry carries: the version the SDK reported, a hash of the declared version, a hash of the system prompt. Adding, removing, or editing a tool never mints a new version. Editing the prompt mints one only for an agent that reports neither its own effective version nor a declared version, so an agent that declares '1.4.2' keeps one effective version across prompt edits. Response size: 'get' returns the whole system prompt plus every tool schema, which can be tens of thousands of tokens. Check token_estimate.total from 'list' or 'list_versions' before fetching, and prefer the system_prompt_prefix in those rows when a prefix is enough. Cross-referencing: pass an agent name from 'list' to agento11y_manage_conversations as the search filter agent = "<name>" to find what that agent actually did. Pagination: when a response carries next_cursor, call the same operation again with cursor set to it. For 'list', also repeat the same name_prefix, start_time, and end_time using absolute RFC3339 times; the cursor is bound to those filters and a relative value such as now-7d or 7d re-resolves and is rejected. Permissions: every operation is a read and needs grafana-agento11y-app.data:read (Agento11y Editor or Admin). This tool performs no writes. When to use: - Discovering which agent names exist before filtering conversations or generations by agent - Reading the system prompt or tool inventory an agent ran with, or how they changed between versions - Checking whether a new prompt version scores worse than the previous one When NOT to use: - Reading individual conversations, generations, or their scores (use agento11y_manage_conversations and agento11y_manage_generations) - Inspecting evaluators or the rules that schedule them (use agento11y_manage_evaluators and agento11y_manage_eval_rules)

List, search, and fetch LLM conversations from Grafana Agent Observability (the grafana-agento11y-app plugin). Operations: - 'list': recent conversations (lightweight; id, title, generation count, timestamps), paginated via limit and cursor - 'search': search conversations by filter expression and time range; results include models, agents, error counts, rating and eval summaries, and trace IDs - 'get': one conversation by ID with all its generations, including full prompts and outputs (can be large) Filter syntax for 'search': key operator value, with the value in double quotes; multiple filters are separated by spaces and combined with AND. Filter keys (trace): model, provider, agent, agent.version, status, error.type, error.category, duration, tool.name, operation, namespace, cluster, service Filter keys (metadata): generation_count, eval.passed, eval.evaluator_id, eval.score_key, eval.score Operators: =, !=, >, <, >=, <=, =~ (regex) Example: status = "error" agent = "claude-code" Pagination: when a response has next_cursor, fetch the next page by calling the same operation again with cursor set to next_cursor. For 'search', also repeat the same filters, start_time, and end_time as the first call, using absolute RFC3339 times; relative ranges like now-24h shift between calls and the cursor will be rejected. When to use: - Debugging an AI application: find failing or low-rated conversations, then inspect their generations - Reviewing evaluation results and user ratings across conversations When NOT to use: - Fetching a single generation or its evaluation scores (use agento11y_manage_generations)

Manage the curated conversations of Grafana Agent Observability (the grafana-agento11y-app plugin): bookmark conversations as saved conversations and group them into collections. Two linked resources: - A saved conversation (/eval/saved-conversations) is a bookmark on one conversation, keyed by a saved_id you choose. It gives that conversation a stable ID, a name, and tags a collection can reference. It does not preserve the conversation: retention deletes the bookmark and its collection memberships together with the conversation it points at. - A collection (/eval/collections) is a named group of saved conversations, used as the source material for offline evaluation. Collections hold saved conversations, never raw conversation IDs, so a conversation must already be bookmarked before a collection accepts it. Operations: - 'list_saved_conversations': bookmarked conversations in this tenant, filterable by source ('telemetry' for bookmarked production traffic, 'manual' for hand-built ones). Also reports total_count for the whole filtered set, not just the page - 'get_saved_conversation': one bookmark by ID - 'list_collections_for_saved_conversation': the collections one bookmark belongs to (unpaginated) - 'list_collections': collections in this tenant, each with its member_count - 'get_collection': one collection by ID - 'list_collection_members': the saved conversations in a collection - 'save_conversation': bookmark a live conversation by conversation_id. saved_id is optional and defaults to 'saved-<conversation_id>'; a conversation can only be saved once, so a repeat returns 409 naming the existing saved_id - 'delete_saved_conversation': delete a bookmark by saved_id. Idempotent, and it also removes the bookmark from every collection it belonged to, with no separate membership cleanup. On a source='manual' bookmark the backend goes further and deletes the underlying conversation and its generations, so the content itself is gone - 'create_collection': create an empty collection from a name and optional description. The response carries the server-assigned collection_id needed by the membership operations - 'update_collection': patch a collection's name or description. Omitted fields are left unchanged, and an explicitly empty description clears it - 'delete_collection': delete a collection and its memberships in one transaction. Idempotent, and the saved conversations themselves are kept - 'add_collection_members': add saved_ids to a collection. Every ID must already be a saved conversation (a missing one returns 400 naming it), and re-adding an existing member is a no-op - 'remove_collection_member': drop one saved conversation from a collection. Idempotent, and the bookmark itself is kept Identifiers: saved_id is caller-chosen and accepts letters, digits, '_', '.', ':', and '-' (looser than the evaluator and rule IDs, which reject hyphens). collection_id is a UUID assigned by the server when a collection is created; it cannot be chosen. List rows are already enriched: every saved conversation in 'list_saved_conversations' and 'list_collection_members' embeds the collections it belongs to plus generation_count, total_tokens, agent_names, models, model_providers, and tags. Read those fields instead of calling 'list_collections_for_saved_conversation' per row, which is one request per result. An absent collections field means the row was not enriched; an empty array means the row genuinely belongs to no collection. Pagination: when a response carries next_cursor, call the same operation again with cursor set to it. Echo the value back exactly; never construct or increment one. 'list_saved_conversations' returns an opaque numeric value while 'list_collections' and 'list_collection_members' return the last row ID, so a cursor from one operation passed to another fails or silently skips rows. Keep the same source filter across pages. Permissions: reads need grafana-agento11y-app.data:read (Agento11y Editor or Admin). Every write needs grafana-agento11y-app.eval:write, granted only by the Agento11y Admin role; an Editor token gets 403. When to use: - Reading what is already curated: which collections exist, how large they are, and what is in them - Turning a triaged failure into a regression collection: 'save_conversation', then 'create_collection' or 'add_collection_members' - Bookmarking a conversation found via agento11y_manage_conversations so a collection can reference it by a stable ID - Collection hygiene: renaming a collection, or removing a conversation that no longer belongs in it When NOT to use: - Searching or reading live conversations and generations (use agento11y_manage_conversations and agento11y_manage_generations) - Inspecting evaluators or the rules that schedule them (use agento11y_manage_evaluators and agento11y_manage_eval_rules)

Manage the evaluation rules and guards of Grafana Agent Observability (the grafana-agento11y-app plugin): the configuration that decides when evaluators run. Two different resources with different runtime behavior: - Eval rules (/eval/rules) are asynchronous. A rule selects production traffic (selector, match filters, sample_rate) and schedules its evaluator_ids to score matching generations after the fact. Rules only observe; they never change a request. - Guards (/eval/hook-rules; there is no /eval/guards path) run inline on the request path and can deny it, redact content, or block tool calls. A guard is inert until the agent application calls the hooks endpoint (POST /eval/hooks:evaluate) itself: a stored guard on its own changes nothing. Operations: - 'list_rules': asynchronous eval rules in this tenant (paginated) - 'get_rule': one eval rule by ID - 'list_guards': guards, read from /eval/hook-rules (paginated) - 'get_guard': one guard by ID - 'create_rule': create an asynchronous eval rule from an inline 'definition' - 'update_rule': patch an existing rule; send only the fields to change (rule_id is taken from the 'rule_id' parameter and must not appear in the definition) - 'delete_rule': delete a rule by ID - 'preview_rule': dry-run a selector, match, and sample_rate against recent traffic and return how many generations would match and be sampled, plus example generations. Run this before creating a rule that spends judge tokens - 'create_guard': create an inline guard (stored as a hook rule) - 'update_guard': full replace of a guard (PUT, not PATCH) — omitted fields reset to server defaults, so send the complete definition, normally a 'get_guard' result with your edits applied - 'delete_guard': delete a guard by ID Identifiers (rule_id) accept only letters, digits, '_', and '.'; hyphens are rejected by the API. Rule selectors: user_visible_turn, all_assistant_generations, tool_call_steps, errored_generations, conversation (guards also accept 'all'). Match keys are arrays and include agent_name, agent_version, operation_name, model.provider, model.name, mode, error.type, error.category, and tags.<key>. Pagination: when a response carries next_cursor, call the same operation again with cursor set to it. Permissions: reads need grafana-agento11y-app.data:read (Agento11y Editor or Admin). Every write, plus 'preview_rule' (which persists nothing), needs grafana-agento11y-app.eval:write, granted only by the Agento11y Admin role; an Editor token gets 403. When to use: - A score names an evaluator and you need to know which rule scheduled it and on what traffic - Auditing which guards are live and whether they warn or deny - Binding a new evaluator to production traffic with 'create_rule', after checking the blast radius with 'preview_rule' - Adding a guard, or promoting one from warn to deny after watching its false-positive rate When NOT to use: - Inspecting what an evaluator checks, or the template it came from (use agento11y_manage_evaluators) - Listing conversations, generations, or scores (use agento11y_manage_conversations and agento11y_manage_generations)

Manage the evaluator catalog of Grafana Agent Observability (the grafana-agento11y-app plugin): read evaluators, evaluator templates, and the judge model catalog, and create, test, or delete evaluators. An evaluator is a scoring function (kind: llm_judge, json_schema, regex, or heuristic) that scores generations. The scores returned by agento11y_manage_generations operation 'scores' name the evaluator that produced them. Templates are versioned starting points for evaluators. Judge providers and models are the LLM backends an llm_judge evaluator can use. Operations: - 'list_evaluators': evaluators in this tenant (paginated) - 'get_evaluator': one evaluator by ID, with its kind, config, and output_keys - 'list_templates': evaluator templates, filterable by scope ('global' for built-ins, 'tenant' for locally created ones) - 'get_template': one template with its config, output_keys, and version list - 'list_template_versions': version history of a template, each version with its config and output_keys - 'list_judge_providers': judge providers configured on this stack - 'list_judge_models': judge models, optionally filtered by provider - 'upsert_evaluator': create or update an evaluator from an inline 'definition'. POST is create-or-update keyed on definition.evaluator_id; there is no separate update operation, and re-using an existing 'version' returns 409, so bump the version to change an evaluator - 'delete_evaluator': soft-delete an evaluator by ID. Rules and guards that reference it keep the reference and silently stop producing scores, so check agento11y_manage_eval_rules first - 'fork_template': derive a new evaluator from a template in one call. Prefer this over copying 'get_template' output into 'upsert_evaluator', which the API rejects - 'test_evaluator': run an inline evaluator definition against one generation and return its scores without persisting anything. Useful for tuning a judge config before 'upsert_evaluator' Identifiers (evaluator_id, template_id) accept only letters, digits, '_', and '.'; hyphens are rejected by the API. Template operations need a stack with the evaluator template store configured and return 404 otherwise. Pagination: when a response carries next_cursor, call the same operation again with cursor set to it. Permissions: reads need grafana-agento11y-app.data:read (Agento11y Editor or Admin). Every write, plus 'test_evaluator' (which persists nothing), needs grafana-agento11y-app.eval:write, granted only by the Agento11y Admin role; an Editor token gets 403. When to use: - A score from agento11y_manage_generations names an evaluator and you need to see what it checks - Inspecting a template before deriving an evaluator from it - Tuning an llm_judge config against a real generation with 'test_evaluator' before storing it - Creating an evaluator so a rule or guard can reference it When NOT to use: - Finding which rule scheduled an evaluator, or which guard enforces it (use agento11y_manage_eval_rules) - Listing conversations, generations, or scores (use agento11y_manage_conversations and agento11y_manage_generations)

Manage the offline experiments of Grafana Agent Observability (the grafana-agento11y-app plugin), their trials, and their scores. An experiment is one offline run of an agent over a test suite. Each test case in the suite produces one or more trials, each trial is scored by the experiment's evaluators, and the experiment reports a pass rate. Experiments are created by SDK runners, not from here. Operations: - 'list': experiments in this tenant, filterable by suite_id, status, source, created_by, tag, and a created_at or completed_at window. Each row carries the same result summary as 'get', so finding the experiment that regressed needs no second call - 'get': one experiment with its result summary: pass rate, average final score, total cost and tokens - 'get_report': the per-test-case breakdown, trimmed by row_limit. The test case input and expected values, the score records, and the artifact records are dropped because those fields have no size bound; each trial keeps its error message, a score_count, an artifact_count, and the IDs the drill-downs take - 'list_trials': one experiment's trials, paginated. Prefer this over 'get_report' on a large suite. It reports no cost or token counts: only the report path fills those in - 'list_scores': every score in one experiment, paginated - 'get_trial': one trial in full, including the test case snapshot with its input and expected values - 'list_trial_scores': one trial's scores, with the explanation each judge wrote - 'list_trial_artifacts': one trial's artifact metadata, with a content_ref rather than the bytes - 'list_facets': the distinct suites, owners, and tags across every experiment in the tenant, for building a 'list' filter. Only source, from, and to narrow it; it rejects a filter it would otherwise have to ignore - 'update': patch an experiment's name, description, tags, or metadata. Only the experiment's created_by may patch it, so patching an experiment someone else started answers 401 - 'cancel': stop a running experiment. It checks no owner, so any caller with the write permission can stop any experiment. An experiment that already finished is left alone: the call answers 200 and returns it unchanged instead of failing, so read the status on the result rather than assume a run was stopped Size: 'get_report' is fetched whole before it is trimmed, and a response above 10 MiB fails the call rather than arriving truncated. Pagination: when a response carries next_cursor, call the same operation again with cursor set to it, repeating the first page's filters with absolute RFC3339 times. A relative bound such as now-7d re-resolves between calls and moves the window the cursor was issued against, so it is rejected alongside a cursor. Permissions: reads need grafana-agento11y-app.data:read (Agento11y Editor or Admin). Both writes need grafana-agento11y-app.eval:write, granted only by the Agento11y Admin role; an Editor token gets 403. When to use: - Finding the last experiment for a suite after a suspected regression: 'list' by suite_id, then read the pass rate off the row - Finding which test cases an experiment failed on, then reading one failing trial in full - Labelling an experiment after triage, so 'list' by tag finds it later - Stopping an experiment that is burning judge tokens on a broken candidate When NOT to use: - Reading scores on live production traffic (use agento11y_manage_generations and agento11y_manage_conversations) - Inspecting the test cases a suite defines, or editing them (use agento11y_manage_test_suites) - Inspecting what an evaluator checks (use agento11y_manage_evaluators)

Fetch a single LLM generation and its evaluation scores from Grafana Agent Observability (the grafana-agento11y-app plugin). Operations: - 'get': full generation detail by ID, including prompt, output, model, and usage (can be large) - 'scores': evaluation scores for a generation (evaluator, score key, score type, value, passed, explanation) When to use: - Drilling into one generation found via agento11y_manage_conversations - Checking why an evaluation passed or failed for a specific generation When NOT to use: - Searching or listing conversations (use agento11y_manage_conversations)

Manage the test suites of Grafana Agent Observability (the grafana-agento11y-app plugin), their versions, and their test cases. A test suite is the input side of an offline experiment: a named set of test cases that an SDK runner replays against an agent. Suites are versioned, and a test case belongs to one version rather than to the suite, so every test case operation takes both suite_id and version. A version is either a draft or published. A draft accepts test case edits; publishing freezes it and makes it the suite's latest_version, which is the version a runner picks up. A suite has at most one draft at a time. Operations: - 'list_suites': the test suites in this tenant, newest first. The rows carry no version history - 'get_suite': one suite with its full version history under versions - 'list_test_cases': the test cases of one suite version, oldest first, paginated - 'get_test_case': one test case in full, with its free-form input and expected values - 'create_suite': a new empty suite. It has no version yet, so follow it with 'create_draft_version' - 'update_suite': patch a suite's name, description, or tags - 'create_draft_version': open a new editable version. A suite that already has a draft answers 409 - 'publish_version': freeze a draft. There is no unpublish; a published version answers 409 to a second publish and to every test case edit, so changing a published suite means a new draft - 'upsert_test_case': write a whole test case into a draft version. It replaces the stored case rather than merging into it, so a field left out is cleared; read the case with 'get_test_case' first and send it back complete - 'delete_test_case': remove one test case from a draft version. Deleting a test case that is already gone answers 404 Pagination: when a response carries next_cursor, call the same operation again with cursor set to it. Permissions: reads need grafana-agento11y-app.data:read (Agento11y Editor or Admin). Every write needs grafana-agento11y-app.eval:write, granted only by the Agento11y Admin role; an Editor token gets 403. When to use: - Reading the test cases at the version an experiment used, after it reported a failing case - Adding a regression case to a suite, then publishing the draft so the next experiment picks it up - Correcting a test case whose expected value was wrong When NOT to use: - Reading how a suite scored, or the trials, scores, and artifacts behind it (use agento11y_manage_experiments) - Changing what an evaluator checks (use agento11y_manage_evaluators)

Manage Grafana alerting routing configuration, including notification policies, contact points and time intervals. Notification policies define how alerts are grouped, routed, and which contact points receive them. Time intervals define active/mute periods for alert notifications. When to use: - Understanding how alerts are routed to contact points/receivers - Debugging why an alert went to a specific receiver - Checking grouping, timing, or mute interval settings When NOT to use: - Checking alert rule configuration or state (use alerting_manage_rules)

Manage Grafana alert rules with full CRUD capabilities and filtering. When to use: - Understanding why an alert is or isn't firing - Auditing alert rule configuration (queries, conditions, labels, notification settings) - Finding alert rules by state, folder, group, or name - Creating, updating, or deleting alert rules - Comparing rule versions to see what changed When NOT to use: - Checking how alerts are routed to receivers (use alerting_manage_routing)

Manage Grafana alerting silences. A silence temporarily suppresses notifications for alerts whose labels match a set of matchers, without changing the alert rules themselves. Operations: - 'list': list existing silences. Optionally filter by rule_uid (matches the __alert_rule_uid__ label) or by matchers. - 'get': retrieve a single silence by silence_id. - 'create': create a new silence. Requires matchers, starts_at, ends_at (RFC3339) and comment. - 'update': modify an existing silence by silence_id. Requires matchers, starts_at, ends_at and comment. The id is only kept when the posted matchers and starts_at match the stored ones, so pass back the starts_at returned by 'get'; otherwise Alertmanager expires the old silence and returns a new id. - 'delete': expire/remove a silence by silence_id. When to use: - Muting noisy or expected alerts during maintenance windows - Inspecting or cleaning up existing silences When NOT to use: - Changing alert rule configuration or state (use alerting_manage_rules) - Changing how alerts are routed to receivers (use alerting_manage_routing)

Audits a Loki label strategy and optionally diagnoses query performance. Returns per-label verdicts, missing base labels, normalisation issues, and a recommended set. Pass datasourceUid for live cardinality or labels for static scoring; both may be combined.

Send a message to Grafana Assistant and wait for the full text reply. The assistant may use tools, metrics, logs, and other stack context—broader than firing one isolated data-source query. Use for open-ended questions, triage, or anything that needs assistant reasoning and tool use, in addition to the more targeted MCP tools. **Multi-turn:** pass contextId from a previous ask_assistant result to continue the same conversation. **Time:** complex tasks can take several minutes; the call blocks until the reply is done or the request times out. Consider running this tool as a background task if able.

Check datasource health. Filter by type or UIDs; omit both to check all.

Create a new annotation on a dashboard or panel. Set format to 'graphite' and provide 'what' for Graphite-format annotations.

Create a datasource. If type is ambiguous, call search_plugin_information first; install the plugin if needed. IMPORTANT: always call this tool twice. First call: provide only the type — the tool returns a field schema. After receiving the schema, you MUST ask the user for every required field value explicitly; do not infer or use defaults without user confirmation. Second call: provide the type, the display name in the top-level name argument, schemaReviewed=true, and the fields map populated with values confirmed by the user. Never handle credentials — remind the user to rotate any detected. Returns UID, health check, and a config page link.

Create a Grafana folder. Provide a title and optional UID. Returns the created folder.

Create a new Grafana incident. Requires title, severity, and room prefix. Allows setting status and labels. This tool should be used judiciously and sparingly, and only after confirmation from the user, as it may notify or alarm lots of people.

Start a Grafana Assistant investigation: an agentic, multi-step root-cause analysis across the stack's metrics, logs, traces, dashboards, and alerts. Provide a natural-language instruction describing what to investigate. Optionally set a title, share with teams via teamNames, or pick an agent profile via agentProfileId. The investigation runs asynchronously: this returns investigationId and chatId immediately; poll get_investigation for lifecycle state and results.

Create a Grafana snapshot from a full dashboard payload. Supports optional expiration and external snapshot fields.

Delete a Grafana snapshot by snapshot key.

Get column names for an Athena table. Use after list_athena_tables. NEXT: Use query_athena with discovered column names.

Get column schema for a ClickHouse table. Pass the database from list_clickhouse_tables results. NEXT: Use query_clickhouse with discovered column names.

Start here when users ask about their infrastructure, services, or architecture. Returns pre-built summaries of service groups including topology, metrics, deployment, dependencies, and datasource UIDs. Infrastructure memories are generated by scanning Prometheus metric datasources to discover services, then using AI to summarize each service group. Memories are organized by service group (e.g. "Payment System", "Inventory"). Each group has chunks covering: overview, metrics, deployment, dependencies, logs, and — when code search finds relevant repos — a code & repositories chunk describing the source repos, languages, and deployment/configuration evidence found in the code. Results also include datasource UIDs for metrics (Prometheus), logs (Loki), and traces (Tempo) — use these to query the right datasource in follow-up tool calls. Individual services/components (e.g. "cortex-gw") are listed inside their parent group's overview chunk — use the exact component name in keywords to find the right group. Uses hybrid search (semanticQuery for meaning + keywords for lexical matching). keywords is critical for finding specific sub-components within groups. Batch queries: pass an array of queries (max 3) to explore multiple service groups or angles in a single call. Results from all queries are merged and deduplicated by group name, so overlapping matches won't be returned twice. Prefer batching related angles over multiple sequential calls. IMPORTANT: semanticQuery must be a single short question with the group/component name — e.g. "What metrics does checkout-service expose?". Do NOT append generic terms like "architecture, components, dependencies, telemetry" — these match every document. keywords must use the exact service/component name (e.g. "cortex-gw"). Examples: - User asks "What's my infrastructure like?" → queries: [{semanticQuery: "What services are running?", keywords: "service"}] - User asks "Tell me about the checkout system" → queries: [{semanticQuery: "How does checkout-service work?", keywords: "checkout-service"}] - User asks "Compare the checkout and payment systems" → queries: [{semanticQuery: "How does checkout-service work?", keywords: "checkout-service"}, {semanticQuery: "How does payment-service work?", keywords: "payment-service"}] Each query returns full groups with overview, metrics, dependencies, logs, datasource UIDs, and (when available) code/repo information — enough to start investigating with targeted queries. Required: queries (each entry needs semanticQuery and keywords) Optional: datasourceUID (pass if a datasource UID is known from the conversation, user query, or previous tool results) When to use: - User asks broad questions about their infrastructure or what services are running - User asks about specific services or components - Need topology, relationships, or configuration - Need to discover which datasources (metrics, logs, traces) to query for a service - Before querying raw metrics or logs — check here first to find the right datasource UIDs - Need to know which repository or source code backs a service (when code evidence is available)

Get column schema for a Snowflake table. Pass the database/schema from list_snowflake_tables results. NEXT: Use query_snowflake with discovered column names.

Generate deeplink URLs for Grafana resources. Supports dashboards (requires dashboardUid or provisioningPreview), panels (requires dashboardUid or provisioningPreview, plus panelId), and Explore queries (requires datasourceUid and optionally queries). For dashboard and panel links, provisioningPreview points at a dashboard staged on a provisioning repository branch (e.g. a git-sync PR preview). For explore links, the time range and queries are embedded inside the Grafana explore state. Set shorten=true to also attempt a /goto/<uid> short URL; if shortening fails, the full deeplink is returned.

Get a specific alert group from Grafana OnCall by its ID. Returns the full alert group details, including the most recent alert and its raw payload when the OnCall API provides them. Alert payloads carry integration-specific fingerprints (for example Sentry's payload.data.event.hashes or Alertmanager's payload.alerts[].fingerprint) that identify recurring alerts across different alert groups.

Fetch Grafana annotations using filters such as dashboard UID, time range and tags.

Returns annotation tags with optional filtering by tag name. Only the provided filters are applied.

Get assertion summary for a given entity with its type, name, env, site, namespace, and a time range

Get the list of users currently on-call for a specific Grafana OnCall schedule ID. Returns the schedule ID, name, and a list of detailed user objects for those currently on call.

Retrieves the complete dashboard, including panels, variables, and settings, for a specific dashboard identified by its UID. The response includes 'apiVersion' and 'isV2': when 'isV2' is true the dashboard uses the v2 schema (panels live under 'elements' keyed by name, arranged by 'layout'; variables under 'variables'), otherwise it is classic v1 ('panels[]' with 'templating.list'). WARNING: Large dashboards can consume significant context window space. Consider using get_dashboard_summary for overview or get_dashboard_property for specific data instead.

Retrieve panel queries from a Grafana dashboard. Supports all datasource types (Prometheus, Loki, CloudWatch, SQL, etc.) and row-nested panels. Optionally filter to a specific panel by ID with `panelId`. Optionally provide `variables` for template variable substitution, which populates `processedQuery` and `requiredVariables` fields. Returns an array of objects with fields: title, query (raw expression), datasource (object with uid and type), and optionally processedQuery, refId, and requiredVariables.

Get specific parts of a dashboard using JSONPath expressions to minimize context window usage. JSONPath targets the dashboard's native schema. Classic v1 paths: '$.title' (title)\, '$.panels[*].title' (all panel titles)\, '$.panels[0]' (first panel)\, '$.templating.list' (variables)\, '$.annotations.list' (saved dashboard annotation queries/definitions)\, '$.tags' (tags)\, '$.panels[*].targets[*].expr' (all queries). v2 dashboards (see isV2 from get_dashboard_by_uid) use different paths: '$.title'\, '$.elements' (panels\, keyed by name)\, '$.variables' (variables)\, '$.annotations'. Use this instead of get_dashboard_by_uid when you only need specific dashboard properties.

Get a compact summary of a dashboard including title\, panel count\, panel types\, variables\, and other metadata without the full JSON. Use this for dashboard overview and planning modifications without consuming large context windows.

Retrieves detailed information about a specific datasource by UID or name. Returns the full datasource model, including name, type, URL, access settings, JSON data, and secure JSON field status. Provide either uid or name; uid takes priority if both are given.

Get a single incident by ID. Returns the full incident details including title, status, severity, labels, timestamps, and other metadata.

Get one Grafana Assistant investigation (AI-driven root-cause investigation) by ID. Returns the investigation's identifiers (investigationId and chatId), the authoritative row lifecycle state and metadata (title, description, state, summary, labels, team ownership, timestamps, completion quality, failure details), and the engine work snapshot (sessionStatus, mode, epoch, plan, report content). The row's state field is authoritative for investigation lifecycle (pending, in_progress, completed, failed, cancelled, paused). The snapshot's sessionStatus only describes the engine session (idle, active, pause) — do not infer completion or failure from it. Legacy (v1) investigations may have no snapshot; the row metadata is still returned with snapshotError set.

Get the working thread of one Grafana Assistant investigation (AI-driven root-cause investigation) by ID: the user-visible conversation between the investigation agent and its tools. Resolves the investigation to its backing chat and returns the non-hidden user-visible messages in order. Each message keeps only prose (the agent's narrative and findings), tool calls (toolName and toolInput), and tool results (raw query output); internal reasoning and bookkeeping blocks are excluded. Tool results are returned verbatim and can be large — use limit and offset to page through long threads (total reports the full user-visible count). Use this to inspect the raw data behind a report's [cite:pN] citations: list_investigation_evidence maps each panel ID to a toolUseId, and the tool_result block with that toolUseId in this thread holds the captured query output.

Get detailed information for a specific Grafana OnCall shift using its ID. A shift represents a designated time period within a schedule when users are actively on-call. Returns the full shift details.

Render a Grafana dashboard panel or full dashboard as a PNG image. Returns the image as base64 encoded data. Requires the Grafana Image Renderer service to be installed. Either dashboardUid (for stored dashboards) or provisioningPreview (for dashboards staged on a provisioning repository branch, e.g. a git-sync PR) must be supplied. Use this for generating visual snapshots of dashboards for reports, alerts, or presentations.

Check whether a Grafana plugin is installed and retrieve its details (name, version, type, enabled status). Returns installed=false when the plugin is not found. Use install_plugin when a plugin is not installed to install plugin after confirming this action with the user.

Get example queries for a specific datasource type. Provides sample queries with descriptions for Prometheus (PromQL), Loki (LogQL), ClickHouse (SQL with Grafana macros), CloudWatch (metric configurations), and InfluxDB (Flux and InfluxQL). Use this to understand query syntax and common patterns for each datasource. TIP: Use list_datasources to find datasource UIDs, or get_datasource if you know the exact name.

List available permissions and assignment capabilities for a Grafana resource type.

List all permissions set on a specific Grafana resource (e.g., dashboard, datasource, folder) by its type and ID.

List all assignments for a specific role, showing which users, teams, and service accounts have been assigned this role.

Get detailed information about a specific Grafana role by its UID, including permissions, metadata, and configuration.

Get a Grafana snapshot by key, including snapshot metadata and dashboard payload.

Make an authenticated HTTP request to the Grafana API. Similar to 'gh api' for GitHub. Supports any Grafana API endpoint with optional jq-style response filtering. Use this for API endpoints that don't have a dedicated tool.

Install a Grafana plugin by its plugin ID. If the version is not already confirmed with the user, omit it — the tool will look up the latest version and return it for confirmation before installing.

List alert groups from Grafana OnCall with filtering options. Supports filtering by alert group ID, route ID, integration ID, state (new, acknowledged, resolved, silenced), team ID, time range, labels, and name. For time ranges, use format '{start}_{end}' ISO 8601 timestamp range (e.g., '2025-01-19T00:00:00_2025-01-19T23:59:59' for a specific day). For labels, use format 'key:value' (e.g., ['env:prod', 'severity:high']). Returns a list of alert group objects with their details. Supports pagination.

List all roles in Grafana. Optionally filter to show only roles that can be delegated by the current user. Returns role details including UID, name, permissions, and metadata.

START HERE for Athena: List available data catalogs (e.g. AwsDataCatalog, Iceberg connectors). NEXT: Use list_athena_databases with a catalog.

List databases in an Athena catalog. Use after list_athena_catalogs. NEXT: Use list_athena_tables with a database.

List tables in an Athena database. Use after list_athena_databases. NEXT: Use describe_athena_table to see column schemas before querying.

START HERE for ClickHouse: List available tables (name, database, engine, row count, size). NEXT: Use describe_clickhouse_table to see column schemas.

List dimension keys for a CloudWatch metric. Requires region. Supports cross-account monitoring via optional accountId parameter. Use after list_cloudwatch_metrics. NEXT: Use query_cloudwatch with discovered dimensions.

List metrics for a CloudWatch namespace. Requires region. Supports cross-account monitoring via optional accountId parameter. Use after list_cloudwatch_namespaces. NEXT: Use list_cloudwatch_dimensions\, then query_cloudwatch.

START HERE for CloudWatch: List available namespaces (AWS/EC2, AWS/ECS, AWS/RDS, etc.). Requires region. Supports cross-account monitoring via optional accountId parameter. NEXT: Use list_cloudwatch_metrics with a namespace.