Loading ToolBench
Life Cycle Assessment engine with MCP server support for database queries, matrix operations, and LCA calculations
VoLCA provides 8 tools for LCA (Life Cycle Assessment) analysis with HTTP transport. However, the server has significant definition quality gaps: (1) Most tool descriptions are sparse (10-50 chars), below the 10-1024 char baseline and the 50-200 char target for LLM optimization. (2) Parameter descriptions are minimal or absent in several tools. (3) No output schemas are documented, callers cannot plan downstream tool chains. (4) The shutdown_server and set_idle_timeout tools raise security concerns (irreversible/config mutation without permission gates or confirmation steps). (5) upload_database accepts base64-encoded archive data as a parameter, which is architecturally questionable but not inherently problematic if properly validated server-side. (6) Tool naming follows verb_noun convention (search_, list_, get_, calculate_, solve_, upload_, shutdown_, set_) but some names could be clearer, 'calculate_matrix' and 'solve_lca' are domain-specific and lack clarity on what they return. (7) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite declaring Risk levels in metadata. (8) Error handling and recovery guidance are not visible in the source.
Calculate technology or impact matrix for LCA analysis
Retrieve information about available databases
List all available LCA databases
Search for activities in the database by name and other criteria
Configure the server's idle timeout in seconds
Gracefully shut down the VoLCA server
Solve linear algebra system for LCA impact assessment
Upload a new LCA database archive
Tool descriptions are critically short (10-45 chars). Baseline production tools average 194 chars. LLMs cannot determine when or why to select tools without proper context. E.g., 'Retrieve information about available databases' (50 chars) does not explain what fields are returned, when to call this vs list_databases, or the data structure.
Output schemas are not documented. Callers cannot plan downstream tool chains or extract required fields (e.g., what fields does solve_lca return? Is it impact_values, matrix_result, or something else?). This forces LLMs to guess and wastes context on trial-and-error.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
Parameter descriptions are minimal or missing. E.g., 'name' in search_activities has a description ('Activity name to search for'), but 'database' is generic ('Database name to search in'), does not explain the expected format, how to discover valid database names, or what happens on mismatch.
Irreversible operations (shutdown_server, upload_database) lack permission gates and confirmation/dry-run steps. An LLM could accidentally shut down the server or upload a malicious database without safeguards. No evidence of permission checks or confirmation patterns in source.
No tool annotations (destructiveHint, readOnlyHint, idempotentHint) despite metadata Risk levels (WRITE, IRREVERSIBLE). Spec 2026-07-28 expects tools to declare these hints to guide LLM reasoning about side effects.
Domain-specific tool names (calculate_matrix, solve_lca) lack clarity on purpose and return value. An LLM unfamiliar with LCA terminology cannot infer from the name alone what 'matrix' type is, what 'solve' produces, or when to call them. Average production tool names are 18 chars and use common verbs (get, list, create, search).
Error handling and recovery guidance are not visible in the source. No evidence of actionable error messages, retryable vs. fatal classification, or recovery suggestions. LLMs receive stack traces or bare error codes with no guidance on next steps.
upload_database accepts 'archive_data' (base64-encoded file) as a parameter. While not inherently insecure if validated server-side, this couples the API to a transport encoding that complicates testing and debugging. Consider accepting multipart file uploads or a file URI instead.