Loading ToolBench
Model Context Protocol server for managing Objectives and Key Results with Stytch B2B authentication and RBAC
The OKR Manager MCP exposes 6 tools with basic structure but significant gaps in descriptions, parameter documentation, and error handling guidance. Tool names follow verb_noun convention (listObjectives, addObjective, etc.), which is good. However, descriptions are minimal (ranging from 60-110 chars), parameter descriptions are sparse or missing for many inputs, and output schemas are undocumented. The server lacks error recovery guidance, permission documentation, and idempotency markers. Schemas visible but inconsistently described. No sample shows actual error handling paths or field-level documentation for returned objectives. The formatResponse method returns generic JSON serialization without structured field documentation.
Add a new key result to a specific objective
Add a new top-level objective for the organization
Remove a key result from a specific objective
Remove an existing top-level objective from the organization
View all objectives and key results for the organization
Set the attainment value for a specific key result in a specific objective
Output schemas completely undocumented. All 6 tools return objectives via formatResponse() which serializes to generic JSON, but no tool description or response schema specifies what fields (id, name, keyResults, attainment, etc.) the client should expect. LLMs cannot reason about downstream chaining or data extraction without this.
Destructive operations (deleteObjective, deleteKeyResult) marked with DESTRUCTIVE risk but lack confirmation/dry-run pattern. No error recovery guidance ('Resource not found' errors have no hints). Pattern:confirmation-request and pattern:recovery-guide not implemented.
Tool descriptions are too brief (40-68 chars for most) and lack WHEN/WHY guidance. Pattern:tool-description specifies 10 - 1024 chars optimal range (typical A+ tools: 50-200 chars). Current descriptions state WHAT but not WHEN to call, prerequisites, or return value structure. Examples: 'Add a new key result' is vague about what constitutes a valid key result.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 56 | - | v1 |
No documentation of parameter dependencies or constraints beyond basic types. Pattern:constrained-input and pattern:param-relationships not fully realized. For example: can an objective have unlimited key results? What's the max text length for objectiveText? No validation rules documented, forcing LLM to guess.
No error handling or recovery guidance in tool descriptions. Pattern:recovery-guide requires error responses to guide next steps. Code shows formatResponse() returns success paths only; no error method visible. LLMs receive no hints on what to do if objectives API fails, okrID is invalid, or permission denied.
Permission requirements not declared in tool descriptions. Pattern:scope-declaration specifies tools should declare required permissions (e.g., 'read:objective', 'write:keyresult'). Code shows stytchRBACEnforcement() wrapping tools, but tool descriptions do not mention what roles/permissions are required. LLMs cannot reason about permission errors.
Idempotency not declared. Pattern:idempotent-operation requires tools to specify idempotency so agents can safely retry. addObjective, addKeyResult, setKeyResultAttainment should declare whether repeated calls with same input produce duplicate records or are safely idempotent.
Pagination not addressed. Pattern:paginated-result requires list operations to support pagination when results could be large. listObjectives returns all objectives with no limit, offset, or cursor. Large org could return thousands of objectives, blowing context window. No limit parameter, no next_cursor, no total count.