Loading ToolBench
DCA discipline tracker — read your plans, events, and discipline data via your AI agent. No advice. No predictions. No execution. All data is your own; the agent only sees what your API key authorizes.
Server has 4 tools with clear verb-noun naming (health_check, get_plans, get_plan, get_discipline). All tools have descriptions (avg ~150 chars, within baseline 34-392 range). Input schemas are present but minimal: health_check and get_discipline have empty schemas ({}), while get_plans and get_plan have single boolean/string parameters with descriptions. No output schemas documented. All tools are READ_ONLY, reducing error handling complexity. Missing: parameter constraints (enums), output schema documentation, and error recovery guidance. Tool composition is sound (each does one thing), but responses lack pagination/limit guidance despite potential for large result sets.
Returns the user's overall DCA discipline summary: score, current streak, cycl points, and tier. One row per user — discipline metrics are maintained by background processes elsewhere in the app; this tool just reads the current state.
Returns a single DCA plan by its plan_id. Typically called after get_plans to retrieve full details for a specific plan. Returns { plan: null } if no plan with that id exists for the authenticated user.
Returns the user's DCA plans. By default returns only active plans. Each plan includes the token (symbol, name, type), recurring USD amount, frequency, and start date. Use this to understand what positions the user is currently accumulating into.
Returns OK if the Da Cycl MCP server is reachable. Use this to verify your connection is working.
Output schemas not documented. LLMs cannot plan downstream calls or extract fields without knowing response structure (e.g., what fields does a plan object contain? Is there pagination?).
Empty input schemas for health_check and get_discipline ({}) lack parameter descriptions. While these tools take no params, the schema should be explicit (type: 'object', properties: {}, required: []).
No pagination or result-limit guidance. get_plans could return hundreds of plans; description should state max results and offer offset/limit parameters to prevent context window exhaustion.
No error recovery guidance. Descriptions do not explain what to do if a plan_id is invalid or user has no plans. LLMs need actionable error hints (e.g., 'If plan not found, call get_plans() to list available plans').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Parameter 'active_only' in get_plans lacks enum constraint or explicit true/false documentation. Description says 'If true (default)' but schema does not enforce boolean type or default value.