Syke exposes 4 tools (read, bash, edit, write) with minimal schema documentation. Tool names are clear action verbs, but descriptions are extremely terse (8-11 words each), parameter descriptions are absent or generic, and output schemas are completely undocumented. No evidence of input validation, error guidance, or security considerations in the visible code. The tools operate on the filesystem with high-risk operations (bash execution, file write) but lack any mention of sandboxing guarantees, permission checks, or audit trails. Parameter schemas exist but lack type constraints, range validation, or format specifications.
Tools (4)
bashirreversible40/100
Execute bash commands with sandboxing support
editwrite35/100
Edit files with read/write operations and sandboxing
readread only42/100
Read files from the filesystem (with sandboxing support)
'Read files from the filesystem (with sandboxing support)' is 59 chars (acceptable), but 'Execute bash commands with sandboxing support' (47 chars) and 'Edit files with read/write operations and sandboxing' (52 chars) and 'Write files to the filesystem with sandboxing' (46 chars) lack critical context. Descriptions do not explain WHEN to use each tool, what they return, or how they differ from each other. LLMs cannot determine why edit vs. write, or read vs. bash.
Output schemas completely undocumented. Tools return unstructured responses (or unknown structure), forcing LLMs to parse free-text output. No evidence of what fields are returned, what types they hold, or how to chain results to downstream tools.
readbasheditwrite
CRITICAL
Recommendations
Expand each tool description to 80-150 characters explaining WHAT it does, WHEN to use it (vs. similar tools), and WHAT it returns. Example: 'read: Read file contents by path. Use for viewing configuration, code, or text files. Returns file contents as string; returns error if path not found or not readable.'
Add description to every parameter. For 'path': 'File path (absolute or relative from working directory; must be within project sandbox).' For 'cwd': 'Working directory for bash command execution (default: project root; restricted to project sandbox).' For 'content': 'File contents as UTF-8 string; if file exists, entire contents replaced.' For 'command': 'Bash command to execute; limited to read-only operations and whitelisted commands; see docs for restrictions.'
Add output schema documentation for each tool. Example for read: 'Returns object {content: string (file contents), size: number (bytes), mimeType?: string}.' For bash: 'Returns object {stdout: string, stderr: string, exitCode: number, durationMs: number}.' For edit/write: 'Returns object {path: string, sizeBytes: number, modifiedAt: ISO8601, success: boolean, error?: string}.'
Add input validation constraints. For 'path': minLength=1, pattern='^[a-zA-Z0-9/_.-]+$' (no .. traversal). For 'command' (bash): enum or pattern restricting to safe commands, or document whitelist. For 'content' (edit/write): maxLength=10000000 (10MB), inform LLM of limits.
Clarify the distinction between 'edit' and 'write'. If edit performs in-place modification, document this. If write truncates, state it.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Parameter 'cwd' (in bash) and 'path' (in all tools) lack descriptions. A 'path' parameter could accept absolute paths, relative paths, symlinks, or URIs, without description, LLMs guess. 'cwd' is ambiguous: does it apply to the bash command execution, file resolution, or both?
No input validation constraints declared. Parameters lack enum, pattern, minLength, maxLength, or range specifications. 'path' parameter could be passed as arbitrary strings (including path traversal attacks like '../../etc/passwd'). 'bash command' is entirely unconstrained, LLMs could invoke destructive commands.
Security concerns not addressed in tool definitions. Tools claim 'sandboxing support' in descriptions but provide no evidence of how sandboxing is enforced, what directories are accessible, or what commands are blocked. Bash tool is marked IRREVERSIBLE (high-risk) but has no dry-run, confirmation, or permission-gate pattern.
Error handling not documented. Tools provide no guidance on recovery strategies, retryability, or actionable error messages. No evidence of categorizing errors as retryable (e.g., file locked) vs. user-fixable (e.g., path not found) vs. fatal (e.g., permission denied).
Tool naming lacks disambiguation. 'edit' and 'write' both perform file write operations; the distinction is unclear. Does 'edit' support partial updates? Does 'write' truncate? No descriptions clarify this.
No audit trail or logging declarations. Tools perform sensitive operations (file read/write, command execution) but provide no indication of what will be logged, who can invoke them, or what permissions are required.
No evidence of idempotency guarantees. If an LLM retries an edit or write operation due to transient failure, will it duplicate content or overwrite correctly?
editwrite
Add dry-run or confirmation support for bash and write operations. Example: add 'dryRun?: boolean' parameter to bash tool; return what would execute without executing.
Add error handling guidance. Include error message templates: 'For read: "Path not found: <path>. Check path and permissions." For bash: "Command not allowed: <cmd>. See whitelist: <list>." For write: "Write failed: <reason>. Ensure parent directory exists and has write permission."'
Document idempotency. For edit/write: 'Calling write multiple times with same path and content is safe (idempotent); no duplicate side effects.' For bash: 'Some commands have side effects (e.g., date/timestamp), use dry-run to preview.'
Add pagination/limit guidance if applicable. For read: document max file size supported. For bash: document timeout (e.g., 30s) and max output size (e.g., 1MB stdout/stderr). Return structured error if limits exceeded.