Loading ToolBench
Server defines 5 tools with reasonable coverage for Uptrace observability queries. Tool names follow verb_noun pattern (search_spans, get_trace, search_groups, search_services, search_logs) which is correct. Descriptions are present and substantive (100-200 chars typical), explaining WHAT each tool does. Input schemas are properly defined with JSON Schema format, types, and parameter descriptions. However, there are significant gaps: output schemas are NOT documented anywhere, error handling guidance is absent, parameters lack validation constraints (e.g., time formats are described as ISO but no regex pattern), and some tools have sparse parameter sets that may require follow-up calls. The format enum (text vs json) is good but the tool does not explain which output structure is returned for each format. Overall quality is above-average for community servers but falls short of production-grade due to missing output documentation and error recovery guidance.
Get all spans for a specific trace ID. Useful for debugging and understanding request flows.
Search and aggregate spans by groups. Supports GROUP BY operations and aggregations like count(), avg(), p99(), etc.
Search logs by text, severity, service name, or custom UQL query. Logs are represented as spans with _system = 'log:all'.
Search for services that have reported spans. Useful for discovering available services in the system.
Search spans with custom filters using Uptrace Query Language (UQL). Supports WHERE clauses, filters, and aggregations. Use 'where _status_code = "error"' to find error spans.
Output schemas are not documented. Tools return data in 'text' or 'json' format but callers do not know the field structure, types, or required fields of responses. This forces LLMs to guess at response shape and plan downstream operations blindly.
Error handling is not described. Tools do not explain what errors are possible, how to recover, or what the LLM should do if a call fails. For example, what happens if trace_id does not exist? What if time_gte > time_lt? What if API quota is exceeded?
Time parameters (time_gte, time_lt) are described as ISO format but lack regex pattern or explicit validation rules in the schema. LLMs may pass malformed timestamps like '2024-01-15' (missing time component) or '2024-01-15T12:00:00' (missing Z). Schema should enforce format: 'date-time'.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 60 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
uptrace_search_services and uptrace_search_logs accept only 'hours' parameter with no query flexibility. This forces calls to look back a fixed window (24h, 3h) even if the user needs a different time range. No time_gte/time_lt parameters means less precise control compared to other search tools.
Parameter descriptions for 'query' and 'format' could be more prescriptive. 'UQL query string (e.g., ...) does not explain what happens if the query is invalid, what syntax errors look like, or where to find UQL documentation. 'format' description does not specify output field names for json vs text.
uptrace_search_logs description is minimal (50 chars): 'Search logs by text, severity, service name, or custom UQL query. Logs are represented as spans with _system = \'log:all\'.' The last sentence about internal representation (_system field) is implementation detail, not user-facing guidance. No parameter descriptions for what fields are searchable.
No tool documents pagination. uptrace_search_spans and uptrace_search_groups accept a 'limit' parameter (default 100) but do not specify whether responses include a total_count, next_cursor, or pagination metadata. If 100+ results exist, how does an agent fetch the next page?
uptrace_get_trace description says 'Get all spans for a specific trace ID' but does not explain the output structure (array of spans? trace object with nested spans?) or whether results are paginated if a trace has thousands of spans.