Loading ToolBench
Two tools with clear, lengthy descriptions and well-structured input schemas. However, both tools suffer from critical security and operational concerns: fastly_api exposes a generic 'body' parameter without validation or escaping, fastly_cli allows arbitrary command execution with minimal constraints, and neither tool provides actionable error recovery guidance. Descriptions are comprehensive but over-verbose (many >500 chars), which wastes tokens and buries essential guidance. Schema format is correct (JSON Schema with types), but parameter descriptions lack specificity about valid ranges, formats, and constraints. Output schemas are entirely undocumented. Error handling is absent, no guidance on retryable vs fatal failures, no actionable error messages, and no recovery suggestions.
Make requests to the Fastly API. Allows accessing all endpoints of the Fastly API with custom paths, methods and parameters. IMPORTANT USAGE NOTES FOR LLMs: 1. When making multiple API calls, summarize the results between calls. The user doesn't see raw API responses. 2. Base URL is automatically added - just provide the path (e.g. '/service'). 3. Authentication is handled automatically - no need to include API keys or know API keys. 4. Common paths: - List services: GET /service - Get service details: GET /service/{service_id} - Get domains: GET /service/{service_id}/version/{version}/domain - Get backends: GET /service/{service_id}/version/{version}/backend - Purge cache: POST /service/{service_id}/purge_all - Get stats: GET /stats (with params: service_id, from, to) 5. Always check status codes in responses. Status 200-299 indicates success. 6. Include simple explanations of what you're doing and what the results mean before and after each API call. # Creating Fastly Compute@Edge Sites To create a Compute@Edge site, you can use a combination of API calls and terminal commands. The API handles service creation and configuration, while terminal commands handle the local build and deployment process. Follow these general steps: 1. Create a new service using the API: POST /service with {"name": "My Site", "type": "wasm"} 2. Initialize a local Compute project using the Fastly CLI 3. Build the project using the appropriate build tools 4. Deploy using the Fastly CLI with the service ID from step 1 # COMMON PITFALLS TO AVOID: 1. DO NOT use --name flag with fastly compute init (use interactive mode or -d -y flags instead) 2. PowerShell requires semicolons (;) not ampersands (&&) for command chaining 3. Fastly compute build creates the package archive AFTER you've built the Wasm binary 4. Build is a TWO-STEP process: first compile to Wasm, then create the package archive 5. Deploy command needs -d flag to avoid hanging on interactive prompts 6. NEVER attempt to extract or use the user's API key directly - auth is handled by MCP 7. To create a service from scratch, you must use API calls for configuration and CLI for local build 8. Check current directory paths carefully before running commands 9. Full URL paths aren't needed in API calls - just use the path portion (e.g. '/service') See the full guide for detailed instructions on handling common errors and PowerShell-specific commands.
fastly_api exposes a generic 'body' parameter accepting any object without input validation, sanitization, or documentation of what JSON payloads are valid. This invites malformed API calls and potential injection attacks if the LLM constructs untrusted payloads.
fastly_cli allows arbitrary CLI command execution via a free-form 'command' parameter with no input validation, allowlist, or rate limiting. An LLM could be tricked into running destructive commands (e.g., 'rm -rf /'). This violates least-privilege and secure-defaults principles.
Neither tool documents output schema. LLMs cannot plan downstream calls or extract relevant fields without knowing what fields are returned, their types, and which are guaranteed vs optional.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Execute Fastly CLI commands securely without exposing API keys. This tool allows you to run Fastly CLI commands while the MCP server handles authentication automatically. The LLM never sees or needs to handle the API key directly. USAGE EXAMPLES: 1. Initialize a Compute project: fastly_cli('compute init --language javascript -d -y') 2. Build a package: fastly_cli('compute build') 3. Deploy a service: fastly_cli('compute deploy --service-id SERVICE_ID -d -y') COMMON COMMANDS: - compute init: Initialize a new Compute project - compute build: Build a Compute package - compute deploy: Deploy a Compute package - compute publish: Build and deploy in one step - whoami: Check authentication status SECURITY NOTE: Authentication is handled automatically. Never attempt to pass API keys in commands.
Error handling is absent. No recovery guidance, no actionable error messages, no classification of retryable vs fatal failures. An API error returns a raw status code with no hint about what to try next.
fastly_api description is 1900+ characters, burying key guidance in verbose prose. Descriptions should be 50 - 200 chars for clarity; longer guidance belongs in separate parameter descriptions or documentation links, not the tool description.
fastly_cli description includes examples ('fastly_cli(...)') using pseudocode syntax that is not valid JSON, LLMs may misinterpret the format and produce malformed calls.
The 'params' parameter in fastly_api lacks type specification, is it a flat object with string values only? Can values be objects/arrays? JSON Schema shows type: 'object' but no properties or additionalProperties constraint, making it ambiguous and error-prone.
fastly_api 'method' is constrained to enum ['GET', 'POST', 'PUT', 'DELETE'] but description does not mention that PATCH is unsupported. If Fastly API supports PATCH, this is a gap; if not, the enum constraint alone is sufficient but should be mentioned in the description.
No pagination support documented for fastly_api. If API responses can be large (e.g., list_services), no mention of limit/offset/cursor parameters or how to handle result sets larger than context window.