Loading ToolBench
A lightweight C++ MCP server with plugin support for tools and resources
LightMCP has 10 tools with mixed quality. Naming is generally verb-based (aidoc_prj_list, get_random_integer, run_lua, get_mem_list) but inconsistent, some use underscores, others use abbreviated prefixes. Descriptions vary widely: aidoc tools have context-specific guidance ('always use this tool first'), while utility tools (get_random_integer, run_lua) have adequate but generic descriptions. Schemas are present for all tools with proper JSON Schema structure, but parameter descriptions are sparse or missing in several tools (e.g., aidoc_prj_list has no parameters documented; filter array in aidoc_file_open lacks type detail). Output schemas are not documented anywhere. Error handling is minimal, no recovery guidance, no categorization of retryable vs fatal errors. The run_lua tool accepts arbitrary code with only runtime duration limits, creating security concerns. Memory tools (get_mem, put_mem, del_mem) lack descriptions of memory persistence, size limits, or lifecycle. Overall, definitions are functional but lack LLM-optimization and production-grade rigor.
Get file contents. For relative paths, prepend parent directory. Do not report markdown file links to user.
Case-sensitive substring search project TOC.
Fuzzy search project TOC.
Lists all AIDoc projects. In case of AIDoc lookup, always use this tool first to match user's request to exact project name.
This tool removes a memory from the memory list.
This tool gets a memory from the memory list.
This tool returns the list of all previously saved memories. Could be useful for getting missing contextual information.
This tool returns a random decimal integer value e.g. 0, 95, 322, 666. Value range is: [0, 2147483647].
Output schemas not documented. LLMs cannot predict what fields to expect from tool responses, forcing them to parse unstructured output or make assumptions about downstream tool compatibility.
Memory tools (get_mem_list, put_mem, get_mem, del_mem) lack critical operational details: persistence scope (per-session vs persistent), size limits, TTL, and whether deletion is reversible. LLMs cannot reason about memory lifecycle.
run_lua accepts arbitrary code with only runtime duration limits. No sandboxing details, no list of allowed/blocked modules beyond vague 'os' and 'io' restrictions. Security posture unclear.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2025-06-18+ | v2 |
This tool puts a memory into the memory list.
This tool executes arbitrary Lua code in a user environment, ideal for math computations and string operations. The script runtime duration is limited to prevent infinite loops. For security, some unsafe functionality in modules like `os` and `io` was stripped to prevent the system damage. Using harmless functions like os.time(), os.date() etc is allowed and encouraged if they are needed for a task you solving. Example: `return _VERSION` outputs the Lua interpreter version. Note: tables cannot be printed directly - use a `for` loop with `print()` to iterate and display contents. Script runs internally via `lua_pcall`.
aidoc_prj_list has no input parameters documented (empty schema), yet description implies it returns a list. Output schema missing, LLM cannot know what fields identify a project for use in aidoc_prj_fuzzy.
No error handling guidance. Tools do not document what happens on failure (e.g., project not found, file not readable, memory key collision). LLMs have no recovery path.