Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Tailr is a Rust-based log tailing/search tool with 5 well-named, action-verb tools (search, tail, list_files, get_file_stats, stream_log). All tools have descriptions and input schemas with type declarations. Tool naming follows verb_noun pattern consistently. However, several definition gaps reduce the score: descriptions are present but lack depth regarding when to use each tool or expected output structure; output schemas are not documented in the source; error handling descriptions are absent; parameter descriptions are minimal (lacking constraints, ranges, or dependency hints); security considerations (path traversal, permission checks) are not evident. The tools are READ_ONLY and well-scoped, but lack the LLM-optimization details (e.g., 'Call this first to discover available files before tailing') that would elevate them to A-grade.
Tools (5)
get_file_statsread onlyauth50/100
Get statistics about a log file (size, line count, modification time)
list_filesread onlyauth50/100
List available log files and directories
searchread onlyauth50/100
Search for keywords in log files with optional level filtering
stream_logread onlyauth50/100
Stream log file entries from a starting line number with real-time updates via WebSocket
tailread onlyauth50/100
Retrieve the last N lines from a log file with optional filtering
Output schemas are not documented. Tools return results, but LLMs have no visibility into what fields to expect. This forces trial-and-error and reduces ability to compose tool outputs into downstream calls.
Parameter descriptions lack constraints, ranges, and validation rules. Example: 'lines' parameter in 'tail' does not state min/max (what if user passes -1 or 1000000?). 'keywords' in 'search' does not state whether regex is supported. No guidance on expected format or bounds.
No error handling or recovery guidance. Tools lack descriptions of failure modes (file not found, permission denied, invalid regex) and actionable next steps for LLMs. Error responses are not visible in source.
searchtaillist_filesget_file_statsstream_log
Recommendations
Document the complete output schema for each tool. Include examples. For 'search': return [{line_number: int, content: string, level: string, timestamp: string}, ...]. For 'tail': return {lines: [{...}], total_lines: int, file_size: bytes}. For 'list_files': return {files: [{name: string, path: string, size: bytes, modified: ISO8601}], directories: [...]}. For 'get_file_stats': return {path: string, size: bytes, line_count: int, modified: ISO8601, access: ISO8601}. For 'stream_log': document message format and connection lifecycle.
Add constraint ranges to numeric parameters. Example: 'lines' parameter in 'tail' should state 'minimum 1, maximum 10000 (default 100)'. 'startLine' in 'stream_log' should state 'minimum 0 (file start), or -N to start N lines from end'. 'limit' in 'search' should state 'minimum 1, maximum 1000 (default 100)'.
Expand descriptions with WHEN to use hints and dependency clarity. Example for 'tail': 'Retrieve the last N lines from a log file, optionally filtered by level. Use this to view recent activity or diagnose current state. If you need to search across the entire file, use search() instead. If you need to list available files first, call list_files().'
Add explicit error handling documentation. Describe failure modes and LLM recovery actions. Example: 'search: If path does not exist, returns error "File not found: /var/log/app.log. Available log files: [list]. Try list_files() to discover valid paths." If regex is invalid, returns "Invalid regex pattern: [pattern]. Check syntax and retry."'
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No tool discovery hints or composition guidance. Descriptions do not explain when to call each tool. Example: should an LLM call list_files first, then search? Or tail directly? When would get_file_stats be useful as a prerequisite?
stream_log description and schema are incomplete. WebSocket behavior (connection duration, reconnection, message format, close conditions) is not documented. Output schema is absent. Parameter 'startLine' and 'maxLines' lack bounds or validation guidance.
No visible security or input validation guidance. Tools accept file paths, no mention of path traversal protection, symlink following, or permission checks. No evidence of input sanitization for search keywords (regex injection risk if regex is supported).
Descriptions are under 200 characters and lack LLM-optimization details. 'Search for keywords in log files with optional level filtering' does not explain typical use cases, expected output structure, or when to use search vs tail. Baseline for A+ tools: 50-200 char descriptions with explicit WHAT, WHEN, and output hints.
searchtaillist_filesget_file_statsstream_log
Document stream_log behavior thoroughly. Include: (1) Connection lifecycle (how long does stream stay open? Does it close after N lines or when new logs stop arriving?); (2) Output format (JSON lines? Raw text? Metadata + line?); (3) Error handling (what if file is rotated mid-stream?); (4) Backpressure (what if client cannot keep up?); (5) Reconnection (how does client resume after disconnection?).
Add input validation guidance for 'search' and other tools accepting user-provided patterns. Document whether regex is supported, case sensitivity, and limits (max pattern length, max results, timeout). Example: 'keywords: array of case-insensitive search strings (no regex). Max 10 keywords. Matches are combined with AND logic (all must appear in a line).'
Clarify filtering semantics in 'search' and 'tail'. Document whether 'levels' are AND or OR combined. Example: 'levels: array of log levels to include (e.g., ["ERROR", "WARN"]). If provided, only lines with these levels are returned. If empty, all levels are returned.'
Add path validation and security guidance. Example: 'path: file or directory path. Must be within configured log directories. Relative paths are relative to the log root. Symlinks are followed. Permissions must allow read access.'
Document output limits and pagination for tools returning multiple items. Example for 'search': 'Returns up to limit results (default 100, max 1000). If more results exist, response includes next_cursor for pagination. Call search() again with cursor parameter to fetch additional results.'
Add usage guidance to list_files. Example: 'Discovers available log files and directories. Call this first if you need to know what logs exist before calling search() or tail(). Useful for clarifying ambiguous file references (e.g., user says "app.log" but multiple variants exist).'
Document any regex or pattern support. If 'search' supports regex, state format (POSIX, Perl, etc.) and provide examples. If not supported, clarify that only literal string matching is performed. Update parameter description to match.