Loading ToolBench
Symbiont JavaScript SDK - Monorepo containing MCP client integration, agent management, policy management, secrets management, and core functionality for the Symbiont runtime
This is an MCP server wrapping a Tool Review API (submitForReview, listReviewSessions, etc.). Schema documentation is present but inconsistent. Tool descriptions are brief but functional. Parameter schemas are defined as objects but lack granularity, many properties inside nested objects have descriptions, but the structure is verbose and not optimized for agent reasoning. Error handling and output schemas are not visible in the provided code samples. The server appears to be a wrapper around an external API rather than a bespoke agent tool set, which limits opportunities for optimization. Most tools are READ_ONLY operations, which is safer but reduces the diversity of agent actions.
Download signed tool package (GET /signing/{reviewId}/download)
Get security analysis by analysis ID (GET /analysis/{analysisId})
Get the current review queue (GET /review/queue)
Get a specific review session by ID (GET /sessions/{reviewId})
Get signing status for a review (GET /signing/{reviewId})
Get Tool Review API statistics (GET /stats)
List review sessions with pagination and filtering (GET /sessions)
Nested object parameters lack explicit type clarity. 'submission', 'decision', and 'params' are objects with properties, but the JSON Schema presentation buries required/optional distinctions and does not use additionalProperties or discriminators to guide LLM input generation.
Tool descriptions are minimal (55 - 70 chars on average). They state WHAT but not WHEN to use or dependencies. E.g., 'Get a specific review session by ID' does not explain whether to call listReviewSessions first or how the ID relates to the submission process.
No output schemas documented. Tool responses are inferred from endpoint names (e.g., getReviewSession returns a review session object) but the actual response structure, field names, and types are not specified. LLMs cannot plan downstream tool calls without knowing what fields to extract.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Submit a review decision for a tool (POST /review/{reviewId}/decision)
Submit a tool for review via the Tool Review API (POST /sessions)
No error handling guidance visible. Tools do not return actionable recovery hints (e.g., 'Review not found. Try listReviewSessions() first' or 'Invalid priority, must be low|normal|high|urgent'). Error responses likely propagate raw API errors.
getReviewQueue accepts no input parameters. Tools that list/queue data should accept pagination (page, limit, offset) and sorting to prevent context window explosion if queue is large. Current design returns all items.
Enum constraints in parameters (e.g., priority: [low, normal, high, urgent] in submitForReview; decision: [approved, rejected, escalated] in submitDecision) are correct, but descriptions do not include the enum list as backup documentation. LLMs sometimes ignore schema enums and require textual backup.
Parameter naming inconsistency: reviewId vs analysisId. Both are opaque string IDs, but the inconsistent naming (camelCase reviewId vs analysisId) signals they are different types even though they may serve the same lookup purpose. Consider consistent ID naming (e.g., resource_id with a type field).