Loading ToolBench
Textualize MCP has 8 tools with moderate definition quality but significant gaps in parameter descriptions, output schemas, and error handling. Tool names follow verb_noun conventions (launch_app, stop_app, list_apps, get_app_status, send_input_to_app, capture_screen, setup_multiplex_environment, send_http_request), which is positive. However, the implementation reveals incomplete schemas, missing parameter constraints, and no visible output schema documentation. The server uses fastmcp but STDIO transport only, which is a hard cap at 50. Most tools lack actionable error messages and parameter validation guidance.
Capture the current screen output of a running in-process application
Get the status of a running application
Launch a Textual application in terminal, web, or in-process mode
List all available Textual applications
Send an HTTP request to an API endpoint (for API Tester app)
Send keyboard input to a running in-process application
Setup a multiplexed terminal environment with multiple applications
Output schemas not documented. No visible return type specifications for any tool. LLMs cannot plan downstream tool calls or structure parsing without knowing what fields are returned.
Missing parameter descriptions and constraints. 'web_mode' and 'in_process' parameters lack explanations of what they do or how they differ. 'port' parameter has no range specification (valid range unknown). 'custom_config' in setup_multiplex_environment is undocumented object structure.
No error handling guidance. No recovery hints if app_id is invalid, if app fails to launch, or if port is already in use. Descriptions lack 'What to do if this fails' guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Stop a running Textual application by app ID
Weak tool descriptions. Most descriptions are 50-70 characters, below the 194-char baseline for production tools. Descriptions like 'Get the status of a running application' lack context on when to call it instead of other tools or what specific status fields are returned.
Mutually exclusive parameters not documented. launch_app accepts both 'web_mode' and 'in_process' as booleans, no indication which take precedence, whether both can be true, or what happens if both are false.
No pagination or result limits documented. list_apps returns all available applications with no limit or pagination parameters. If hundreds of apps exist, response could blow context window.
Destructive operations lack confirmation or dry-run support. stop_app with 'force' flag can kill applications, no mention of confirmation step or dry-run mode to prevent accidents.
send_http_request accepts free-form HTTP method as string, not enum. Should constrain to ['GET', 'POST', 'PUT', 'DELETE', 'PATCH', 'HEAD', 'OPTIONS'] to prevent hallucinated methods.
Response field naming inconsistency. Tools return app_id and app_name but documentation doesn't specify exact field names, forcing LLM to infer structure from examples. Tools accepting app_id might conflict with return names.
Tool composition gaps. capture_screen requires app_id but launch_app returns app_id, no guarantee next reference will have it. If agent context is lost between calls, it cannot resume.