Loading ToolBench

Reading the current corpus…

better-chatbot MCP server · F · ToolBench

← Browse

better-chatbot

github.com/cgoinglove/better-chatbot

A Next.js-based chatbot application with support for multiple AI providers, MCP servers, workflows, and agents

2025-06-18+STDIO9 tools

41/100

Definition Quality33

Protocol Readiness15

Supportability72

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · detected: Dynamic Client Registration

Deprecated protocol patterns detected

Summary

This is a Next.js web application, not an MCP server. The codebase contains tool definitions (CreatePieChart, CreateBarChart, CreateLineChart, CreateTable, WebSearch, WebContent, Http, JavascriptExecution, PythonExecution) but they are implemented as internal AI SDK tools for a chat UI, not as an MCP server exposing tools via the Model Context Protocol. The package.json lists '@modelcontextprotocol/sdk' as a dependency, but inspection of the provided source code shows no MCP server implementation, no tool registration via MCP's CallToolRequest/ToolList patterns, and no stdio/HTTP transport setup. The tool definitions exist in 'src/lib/ai/tools.ts' but appear to be Vercel AI SDK tools, not MCP tools. For the tools that ARE defined, descriptions are present but generic/vague, input schemas are partially visible for only 2 of 9 tools (JavascriptExecution and PythonExecution show explicit 'code' parameter), and most lack comprehensive parameter documentation. No error handling guidance is visible. Output schemas are undocumented. The architecture is fundamentally misaligned with MCP server patterns, this is a chatbot UI, not an MCP server.

Tools (9)

CreateBarChartread only37/100

Create a bar chart visualization

CreateLineChartread only37/100

Create a line chart visualization

CreatePieChartread only37/100

Create a pie chart visualization

CreateTableread only32/100

Create a table visualization

Httpwrite27/100

Make HTTP requests to external APIs

JavascriptExecutionread only50/100

Write and execute JavaScript code in the user's browser. When users request code examples, use this tool to execute the code and show console.log results rather than just providing static code. For data generation or random operations, executing code to generate actual data is more accurate than manually creating examples. This ensures users see real working results and can trust the output is genuinely generated by the code logic.

PythonExecutionread only50/100

Execute Python code in the user's browser via Pyodide. Use pyodide.http.open_url for HTTP(S) downloads; CORS must allow the app origin.

WebContentread only

Issues (7)

CRITICALtool (pattern:tool) ↗

No input schemas visible for 7 of 9 tools (CreatePieChart, CreateBarChart, CreateLineChart, CreateTable, WebSearch, WebContent, Http).

CreatePieChartCreateBarChartCreateLineChartCreateTableWebSearchWebContentHttp

HIGHtool-description (pattern:tool-description) ↗

Descriptions are generic and under 50 characters for most tools (e.g., 'Create a pie chart visualization', 'Search the web for information'). These lack context on WHEN to use, WHAT it returns, or any prerequisites.

CreatePieChartCreateBarChartCreateLineChartCreateTableWebSearchWebContentHttp

CRITICALtool (pattern:tool) ↗

This is a Next.js web application, NOT an MCP server. No evidence of MCP protocol implementation (no ToolListResponse, no CallToolRequest handling, no stdio/HTTP MCP transport). The '@modelcontextprotocol/sdk' dependency is listed but not used for server functionality. Tools are internal Vercel AI SDK integrations, not MCP tools.

Recommendations

This submission is fundamentally a web chatbot, not an MCP server. To be an MCP server, it must expose tools via the Model Context Protocol using stdio, SSE, or HTTP transport. If the intention is to evaluate the chatbot's internal tools, clarify that context.
For each tool, document the complete input JSON Schema with type, required fields, and per-parameter descriptions (not just the tool description).
Rewrite tool descriptions to follow the pattern: '[Verb] [object/resource]. Use when [condition]. Returns [data structure summary].' Example: 'Create a pie chart from numeric data. Use when visualizing proportional breakdown of categories. Returns a chart URL and metadata (title, labels, values).'
Document output schemas for every tool. Specify field names, types, and constraints. If a tool returns a chart, specify what fields identify it (id, url, title, etc.) so downstream tools can reference it.
Add error handling guidance. For WebSearch and WebContent, document: 'If no results found, suggest alternative search terms. If page fetch fails, return available cache or suggest using a different source.'
Rename 'Http' to a verb_noun pair that conveys the action, e.g., 'send_http_request' or 'fetch_api_endpoint'. Add required parameters: method (GET|POST|PUT|DELETE|PATCH), url, and optional headers, body, timeout.
Add per-parameter descriptions and type constraints to JavascriptExecution and PythonExecution. Document: code length limit, allowed APIs/modules, timeout, and security sandbox constraints.

Score history

Overall score trend

↓ 11 points across a rubric change (v1 → v2)

41/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	F	41	2025-06-18+	v2
2026-03-09	D	52	1.25.1+	v1