Loading ToolBench
Exposes OKR (Objectives and Key Results) management service via the Model Context Protocol for consumption by API Agents, with Stytch B2B authentication and RBAC support
This OKR Manager MCP server presents a coherent domain (objective/key-result management) with 6 tools covering CRUD operations. However, it has significant gaps in definition quality. Tool names follow verb_noun convention correctly (listObjectives, addObjective, deleteObjective, etc.), but descriptions are minimal (10-30 chars), parameters lack descriptions beyond the type name, and output schemas are not documented. The server appears to be HTTP-mounted via Hono/Workers (not STDIO), which is good for protocol readiness, but the tool definitions themselves are sparse. No error handling guidance, no pagination for list operations, and no input validation constraints are evident. The code shows OAuth/RBAC integration via Stytch, but security patterns are not reflected in the tool definitions themselves.
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
All tool descriptions are trivially short (10-30 chars). 'View all objectives and key results for the organization' is the longest; most others are 1-2 sentences with no context for WHEN to use them or WHAT they return. LLMs rely on descriptions to select tools, these fail the 10-1024 character guideline.
Parameter descriptions are missing or non-existent. 'objectiveText' has a description ('The text of the objective to add'), but 'okrID' and 'keyResultID' lack any explanation of what these IDs are, whether they are UUIDs or system-generated, or how to obtain them. This violates the requirement that every parameter have a description.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | C | 64 | - | v1 |
listObjectives returns no documented output schema. The source shows a response is sent (via formatResponse), but the structure of 'newState' (Objective[]) is never documented in the tool definition. Without schema documentation, LLMs cannot plan downstream operations or extract required fields.
No error handling guidance. Tools lack documentation on what happens when an okrID does not exist, when the user lacks permissions, or when an add operation fails. Errors are likely caught by the RBAC layer (stytchRBACEnforcement), but this is not documented in the tool definition itself, so agents have no recovery path.
No confirmation or dry-run support for destructive operations. deleteObjective and deleteKeyResult are marked as DESTRUCTIVE in risk, but the tool definitions offer no dry-run, confirmation step, or undo mechanism. Agents making mistakes have no safety net.
setKeyResultAttainment uses an integer attainment parameter with min/max constraints (0-100), which is well-defined in the schema. However, the description does not explain what attainment means semantically (is it a percentage? a raw score?), or what side effects occur (does it trigger notifications? update timestamps?). This is ambiguous.
No documentation of permissions or scope requirements. The source shows RBAC enforcement via stytchRBACEnforcement and parameters like 'resource_id' and 'action', but the tool definitions do not declare what permissions agents need (e.g., 'read:objective', 'write:objective'). Agents cannot self-document their least-privilege scope.