Loading ToolBench
Model Context Protocol (MCP) server adapter for the Action1 REST API (via provided docs).
Action1 MCP Server exhibits significant quality gaps across naming, descriptions, and schema clarity. While it provides 15 tools with visible schemas and descriptions, the definitions lack the specificity and LLM-optimization required for production use. Naming is inconsistent and sometimes vague (e.g., 'call_action', 'list_resource', 'get_resource'). Descriptions are present but generic and under-optimized for LLM selection. Parameter descriptions exist but lack sufficient constraint detail (ranges, formats, patterns). Output schemas are not documented. Error handling is minimal. Generic tools that accept arbitrary resource/action strings (list_resource, get_resource, create_resource, update_resource, delete_resource, call_action) mask the actual API surface and provide no LLM guidance. Union types for IDs (string|number) without disambiguation increase ambiguity. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. The server demonstrates basic competency but falls well short of production quality.
Live audit: probe commonly used endpoints and report availability and sample shapes
Generic action caller
Generic create for any resource
Generic delete for any resource
Diagnostics: quick config snapshot (no secrets)
Convenience: get agent installation links for Windows
Generic get for any resource
Generic resource/action tools lack specificity. Tools like 'list_resource', 'get_resource', 'create_resource', 'update_resource', 'delete_resource', and 'call_action' accept arbitrary string parameters ('resource', 'action') without enums or validation, forcing LLMs to guess valid values. These tools provide zero discovery guidance and hide the actual API surface from the agent. Pattern guidance: split generic tools into specific ones (get_endpoint, create_group, delete_endpoint) OR provide a discovery tool that enumerates valid resource/action names.
No output schema documentation. None of the tools document their return types. LLMs cannot plan downstream tool calls or extract relevant fields without knowing what fields are in the response. The source code shows JSON responses are returned, but the MCP tool registration does not declare output schemas.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Convenience: inspect a deployer by id
Convenience: list endpoint status snapshots with optional client-side filter
Convenience: list endpoints with simple fields and optional filter
Generic list for any resource
Resolve resource names to IDs
Convenience: start remote session for an endpoint
Generic update for any resource
Verify authentication by probing a low-risk GET endpoint
ID parameters use union types (string|number) without disambiguation. Callers do not know whether to pass a numeric ID, a UUID string, a name, or an email. The 'orgId', 'endpointId', 'deployerId' parameters all accept union types with identical descriptions. Ambiguity forces LLMs to guess or make multiple attempts. Add parameter descriptions specifying accepted formats: 'Organization ID: numeric ID (e.g. 123) or UUID string (e.g. 550e8400-e29b-41d4-a716-446655440000)'.
No tool annotations for risk levels. Tools declare Risk: READ_ONLY, WRITE, DESTRUCTIVE in metadata, but these are not exposed via MCP's idempotentHint, readOnlyHint, or destructiveHint annotations in the tool schema. LLMs cannot distinguish dangerous operations from safe ones during planning. All 15 tools lack annotations.
Generic descriptions lack LLM-optimized detail. Descriptions like 'Convenience: list endpoints with simple fields and optional filter' and 'Generic get for any resource' are too brief and vague. They do not explain WHEN to use a tool or WHAT makes it distinct from similar tools. Current descriptions average ~70 chars but lack specificity.
'call_action' violates single-responsibility principle. It accepts an arbitrary 'action' parameter (string) and forwards it to the API. This tool does not specify what actions are valid, does not document what each action does, and does not describe outcomes. It is a pass-through that provides no LLM guidance and could invoke any API endpoint without validation or documentation.
Confirmation and dry-run flags are optional, not properly validated. 'start_remote_session', 'create_resource', 'update_resource', and 'delete_resource' accept 'dry_run' (boolean) and 'confirm' (enum ['YES']) flags, but there is no documented validation logic that prevents non-dry-run execution without confirmation. LLMs may omit these flags accidentally, leading to unintended destructive operations.
No pagination guidance. Tools like 'list_endpoints_simple', 'list_endpoint_status', 'list_resource', and 'resolve_names' accept 'limit' but descriptions do not specify recommended limits, max limits, or whether pagination cursors (next_page) are always returned or only when needed. Large result sets could blow context windows.
Error handling is absent from descriptions. None of the tools document what errors they can return, what they mean, or how to recover. LLMs will receive raw error messages and have no guidance on whether to retry, ask the user, or abandon the operation.
Parameter naming inconsistency and ambiguity. Some tools use 'installType' (enum), others use 'resource' (free string). Parameters like 'body' (object, description='Request body for creation') are too generic, no guidance on valid fields. No suffix conventions (e.g., '_id', '_name') to disambiguate parameter types.