Loading ToolBench
A LangGPT prompt assistant for generating structured prompts using the LangGPT framework with web frontend
This server has moderate definition quality with visible schemas and descriptions, but suffers from several critical gaps. All 4 tools have input schemas present in the source code and descriptions in the range of 60-110 characters, which meets baseline expectations. However, parameter descriptions are sparse or missing, tool purposes lack actionable context, and there is no documented output schema structure. The tools follow a reasonable naming convention (verb-noun pattern with underscores), but descriptions are generic and do not explain WHEN to use each tool vs. alternatives or what specific outcomes to expect. No error handling guidance, no output structure documentation, and no indication of whether operations are idempotent or have side effects. The server also conflates frontend mock implementations with actual MCP tool definitions, making it unclear whether the backend server.ts file contains the real implementation.
Analyze an existing prompt for structure, effectiveness, and improvement opportunities
Generate a structured LangGPT-style prompt based on role type, domain, and specific task
Get a list of available predefined LangGPT roles
Optimize an existing prompt based on specified goals and constraints
Parameter descriptions are missing or extremely sparse. For example, 'role_type' in generate_langgpt_prompt is described only as 'Type of role (assistant, expert, tutor, consultant, etc.)', this does not explain format constraints, accepted values beyond the parenthetical hint, or what happens if an invalid role is passed. Parameters like 'style', 'requirements', 'constraints', and 'additional_skills' lack any description at all.
Tool descriptions lack context about WHEN to use each tool and what distinguishes it from similar tools. For example, 'analyze_prompt' and 'optimize_prompt' both operate on prompts but it is not clear when to call analyze vs optimize. According to baselines, descriptions should be 50-200 characters and explicitly state purpose, prerequisites, and outcomes. Current descriptions are 60-110 characters but do not follow this structure.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 51 | - | v1 |
No output schema is documented anywhere in the source code. The rubric requires that tools document their return type so LLMs know what fields to expect. Without this, agents cannot plan downstream tool calls or extract the right data from responses. The mock implementations return unstructured objects (e.g., 'mockResult' with no schema definition).
Error handling provides no recovery guidance. The frontend-server.js catches errors and returns '{ success: false, error: error.message }' but does not classify errors as retryable/user-fixable/fatal, do not suggest next steps (e.g., 'Try search_users() with a partial name'), and do not return the invalid value or constraint violated. This leaves agents unable to self-correct.
Enum constraints are incomplete or missing. For example, 'analysis_type' in analyze_prompt declares an enum of ['effectiveness', 'structure', 'clarity', 'completeness'] but other parameters like 'role_type' in generate_langgpt_prompt are free-form strings with only a parenthetical hint of examples. Free-form strings invite hallucinated values; enums are self-documenting.
The 'role_type' parameter accepts free-form strings and lacks a formal enum constraint. This violates the pattern:constrained-input rule that known sets of values must be declared as enums to prevent hallucinated values. The parenthetical hint '(assistant, expert, tutor, consultant, etc.)' does not function as a machine-parseable constraint.
No idempotency or side-effect declarations. Tools do not indicate whether they are read-only, destructive, or idempotent. The rubric requires tool descriptions to state 'If the tool modifies state (creates, updates, deletes, sends), the description must say so.' Current descriptions do not clarify whether 'generate_langgpt_prompt' creates persistent records or returns ephemeral suggestions.
The server source code is split between frontend-server.js (which contains API routes and mock implementations) and src/server/langgpt-server.ts (not fully shown). Tool definitions appear in both files, creating ambiguity about which is the real MCP server implementation. The rubric penalizes inferred tool definitions, if actual tool registrations are hidden in unseen server.ts code, per-tool scores should be capped at 50.