Loading ToolBench
Model Context Protocol server providing tools for accessing MTA (Multi Theft Auto) wiki information and debug companion functionality for MTA server scripting
Server has 13 tools with basic descriptions and parameter schemas, but significant gaps prevent higher scores. Tool names follow verb_noun convention (RunCode, GetLogs, SearchWiki), which is good. However, parameter descriptions are minimal or absent, most params lack detail on format, constraints, or valid ranges. Output schemas are not documented anywhere in the source. Error handling is absent; tools return raw strings with no guidance on recovery. The RunCode tool is particularly risky: it accepts arbitrary Lua code with no validation, sanitization, or permission checks. Wiki tools (GetFunctionList, GetEventList) have enum parameters which is correct, but descriptions lack context on when to use each tool vs. alternatives. No pagination support visible despite tools returning potentially large result sets (e.g., GetFunctionList, GetVehicleModels). Composition is reasonable, tools are single-purpose, but chaining is not documented.
Returns a list of all available MTA scripting events for the specified side (Server or Client), grouped by category
Returns the parameters and event source for a specific MTA Wiki event
Returns the description, syntax, parameters and example for a specific MTA Wiki function
Returns a list of all available MTA scripting functions for the specified side (Server, Client, or Shared), grouped by category
Retrieves the latest 100 lines of debug logs.
Returns the raw HTML source of a MTA Wiki page, useful as a fallback for detailed parsing when other tools do not return the expected result
Returns a list of all valid GTA:SA ped model IDs and their names
RunCode tool accepts arbitrary Lua code with no input validation, sanitization, or permission checks. Poses critical security risk, agents could execute destructive or unauthorized code on the MTA server.
No output schemas documented for any tool. Responses are raw strings (Task<string>), making it impossible for LLMs to parse structured data or chain tools. E.g., GetFunctionList returns a string, not a typed list of functions with IDs for downstream calls.
Parameter descriptions are missing or trivial. E.g., 'name' in RestartResource has no description of what 'name' means (resource name? file path?). 'functionName' in GetFunctionInformation lacks format guidance. LLMs cannot infer valid input without explicit descriptions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Returns a list of all valid GTA:SA vehicle model IDs and their names
Restarts the specified resource on the MTA server.
Runs any arbitrary Lua code on the MTA server, for the purpose of debugging. Will return any result from the code that was run. If running more than a single statement returned information can be obtained using: (function() -- code here return toJSON({ --[[ any value here ]] }) end)()
Searches the MTA Wiki for pages matching the given query. Returns a list of matching page names (usable with GetFunctionInformation and GetPageSource) and their short descriptions
Starts the specified resource on the MTA server.
Stops the specified resource on the MTA server.
No error handling or recovery guidance. Tools return raw strings with no indication of success/failure, error classification, or next steps. E.g., if RunCode fails, the LLM has no way to know if it should retry, ask the user, or try a different approach.
No pagination support visible. GetFunctionList, GetEventList, GetPedModels, GetVehicleModels, and SearchWiki likely return large result sets but have no limit, offset, or cursor parameters. Large responses will exhaust context windows and degrade LLM reasoning.