Loading ToolBench
Universal agent skill and daily learning orchestrator for job-role learners. Provides MCP tools for onboarding, planning, research, email delivery, progress logging, and skill progression tracking.
This MCP server has severe definition quality issues across all dimensions. Tools are minimally defined with no input schemas visible in the source code, descriptions are generic without LLM-optimization guidance, and parameter constraints are absent. The server.js file shows tool names and basic descriptions but NO formal JSON Schema definitions for any input parameters. This violates the core requirement that tools must be self-documenting for LLM selection and execution. While the tool set (12 tools) is coherent for an educational orchestration platform, the lack of structured input schemas, parameter type definitions, and comprehensive error handling makes this unsuitable for production agent use.
Create role-specific official course, free learning, and newsletter source pack.
Create the compact token-conscious execution harness.
Log learner progress evidence.
Run EduOrchestrate onboarding.
Generate a 30-day-minimum EduOrchestrate plan.
Run the prebuilt program that writes the role, skill, GitHub-style progression, and terminal card artifacts.
Recommend the next skill after the current plan window.
NO FORMAL INPUT SCHEMAS. Tools declare parameters in the param-list but provide no JSON Schema definitions with types, constraints, or format specifications. The server.js shows inline parameter objects (e.g., 'mode' with description and optional flag) but these are NOT JSON Schema compliant and lack critical metadata like type, enum, minimum/maximum, pattern, etc. This forces LLMs to guess parameter semantics and violates pattern:tool and pattern:constrained-input.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Create a sourced trend research digest for a day or topic.
Send or dry-run today's learning email.
Show current plan and momentum status.
Run the prebuilt program that writes the exact SVG terminal-card artifact.
Summarize a learning week.
GENERIC DESCRIPTIONS UNDER 50 CHARS. Most tool descriptions are vague and lack LLM-optimization. Examples: 'Run EduOrchestrate onboarding.' (32 chars), 'Show current plan and momentum status.' (38 chars), 'Recommend the next skill after the current plan window.' (54 chars, barely sufficient). Descriptions do not answer WHEN to use each tool, what it modifies, what it returns, or how it differs from similar tools.
PARAMETERS LACK TYPE DEFINITIONS. Parameters like 'mode', 'day', 'dryRun', 'completed', and 'evidence' are listed with descriptions and optional flags but have NO explicit 'type' field in a JSON Schema structure. The server.js shows inline objects like {type: 'string', description: '...', optional: true}, but these are not integrated into the MCP tool definition schema. This violates the JSON Schema requirement and prevents LLMs from validating inputs before calling tools.
NO PARAMETER CONSTRAINTS OR ENUMS. Parameters like 'mode' (accepts 'daily'?) and 'day' (range?) have no declared enums, minimum/maximum, or format restrictions. The description for 'mode' says '(default: daily)' but does not declare valid values or whether other modes exist. This invites hallucinated invalid values from LLMs and violates pattern:constrained-input, which mandates enums or regex patterns for known-set parameters.
OUTPUT SCHEMAS NOT DOCUMENTED. Tools return responses wrapped in {type: 'text', text: JSON.stringify(...)}, but no schema documents what fields the JSON contains, their types, or structure. LLMs cannot plan downstream calls or extract relevant data when the return type is opaque. Pattern:tool and pattern:response-shaper require structured output documentation.
NO ERROR HANDLING GUIDANCE. Tool implementations in server.js use spawnSync() with no error classification, recovery hints, or actionable messages. If a subprocess fails, LLMs receive raw stderr or a generic error. Pattern:recovery-guide and pattern:error-classification require categorizing errors as retryable vs user-fixable and providing next-step guidance (e.g., 'Try search_users() first').
IRREVERSIBLE OPERATIONS WITHOUT CONFIRMATION. Tools like 'eduorchestrate_send_today' (sends emails), 'eduorchestrate_log_progress', 'eduorchestrate_progress_card', and 'eduorchestrate_terminal_card' (write artifacts) modify state or send external messages without a dry-run safety net or confirmation step. The 'dryRun' parameter on send_today defaults to true (preview mode), but other write operations lack this guard. Pattern:confirmation-request mandates dry-run or confirmation for destructive/irreversible ops.
TOOL NAMES LACK ACTION VERBS. Names like 'eduorchestrate_onboard', 'eduorchestrate_harness', 'eduorchestrate_courses', 'eduorchestrate_progress_card', 'eduorchestrate_terminal_card', 'eduorchestrate_weekly_summary', 'eduorchestrate_status' are noun-heavy and do not immediately convey the ACTION (create, get, generate, send, log, etc.). LLMs must read descriptions to infer intent. Pattern:tool recommends verb_noun naming (e.g., 'generate_plan_30day' vs 'eduorchestrate_plan30'). Only 'log_progress', 'send_today', 'recommend_next' have clear verbs.
PARAMETER DESCRIPTIONS OMIT CONSTRAINTS AND EXAMPLES. The 'days' parameter in 'eduorchestrate_plan30' says 'Number of planning days (minimum 30, default 30)' but is declared as a string/number with optional flag, no formal min/max in schema. The 'topic' in 'eduorchestrate_research' lacks format or length guidance. Per pattern:tool-description, parameter descriptions must state format, range, and allowed values explicitly so LLMs can self-correct without trial-and-error.
NO PAGINATION OR RESULT LIMITS DOCUMENTED. Tools like 'eduorchestrate_courses' and 'eduorchestrate_research' likely return lists, but no parameters control pagination (limit, offset, page_size, cursor) and no output schema documents result count or next_cursor. If responses are large, they blow the context window. Pattern:paginated-result and pattern:mxe/enforce-result-limits require explicit pagination and result capping with defaults (e.g., limit=20).