Loading ToolBench
MCP server for managing Akamai Functions applications, including deployment, status monitoring, logging, and account management
The server has 10 tools with mostly clear naming and reasonable descriptions. Tool names follow verb_noun conventions (get_app_status, list_apps, deploy_app, etc.). Descriptions are present and generally explain WHAT the tool does. However, there are significant gaps: (1) Input schemas are visible in the code but descriptions for some nested object properties lack clarity, the 'account' parameter is an object with an 'id' property, but the relationship between name and ID is underspecified; (2) Error handling descriptions are minimal, tools don't guide the LLM on retry logic, alternatives, or failure modes; (3) Output schemas are partially documented in code (AppStatusResponse, ToolResponse structs) but not consistently clear in descriptions; (4) The deploy_app tool has critical instructions embedded in its description rather than enforced via parameter constraints and validation. Baseline: 194 chars avg description length, most tools here are 150-300 chars, which is appropriate. Tool naming is solid. Parameter descriptions exist but could be more prescriptive about formats and constraints.
Deploys the application to Akamai Functions. STRICTLY FOLLOW THESE SAFETY RULES: 1. You MUST ALWAYS ask the user for confirmation before calling this tool. 2. If the current workspace contains a '.spin-aka/config.toml' file, it is a recurring deployment and you MUST NOT set 'isFirstTimeDeployment' to true. 3. If there is no '.spin-aka/config.toml' file, ask the user if this is a first time deployment or if they want to link the workspace to an existing app in their Akamai Functions account. 3.1 If they wanna do a first time deployment, set 'isFirstTimeDeployment' to true and provide the app name from the spin.toml file. 3.2 If it is not a first time deployment, ask them which app they wanna link to (use the list_apps tool to show them a list of existing applications). Tell the use to provide either the app name or ID. Pass the value provided by the user to the 'link_app' tool. Finally call 'deploy_app' with 'isFirstTimeDeployment' set to false 3. Set 'isFirstTimeDeployment' to true ONLY if deploying an app for the first time.
Retrieve the history of an Akamai Function. You can omit the ID or Name if you are running this in a project directory containing a .spin-aka/config.toml file; the server will auto-detect the application.
Retrieves logs for an Akamai Function. You can omit the ID or Name if you are running this in a project directory containing a .spin-aka/config.toml file; the server will auto-detect the application.
Retrieve the status of an Akamai Function. You can omit the ID or Name if you are running this in a project directory containing a .spin-aka/config.toml file; the server will auto-detect the application.
deploy_app description embeds critical operational logic (first-time vs. recurring deployment, user confirmation requirements, fallback workflows) as narrative text in the description rather than as enforced parameter constraints or validation. This forces the LLM to infer and follow procedural steps rather than being guided by schema. Lines like 'You MUST ALWAYS ask the user for confirmation' and 'If the current workspace contains a .spin-aka/config.toml file...' are instructions, not tool documentation.
The 'account' parameter is defined as an object with only 'id' property visible in schemas, but the description states 'provide the account name or its identifier', implying both name and ID are accepted. The schema does not include a 'name' field, and the parameter descriptions do not clarify the precedence or how name resolution works. This ambiguity forces the LLM to guess which field to use.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 43 | - | v1 |
Retrieve the public endpoint for an Akamai Function. You can omit the ID or Name if you are running this in a project directory containing a .spin-aka/config.toml file; the server will auto-detect the application.
Links the current workspace to an application existing on the user's Akamai Functions account. USE THIS WHEN: 1. The user explicitly asks to link this folder (or workspace) to an app deployed to their Akamai Functions account. 2. A deployment, status, history, or log request fails because the workspace is not linked (workspace has no link to an app deployed to Akamai Functions). IMPORTANT: You must provide the exact App ID or Name. Use 'list_apps' to see all apps and ask the user which remote app should be linked to.
List all Akamai Functions accounts I have access to
Get all Spin apps deployed to your Akamai Functions account
Find an app using the specified query in any of my Akamai Functions accounts
Unlinks the current local workspace from the application deployed to Akamai Functions. USE THIS WHEN: 1. The user explicitly asks to unlink this workspace from an existing app. IMPORTANT: This does NOT delete any remote applications, it only removes the local link (the .spin-aka/config.toml file).
Error responses lack actionable recovery guidance. Tools return NewToolErrorResponse with a message string, but there is no pattern for categorizing errors as retryable, user-fixable, or fatal, nor guidance on next steps. For example, if get_app_status fails because the app doesn't exist, the LLM doesn't know to call search_app or list_apps.
Output schemas are defined in Go structs (e.g. AppStatusResponse in app.go) but not documented in tool descriptions. Users and LLMs cannot predict the response structure from the tool definition alone, they must infer it from implementation. The ToolResponse[T] wrapper with 'success', 'message', 'data' fields is consistent but not formally declared.
Parameter descriptions lack format constraints and value ranges. For example, 'maxLines' in get_app_logs has description 'Maximum number of log lines to retrieve,default=10' but no stated min/max bounds (is 0 valid? Is 10000 valid?). Users cannot infer what values are sensible.
The 'app' parameter in multiple tools is described as an object that requires 'either Name or ID', but the validation logic (ByAppArgs.Validate in app.go) enforces that exactly one must be provided. This constraint should appear in the description and/or be represented as separate optional parameters (app_id, app_name) rather than a single overloaded object.
Responses from list_apps and search_app are not documented, no mention of pagination, result limits, or field structure. If list_apps returns 500 applications, the LLM context may be exhausted. Pagination or result limits should be documented in the description.
Confirmation flow for destructive operations (deploy_app, link_app, unlink_app) is described in prose in tool descriptions rather than enforced by a dedicated confirmation/dry-run pattern. The description says 'You MUST ALWAYS ask the user for confirmation before calling this tool' but the schema and error handling do not support this workflow formally.