Loading ToolBench
Official API-token-first MCP server for deploying and operating StaticX static sites.
StaticX MCP server has 13 tools with complete input schemas and descriptions. Naming follows verb_noun convention (list_, get_, delete_, write_, read_, publish, upload_, index_). Descriptions are present and actionable (avg ~100 chars), explaining WHAT each tool does and WHEN to use it. However, parameter descriptions lack detail on constraints, formats, and valid ranges. Output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling is basic (throws errors but lacks recovery guidance). No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Missing idempotency guarantees for write operations.
Delete a file from the workspace.
Get details about a specific deployment.
Get project logs for debugging deployments and imports.
Get details about a specific StaticX project.
Get the current workspace state and file listing.
Check if a URL is indexed in a search engine.
Submit a search indexing request to SpeedyIndex for a URL.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., staticx_list_projects returns what fields? Is it paginated? Does it include project_id for use in staticx_get_project?
Parameter descriptions lack constraint details. 'status' in staticx_list_deployments says 'Optional filter by deployment status (e.g., succeeded, failed, running)' but does not declare it as an enum or list valid values formally. LLMs may hallucinate invalid statuses.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. staticx_delete_file is DESTRUCTIVE but unmarked. staticx_publish is WRITE with side effects but no idempotency guarantee. Agents cannot reason about retry safety.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
List all deployments for a project, with optional filtering by status.
List all projects in the StaticX account.
Publish the current workspace to production. Waits for the deployment to complete (up to 15 minutes).
Read a file from the workspace.
Upload a ZIP file to the workspace. Large imports are queued and polled until completion.
Write or overwrite a file in the workspace.
Error handling lacks recovery guidance. Code throws StaticxApiError with status and payload, but does not categorize errors as retryable vs. user-fixable. E.g., 'STATICX_API_TOKEN is required' is user-fixable; timeout is retryable. LLMs need explicit guidance.
project_id parameter is optional (falls back to STATICX_PROJECT_ID env var) in all 13 tools, but description says 'If not provided, uses STATICX_PROJECT_ID environment variable.' This is implicit and error-prone. If env var is missing, error is thrown at runtime. Better: make project_id required or document the fallback chain explicitly in each tool description.