Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Detrix provides 10 tools for debug-on-demand observability via MCP. Tool definitions are present with names, descriptions, and input schemas. However, there are consistent gaps in description depth, output schema documentation, and error handling guidance. Descriptions are brief (10-50 chars) and lack context on when/why to use each tool. No output schemas are documented, forcing LLMs to infer return types. Error handling does not guide recovery steps. Tool composition is reasonable, each performs a single action (add, remove, list, get operations), but lacks idempotence guarantees and parameter relationship documentation.
Descriptions are uniformly under 50 characters and lack context. Examples: 'Get the call stack at a specific location' (40 chars), 'Get local variables at a specific location' (42 chars), 'Get the current status of the Detrix daemon' (43 chars).
No output schemas documented. Tools return results but the response structure is not specified. LLMs cannot infer what fields to expect from get_metrics, get_call_stack, or list_locations. Requires tool invocation and trial-and-error to discover return type.
Expand all tool descriptions to 100-200 characters. State WHAT the tool does, WHEN to use it (e.g., 'Call after add_location to retrieve collected metrics'), and key outputs. Example: 'Retrieve collected metrics for a location. Call this after add_location to see what data has been gathered since a specific ISO 8601 timestamp. Returns an array of metric events with timing and values.'
Document output schemas for all tools. At minimum, specify the top-level type (object, array) and list expected fields with types. For list_locations: 'Returns array of {id: string, file: string, line: number, mode: string, active: boolean}'. For get_metrics: 'Returns array of {timestamp: ISO8601, event_type: string, value: number}'.
Add constraints to parameter descriptions. For mode in add_location: 'Metric collection mode: None (disabled), Sample (periodic sampling), or Full (capture every call). Use Sample for low-overhead profiling; Full for detailed debugging.'
Specify format for since parameter in get_metrics: 'Optional ISO 8601 timestamp (e.g., 2024-12-20T10:30:00Z) to fetch metrics collected after this time. If omitted, returns all metrics for the location.'
Add idempotence guarantees. Document whether calling add_location with the same file:line twice creates a duplicate location or updates the existing one. E.g., 'Idempotent: calling with the same file and line replaces the existing location configuration.'
For destructive tools, add recovery guidance. E.g., remove_location description: 'Remove a metric collection location. This is permanent but can be re-enabled by calling add_location again with the same file and line.'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 8 points across a rubric change (v1 → v2)
54/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-21
D
54
<=2025-11-25
v2
2026-03-09
F
46
-
v1
remove_locationwriteauth50/100
Remove a metric collection location
set_breakpointwriteauth50/100
Set a breakpoint at a code location
Parameter descriptions lack actionable constraints. 'mode' enum in add_location lists values (None, Sample, Full) but does not explain what each mode does, when to use each, or consequences. 'since' parameter in get_metrics lacks format specification, is it ISO 8601, epoch seconds, or natural language?
No error handling guidance. Tools lack documentation on failure modes, recovery steps, or actionable error messages. What happens if location_id does not exist? What does the LLM do next?
Destructive operations (add_location, remove_location, set_breakpoint, remove_breakpoint) lack confirmation/dry-run patterns. No tool description indicates whether these are idempotent or have side effects.
Parameter relationships undocumented. 'location_id' and 'breakpoint_id' appear in multiple tools but relationship to 'file' and 'line' from add_location/set_breakpoint is not explained. LLM must infer that location_id returned from add_location can be passed to get_metrics.
Missing chaining hints. If add_location returns a location_id and get_metrics requires it, the add_location description should hint: 'Returns a location_id for use in get_metrics, get_call_stack, etc.' Currently no such guidance exists.
Lack of discovery context. Tools like list_locations and get_status are discovery/observability tools but descriptions do not explain when to call them first or how their results inform downstream decisions.
list_locationsget_status
Include parameter relationship hints. In get_metrics, add_call_stack, and get_local_variables descriptions: 'location_id is returned by add_location after setting up a metric collection point.'
Add discovery hints to list_locations: 'Call this first to see all active collection points and their IDs before fetching specific metrics or stack traces.'
Document error paths. Add to all parameter descriptions: 'Raises error if location_id/breakpoint_id does not exist or has been removed.'
For evaluate_expression: specify syntax and scope. 'Evaluate an expression in the context of a specific location. Expression syntax follows the debugged language (e.g., Python or Rust). Returns the evaluated result or an error if the expression is invalid.'
Provide natural-language path guidance. File parameter example: 'Absolute or relative file path (e.g., src/main.rs or /home/user/project/src/main.rs).'
Create a batch variant for efficiency. E.g., add_locations (plural) accepting an array of {file, line, mode} to set multiple collection points in one call, reducing round-trips.