Skip to main content
Glama
Grafana MCP Server
by nks1097

grafana_criar_fonte_dados

Creates a new Grafana data source with validated parameters such as name, type, URL, access mode, and default status.

Instructions

  1. Criar uma nova fonte de dados no Grafana com parâmetros validados.

Input Schema

NameRequiredDescriptionDefault
urlYes
nomeYes
tipoYes
acessoNoproxy
padraoNo
dados_adicionaisNo

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, the description bears the full behavioral burden, yet it discloses almost nothing: not whether the data source becomes default, what happens on duplicate name, permission/auth requirements, or whether URL reachability is checked. "Com parâmetros validados" hints at validation but never explains it.

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?

It is a single sentence, but the "23." prefix is dead weight and the trailing "com parâmetros validados" clause adds no information. The useful part (create a new Grafana data source) is front-loaded and clear.

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 needn't be described, but for a mutation tool with zero annotations and six undocumented parameters—including a nested freeform object—the description is far too thin to let an agent call it correctly.

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% across 6 parameters, and the description compensates for none of it. Opaque parameters like tipo (which source types?), acesso (proxy default), padrao, and the freeform dados_adicionais object receive no explanation beyond what the bare property names imply.

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?

It states a specific verb ("Criar") and resource ("fonte de dados no Grafana") that is distinguishable from the list/update/delete/excluir siblings by verb alone. However, the leading "23." is meaningless noise and "com parâmetros validados" is vague filler rather than scope detail.

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?

There is no guidance on when to use this versus grafana_atualizar_fonte_dados or grafana_testar_fonte_dados, nor any prerequisites such as required admin permissions or whether to test the connection before saving. The only cue, "parâmetros validados," is not actionable.

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