Eye provides well-structured tool definitions with complete input schemas and descriptions for all 5 tools. Naming follows verb_noun convention (get_, read_, query_, refresh_, etc.). Descriptions are substantive (50-150 chars) and explain purpose and prerequisites. All parameters have type definitions and descriptions. However, output schemas are not explicitly documented in the visible code, only input schemas are defined via Zod. Error handling is basic (generic error wrapping). Tool composition is sound: each tool has a single responsibility, and chaining is supported via symbolId reuse. Security is appropriate for a read-mostly server (4 of 5 tools are read-only; refresh_index is write-gated). No critical gaps, but output documentation and error recovery guidance would elevate this to 80+.
Get the current status of the project index, including file count, symbol count, and indexing state.
Use first on unfamiliar repositories. Returns a bounded read-only directory tree and does not create .eye runtime state.
Resolve symbol definitions, references, or context. Start with target: "Name" and action: "definition"; then reuse the returned symbolId for exact references or context.
Read numbered source lines without indexing. filePath is projectRoot-relative and line is 1-based.
Refresh the project index by scanning for changed files and updating the semantic index.
Output schemas not documented in visible code. Only input schemas are defined via Zod; return types are inferred from TypeScript types but not exposed to LLMs in tool definitions.
Error handling is generic. asToolError() wraps all errors as plain text without categorization (retryable vs fatal), recovery guidance, or actionable next steps for the LLM.
query_symbol's 'target' parameter accepts a complex discriminated union (by anchor/symbolId/symbol) but the description does not explain the three modes or when to use each. LLMs may struggle to construct valid targets.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
refresh_index is a write operation but lacks a dry-run or confirmation step. Agents could accidentally trigger expensive re-indexing without safeguards.
No pagination support documented. Tools like get_project_structure and query_symbol accept maxEntries/maxResults but do not return a next_cursor or total_count, limiting scalability.