Loading ToolBench

Reading the current corpus…

elemctl MCP server · D · ToolBench

elemctl

CLI, MCP server and library for the Console API v2 of the 1C:Enterprise.Element platform (1cmycloud): applications, builds from source, one-command deploy with verification, a compile probe

2026-07-28+STDIO23 tools

59/100

Definition Quality70

Protocol Readiness50

Supportability47

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence

Current-spec patterns detected

Summary

23 tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. All tools have names starting with action verbs (list_, get_, create_, delete_, deploy_, etc.) and descriptions present. However, most parameter descriptions are minimal (1-2 words), and output schemas are not documented. Error handling guidance is absent. The server mixes read-only, write, and irreversible operations without clear risk annotations. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite having tools marked DESTRUCTIVE and IRREVERSIBLE.

Tools (23)

apply_buildirreversibleauthsource verified67/100

Apply a build to an application

build_assemblywritesource verified67/100

Build an assembly from source code

create_appwriteauthsource verified68/100

Create a new application on the platform

delete_appdestructiveauthsource verified67/100

Delete an application from the platform

delete_builddestructiveauth50/100

Delete a build from the platform

deployirreversibleauthsource verified63/100

Deploy a build to an application

deploy_from_sourcesirreversibleauth50/100

Build from sources and deploy to an application in one command

ensure_app

Issues (5)

CRITICALtool ↗

No output schemas documented. Tools return data but LLMs cannot plan downstream calls without knowing response structure. E.g., list_apps, get_app, list_builds lack documented return types.

list_appsget_applist_buildsget_buildlist_projectsget_project

HIGHtool-description ↗

Parameter descriptions are minimal (1-2 words: 'Application ID', 'Project ID'). Rubric baseline is 72 chars avg; these are 10-20 chars. LLMs cannot infer format, constraints, or when to use each parameter.

get_appcreate_appdelete_appget_projectget_builddeploy

HIGHconfirmation-request ↗

Destructive and irreversible operations (delete_app, delete_build, deploy, apply_build, merge_branch) lack tool annotations (destructiveHint, idempotentHint) and no confirmation/dry-run support. Agents can accidentally delete or deploy without safeguards.

delete_appdelete_builddeploy

Recommendations

Document output schemas for all tools. E.g., list_apps should specify: returns array of {id, name, project_id, status, created_at}. This enables agents to chain calls and extract required fields.
Expand parameter descriptions to 50-100 chars with format/constraint hints. E.g., 'app_id: Unique application identifier (alphanumeric, 1-50 chars)' instead of 'Application ID'.
Add tool annotations: mark delete_app, delete_build, deploy, apply_build, merge_branch with destructiveHint=true and idempotentHint=false. Mark read-only tools (list_*, get_*, find_*, inspect_*, verify_*, probe_*) with readOnlyHint=true.
Implement dry-run or confirmation pattern for irreversible operations. E.g., deploy could accept a 'confirm=true' parameter, or return a confirmation token requiring a second call.
Add error recovery guidance to tool descriptions. E.g., deploy: 'If deployment fails, call verify_deploy to check current state. If rollback is needed, contact platform support.' Include specific error codes and remediation steps in error responses.

Score history

Overall score trend

First recorded score · v2 rubric

59/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	D	59	2026-07-28+	v2