Loading ToolBench
MCP server implementation in Go providing Slack and GitHub integrations
This MCP server exhibits significant definition quality gaps. While 4 tools are registered with basic descriptions, the implementation lacks proper input schemas, comprehensive parameter documentation, and structured output schemas. Tool names lack action-verb clarity, parameter descriptions are minimal, and there is no evidence of error handling guidance or output schema documentation. The server appears to be a thin HTTP wrapper around Slack and GitHub APIs without MCP-specific optimization for LLM agent interaction.
Connect to an MCP server with authentication
List contexts (channels/repositories) available on the connected server
Receive messages from a context (channel history for Slack, issue comments for GitHub)
Send a message to a context (channel for Slack, issue comment for GitHub)
The 'config' parameter in Connect is typed as 'object' with no property definitions, minProperties, or required field specification. Schema score must not exceed 30 for parameters lacking proper type constraints.
Parameter descriptions lack actionable constraint information. 'server' param described only as 'Name of the MCP server (slack or github)', should enumerate allowed values as an enum constraint or explicit 'must be one of: slack, github'. Without formal enums, LLMs hallucinate invalid values.
No output schemas documented for any tool. LLMs cannot determine what fields to expect or plan downstream calls. ListContexts returns an array, SendMessage returns 'OK' (string), ReceiveMessage returns message objects with Time/User/Text fields, Connect returns void, none of this is formalized in schema definitions.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 32 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Connect tool exposes credentials via parameters. The 'config' parameter accepts a map that contains 'token' (authentication secret). This violates secret-injection pattern, credentials should never be tool parameters; they should be injected server-side via environment variables or vault. Agent traces will log this parameter, leaking credentials.
No error handling guidance. Code shows bare HTTP errors ('Unknown server', 'Missing context or message', 'Invalid input') with no recovery hints. Pattern requires: 'User not found. Try search_users() with a partial name.' Instead, LLMs receive raw error strings with no guidance on what to do next.
ReceiveMessage lacks pagination limits. Code iterates over a channel receiving messages indefinitely until the channel closes. No limit parameter, no page/offset, no total count. Large message histories will blow the context window; no way for the LLM to fetch 'last 10 messages' or 'messages since timestamp'.
Parameter naming is inconsistent with pattern guidance. 'context' parameter accepted by SendMessage and ReceiveMessage is ambiguous, does it mean channel, thread, issue, or repository? For Slack it's a channel name; for GitHub it's 'owner/repo'. Descriptions hint at this, but parameter names should disambiguate: 'channel_name', 'repo_identifier', or separate tools.
Descriptions are under 100 characters for most tools and lack WHEN-to-use guidance. 'Send a message to a context' (52 chars) is barely adequate. Best practice is 50-200 chars with explicit use cases: 'Send a message to a Slack channel or post a comment on a GitHub issue. Specify the target with channel name (Slack) or owner/repo (GitHub).'