Loading ToolBench
The server defines 3 tools with descriptions and input schemas. However, multiple critical gaps emerge: (1) Parameter descriptions are present but minimal (10-20 chars), falling below the 34-char baseline. (2) No output schemas are documented, responses are inferred from code but not formally declared. (3) Error handling returns unstructured dicts with 'success' flags and 'help' hints, but lacks recovery classification or clear next-step guidance. (4) Tool names are verb-based but generic ('check_credentials', 'create_api_key', 'upload_project'), they follow the convention but offer little signal about alternatives or preconditions. (5) Security: the `create_api_key` tool accepts an API key as a plain string parameter, which violates the secret-injection pattern; this should use server-side credential storage. (6) No input validation constraints (enums, ranges, patterns) are declared in schemas. (7) Idempotency and composition are not addressed, repeated calls to `upload_project` with the same input may produce duplicate uploads.
Check your yourware credentials exists and are valid.
Create a new yourware API key. This will automatically be stored in ~/.yourware/credentials.json. Use this tool if current credentials are invalid
Upload a file or directory to yourware, might be a dist/out directory or a single html file. Use absolute path if possible. For multiple files, you should move them to a directory first, then use this tool to upload the directory
create_api_key accepts API key as a plain string parameter, violating secret-injection pattern. Secrets in tool parameters are logged in traces and prompt history.
No output schemas documented for any tool. Responses are unstructured dicts inferred from code. LLMs cannot plan downstream calls or extract specific fields without explicit schema documentation.
Parameter descriptions are too brief (10 - 20 chars vs 72-char baseline). E.g., 'The API key to store' and 'The current working directory to resolve relative paths from, should be a absolute path' lack format constraints, valid ranges, or dependency hints.
Error responses lack recovery classification. Responses like {'success': False, 'help': '...'} do not tell the LLM whether an error is retryable, user-fixable, or fatal. No actionable next-step guidance beyond generic help text.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
No input validation constraints declared. file_path and cwd parameters accept any string; no length limits, regex patterns, or path constraints are formally specified. LLMs may pass invalid paths (e.g., non-existent dirs, relative paths without resolution logic visible).
Idempotency and duplicate-prevention not addressed. upload_project may create duplicate uploads if called twice with identical inputs. No mention of idempotent semantics or conflict handling.
Tool composition weak. upload_project requires valid credentials but does not return a deployment ID or URL. Downstream tools cannot chain on the result. No guidance on what happens after upload (e.g., does it auto-deploy? Return a live URL?).