Skip to main content
Glama
Grafana MCP Server
by nks1097

grafana_gerar_relatorio_incidentes

Generate operational incident reports with severity levels and MTTR resolution times; choose a time period and output format for analysis.

Instructions

  1. Gerar relatório de incidentes operacionais, severidade e tempos de resolução (MTTR).

Input Schema

NameRequiredDescriptionDefault
formatoNopdf
periodoNo30d

Output Schema

NameRequiredDescriptionDefault
erroNoMensagem de erro amigável caso haja falha
dadosNoCarga útil da resposta estruturada
avisosNoLista de alertas e avisos operacionais
sucessoNoIndica se a operação foi bem-sucedida
metadadosNoMetadados da execução
id_requisicaoNoIdentificador único da operação

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations at all, the description carries the full disclosure burden and does almost none of it: it never says the operation is read-only, whether the report is generated synchronously or rendered asynchronously, whether output is stored, or how expensive a 30-day MTTR aggregation is. It only names the report's subject matter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One short sentence that front-loads the action, so there is little waste, but the '75.' numbering prefix is pure noise and the single sentence is too thin for a tool with two undocumented parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, but with zero annotation coverage and zero parameter documentation the definition leaves format choices, period syntax, and side-effect profile entirely unresolved. An agent can guess the intent but not call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so both parameters ('formato', 'periodo') are bare titles with defaults and no explanation. The description says nothing about which formats are accepted or how the period string is expressed, leaving the agent to guess the accepted values.

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?

States a specific verb+resource ('Gerar relatório de incidentes') and names the report's contents (severidade, MTTR), which separates it from the other relatório siblings such as gerar_relatorio_alertas or gerar_resumo_pos_incidente. It does not explicitly say how it differs from those siblings, and the leading '75.' is meaningless noise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No indication of when to use this report versus gerar_resumo_pos_incidente, gerar_relatorio_alertas, or plain grafana_listar_incidentes. No prerequisites, no note about whether incidents must exist in the period, no mention of what happens with the default 30d window.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools