Loading ToolBench
mcp server for victoriametrics
VictoriaMetrics MCP server exhibits significant quality gaps across the definition rubric. Tool naming follows verb_noun convention (vm_query, vm_labels), which is correct, but descriptions are critically sparse. Most tools have single-sentence descriptions (10-40 chars) that fail to explain WHEN to use them or WHAT they return. Parameter descriptions exist but are minimal (typically 20-40 chars). Schemas are present and properly typed for all tools, but lack return type documentation, the server does not document what each tool returns, preventing LLMs from planning downstream chains. No error handling guidance is present; failure modes are not documented. No input validation constraints (enums, ranges, patterns) are shown. The 'metric' parameter in vm_data_write is typed as 'object' with no inner schema, effectively unvalidated. Overall, the server reads like a thin wrapper over VictoriaMetrics APIs with minimal LLM-optimization effort.
Write data to the VM database
Get all unique values for a specific label
Get all unique label names
mport Prometheus exposition format data into VictoriaMetrics
Query current value of a time series
Query time series over a time range
Tool descriptions are critically short (10-25 chars) and lack actionable context. E.g., vm_data_write: 'Write data to the VM database' does not explain when to use it vs vm_prometheus_write, what format the metric object requires, what the return value contains, or what happens on failure.
No output schema documentation. None of the 6 tools declare what fields they return. LLMs cannot plan downstream tool calls or extract result data. E.g., vm_query_range returns JSON but the structure is not documented, does it contain metric names, labels, timestamps, values? Without this, agents cannot chain tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 39 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
vm_data_write 'metric' parameter is typed as 'object' with no schema for inner properties. This is effectively unvalidated input. What keys does the metric object accept? Are they tags? Labels? The LLM has no guidance and will guess, causing failures. Provide a properly constrained schema.
Parameter descriptions lack format and constraint guidance. E.g., 'step' in vm_query_range is described as 'Query resolution step width' with no indication of valid formats (e.g., '5m', '30s'), ranges, or examples.
No error handling guidance in any tool. The source code shows error responses like 'range query fail: <text>', but the tool descriptions do not explain recovery steps. Per pattern, error responses must tell the LLM what to do next. No distinction between retryable, user-fixable, or fatal errors.
vm_prometheus_write description contains a typo ('mport' instead of 'import') and is only 74 chars. This signals low quality and confuses LLMs.
Optional parameters not marked clearly. E.g., 'time' in vm_query and 'start', 'end', 'step' in vm_query_range are not in 'required' arrays, but descriptions do not explain defaults or behavior when omitted.
No parameter constraints (enums, regex, min/max). E.g., 'query' parameters accept free-form PromQL strings with no guidance on syntax, invalid operators, or query limits. If an LLM passes a malformed PromQL, the tool returns a generic error with no recovery hint.
Environment variable configuration (VM_URL, VM_SELECT_URL, VM_INSERT_URL) is not documented in tool descriptions. LLMs have no way to know the server relies on these env vars or what happens if they are missing. Tool descriptions should hint at prerequisites.