AI gateway for managing and routing LLM requests with MCP server capabilities for trace querying and observability
Vllora MCP server exposes 2 read-only tools for trace querying. Tool naming follows verb-noun convention well (list_traces, search_traces). Both tools have substantive descriptions (95-180 chars). Input schemas are comprehensive with typed parameters and good descriptions. However, output schemas are completely undocumented, the server returns trace data but provides NO schema definition for the response structure. This is a critical gap: LLMs cannot plan downstream operations or extract specific fields when they don't know the response shape. Additionally, error handling is not visible in the code provided, and no tool annotations (readOnlyHint, etc.) are present despite these being read-only operations. Parameter descriptions are detailed and include enums and constraints where appropriate (e.g., operation_names, status, range_filter with predefined values).
The request to list traces from vllora.
Search and filter traces with flexible query options including time ranges, status, model, operation kind, and free-text search.
Output schema completely undocumented. Both tools lack any specification of response structure, field names, or types. LLMs cannot reason about downstream tool calls or field extraction without knowing what data is returned.
No tool annotations present. Both tools are read-only and should declare readOnlyHint=true to signal to LLMs that these calls are safe to retry and have no side effects.
Error handling not visible. No evidence in the source code of how errors are communicated to the LLM. Without actionable error messages that guide recovery (e.g., 'Invalid status filter: must be one of any, ok, error'), agents cannot self-correct.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 67 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 13 | - | v1 |
Parameter 'operation_names' in list_traces lacks a default value or indication of optionality semantics. The inline enum comment lists 10 operation types, but it's unclear whether omitting this parameter means 'all operations' or 'no filtering'.
search_traces filters.labels accepts arbitrary string key-value pairs (additionalProperties). Without documentation of valid label keys or values, LLMs cannot reliably construct filter queries.