Loading ToolBench
Automatic MCP Server & OpenAI Tools Bridge for apcore
apcore-mcp exhibits mixed quality across 6 tools. Three tools (__apcore_approval_check, convert_temperature, word_count) have complete input schemas with proper type definitions and clear parameter descriptions. However, the server suffers from critical naming and description issues: __apcore_approval_check violates verb_noun conventions and uses an underscore prefix suggesting internal/private scope; descriptions vary widely in completeness (word_count is 100 chars, convert_temperature is 71 chars, but Greeting and MathCalc lack sufficient detail for LLM selection without reading implementations). The greeting, MathCalc, and TextEcho tools are example/demo code rather than production fixtures, suggesting this is a template/reference implementation. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present despite HTTP transport. No output schemas are documented, LLMs cannot predict response structure. Per-tool analysis reveals average naming quality but weak description consistency and missing error guidance patterns.
Generate a personalized greeting in different styles
Perform basic arithmetic: add, subtract, multiply, or divide
Echo input text back, optionally converting to uppercase
Poll the status of a pending approval request. Returns {approval_id, status, reason}. status is 'pending', 'approved', or 'rejected'. When 'approved', retry the original tool call with _meta.approvalId set to this approval_id.
Convert temperature between Celsius, Fahrenheit, and Kelvin.
Count words, characters, and lines in a text string.
Tool naming violates verb_noun convention and uses leading underscore. '__apcore_approval_check' suggests internal/private status; LLMs may avoid calling it or misinterpret intent. Should be 'check_approval' or 'get_approval_status' with no underscore prefix.
No output schemas documented for any tool. LLMs cannot predict return structure (e.g., does convert_temperature return {celsius: float, fahrenheit: float, kelvin: float} or {value: float, unit: string}?). This forces LLMs to guess downstream field names and risks failed chaining.
Description lengths vary widely (45 - 100 chars) with some tools (Greeting, MathCalc, TextEcho) at or below the 50-char minimum for LLM selection clarity. 'Perform basic arithmetic: add, subtract, multiply, or divide' (60 chars) is terse; missing guidance on when to use MathCalc vs a calculator tool.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No tool annotations (destructiveHint, readOnlyHint, idempotentHint) despite HTTP transport and explicit 'Risk: READ_ONLY' notation in tool metadata. These hints should be serialized in tool schema for MCP 2026-07-28 compliance.
Tools Greeting, MathCalc, TextEcho appear to be example/demo code (examples/ directory). Production assessment unclear, these may not be stable fixtures. Naming conventions differ (capitalized Greeting vs lowercase convert_temperature).
No error handling guidance in any tool description. E.g., convert_temperature does not specify what happens if from_unit or to_unit is invalid (e.g., 'rankine' or typo 'celcius'). No recovery hints provided.
Enum constraints for convert_temperature (celsius, fahrenheit, kelvin) and MathCalc (add, sub, mul, div) and Greeting (friendly, formal, pirate) are present in descriptions but not formalized in JSON Schema enum arrays. LLMs must parse text constraints rather than reading structured enum.