Loading ToolBench
A Unity package for natural communication with MCP servers.
The server provides 7 tools with reasonable naming conventions and descriptions, but has significant gaps in schema completeness, parameter documentation, and error handling guidance. Tool names follow verb-noun patterns (RefreshAssets, GetCurrentConsoleLogs, ClearConsoleLogs, GetCompileLogs, RunEditModeTests, RunPlayModeTests, Hello), which is good. However, several tools lack complete input parameter schemas in the JSON schema format, and descriptions, while present, vary in quality and actionability. The server provides some structured output (IReadOnlyList<LogEntry> for logging tools, string for test runners), but output schemas are not formally documented. Error handling is basic (try-catch with Debug.LogError) but does not provide LLM-actionable recovery guidance. Parameter descriptions are present but often lack constraints, ranges, or format specifications.
Clear console logs.
Get compilation errors. Same as `ClearConsoleLogs();GetCurrentConsoleLogs({"compile-error", "compile-warning"}, args)`
Get current console logs. The default value is adjusted to reduce token usage. Simply call it with the default value the first time and specify arguments only when necessary.
Retrurns "Hello World!" message.
Execute AssetDatabase. Refresh.It must also be called when compiling a script.
Run Edit Mode tests on Unity Test Runner. Recommend filtering by assemblyNames, groupNames, or testNames to narrow down the tests to be executed to the scope of changes.
Run Play Mode tests on Unity Test Runner. Recommend filtering by assemblyNames, groupNames, or testNames to narrow down the tests to be executed to the scope of changes.
RunEditModeTests and RunPlayModeTests accept 'cancellationToken' as an object type without schema definition or constraints. The type annotation states 'object' but provides no structure, properties, or guidance on what the LLM should pass.
Error handling lacks LLM-actionable recovery guidance. All tools use generic try-catch with Debug.LogError, but do not provide structured error responses telling the agent what to do next (retry, lookup, etc.). For example, GetCurrentConsoleLogs could fail if regex filter is invalid, but no recovery hint is provided.
ClearConsoleLogs description is minimal ('Clear console logs.'), 19 characters, barely above the 10-char floor. It does not explain when to use it relative to GetCurrentConsoleLogs, whether it's idempotent, or any side effects.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 33 | - | v1 |
Hello tool description contains a typo ('Retrurns' instead of 'Returns') and is overly generic. The tool appears to be a test/example placeholder, not a production tool. If included, it should either be documented properly or removed.
GetCurrentConsoleLogs and GetCompileLogs accept a 'filter' parameter as a plain string but describe it as regex without specifying regex syntax, supported flags, or what happens if the regex is invalid. An LLM could pass malformed patterns.
RunEditModeTests and RunPlayModeTests accept array parameters (assemblyNames, categoryNames, groupNames, testNames) but lack constraints on array length, item format, or what happens if an invalid assembly/test name is passed. Arrays are unbounded.
Output schemas are not formally documented. GetCurrentConsoleLogs and GetCompileLogs return IReadOnlyList<LogEntry>, but the LogEntry structure is not defined in the tool schema. RunEditModeTests and RunPlayModeTests return a string, which is too unstructured for reliable agent composition.
GetCurrentConsoleLogs and GetCompileLogs return a fixed limit (maxCount default 20), but no documentation explains whether results are paginated or truncated, whether a total count is returned, or how to request more results.