Loading ToolBench
MCP server for ChatGPT agent with software development focus
This server defines 3 tools with basic schemas and descriptions, but has significant gaps in parameter documentation, output schema clarity, and error handling guidance. Tool names follow verb_noun convention, but parameter descriptions are minimal or missing. The 'chat_with_agent' tool has a context parameter with no type constraint or format guidance. No tool description explains prerequisites, return structure, or when to call it instead of alternatives. Error responses are raw exception messages without recovery guidance. This is typical of an early-stage MCP implementation.
Chat with the GPT agent focused on software development and architecture
Get current agent status and conversation info
Reset the conversation history with the agent
Parameter descriptions are missing or minimal. 'message' in chat_with_agent has a description, but 'context' is vague ('Optional context about your development environment or project') without format guidance, length limits, or examples of what should be included. LLMs cannot reason about what constitutes valid context.
No output schemas documented. The server returns tool responses as {content: [{type: 'text', text: ...}]} but does not document what fields agents should expect. For 'get_agent_status', the caller has no way to know if the response includes conversation_count, model_name, or other fields without making a test call.
Error handling provides no recovery guidance. catch blocks return raw error messages like 'Error: Unknown tool: X' or 'OpenAI API Error: <message>'. Per the recovery-guide pattern, errors should tell the LLM what to do next: 'Authentication failed. Check your OpenAI API key in the .env file' or 'Rate limit exceeded. Retry in 60 seconds.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 42 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | 2024-11-05+ | v1 |
Tool descriptions lack specificity on when to use each tool. 'Chat with the GPT agent...' does not explain prerequisites (e.g. must initialize agent first?), what types of questions it handles, or whether it maintains conversation state. A better description: 'Send a message to the GPT agent to get architecture or debugging advice. Conversation history is maintained across calls. Context parameter enriches the response with project details.'
reset_conversation has an empty inputSchema (no properties defined, no required array). Per the constrained-input pattern, even stateless tools should document their inputs clearly. If reset_conversation takes no arguments, the description should state this: 'Clears the conversation history. No parameters required.'
No indication of tool idempotency or state-modification consequences. 'reset_conversation' modifies internal state (clears conversationHistory) but the description does not warn that this is irreversible or that subsequent chat_with_agent calls will start with an empty history. Agents need to know which calls are safe to retry and which have side effects.
API key and OpenAI configuration exposed as environment variables without documented secret-injection best practices. While the code correctly avoids placing API keys in tool parameters, the .env file approach is implicit and undocumented. Users may accidentally commit secrets to version control.