Loading ToolBench
MCP server for interacting with Lenses HQ, providing tools for governance approvals, environments, Kafka connectors, consumer groups, SQL operations, SQL processors, and topics
The server defines 8 tools with reasonable naming (verb_noun convention), mostly complete parameter descriptions, and documented input schemas. Tool names are action-oriented (request_, list_, get_, create_, check_). Parameter descriptions are present and non-trivial (average ~80 chars). However, output schemas are NOT documented, the rubric requires this for 100% of A+ tools (pattern:tool), and the absence is a critical gap. Error handling is not visible in the code excerpts. Tool descriptions vary in completeness; some are excellent (request_topic_creation: 120+ chars with context on when/why to use), others are minimal (get_approval_request, list_connected_environments: ~30 chars). No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, which would improve LLM understanding of side effects. Risk classifications are present but not surfaced in descriptions. The server does not expose secrets as parameters (good security practice), and environment-based config is used.
Checks the health status of a Lenses environment.
Creates a new Lenses environment.
Get the details of an approval request.
Retrieves a single Lenses environment by name.
List topic-creation approval requests. Note: a caller without the governance:ListRequests permission gets an empty page, not an error.
List all connected environments
Output schemas are not documented. Tools like list_approval_requests and list_environments lack any description of response structure (fields, types, pagination details). LLMs cannot plan downstream operations without knowing what data to expect.
Minimal descriptions on several tools. get_approval_request, list_environments, get_environment, check_environment_health, and list_connected_environments have descriptions under 50 characters. At minimum they should explain WHAT the tool does, WHEN to use it, and any prerequisites (e.g., does caller need governance:ListRequests?).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 68 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Lists all Lenses environments.
Submit a topic-creation approval request (the governed alternative to create_topic). Use this when the caller lacks the kafka:CreateTopic permission and topic creation must go through governance approval. The topic is only created once a governance admin approves the request in Lenses.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are visible. This is a CURRENT pattern in spec 2026-07-28. request_topic_creation (WRITE risk) and create_environment (WRITE risk) should be marked destructiveHint=true so LLMs understand these are state-altering and require confirmation before execution.
Pagination not documented for list tools. list_approval_requests and list_environments accept page/page_size parameters but do NOT document the response structure (total count, remaining items, next_cursor, or how to detect end of results). LLMs cannot reliably paginate without knowing the response shape.
No error recovery guidance visible. If an approval request is not found, or the caller lacks permissions, there is no documented error message or recovery path (e.g., 'Try list_approval_requests() to see available requests').
Parameter validation constraints not fully specified. Numeric parameters (partitions, replication, records_size, data_produced_per_day, consumers in request_topic_creation; page, page_size in list_approval_requests) lack min/max bounds. LLMs may pass invalid values (e.g., page=-1, replication=1000) without clear feedback.
Enum constraints not enforced in descriptions for known-value fields. sort_field and sort_order in list_approval_requests, sort_order in list_approval_requests, and tier in create_environment are constrained but descriptions do not emphasize valid values strongly enough for LLM inference.