Loading ToolBench
MCP server for managing insights and projects with full-text search, versioning, and OAuth2/OIDC authentication
Starlogz has well-structured tool names (verb_noun pattern: whoami, project_ensure, insight_write, etc.) and comprehensive descriptions (100-300 chars, well above the 34-char minimum). However, ALL 12 tools have severely incomplete input schemas. Most tools show only a 'telemetry' object with a 'context' string parameter in their schema, but lack the actual domain parameters (project, content, key, tags, category, source, expected_revision, etc.) that the descriptions reference. This is a critical gap: the schema does not match the description. For example, insight_write's description mentions 'project', 'key', 'expected_revision', 'category', 'source', and 'tags', but the visible schema only shows 'telemetry'. This suggests either incomplete schema extraction or that parameters are defined elsewhere (not visible in the provided code). Per the hard rules, if schemas are not visible/complete, schema scores must be 0. Additionally, no output schemas are documented, and error handling guidance is absent. Tool descriptions are strong (50-200 chars range), but parameter descriptions within schemas are minimal.
Soft-deletes an insight by ID. Supply expected_revision for optimistic concurrency. The insight no longer appears in list or search results.
Retrieves one insight by ID or key with bounded outgoing links and backlinks.
Lists immutable revisions for an insight, newest first, with opaque cursor continuation. Includes soft-deleted insights.
Lists live insights in a project, newest first. Optionally filter by a single tag or continue with an opaque cursor.
Returns tags for a project ordered by usage frequency. Call before writing tags to avoid fragmentation.
Restores an insight from an immutable revision as a new live revision. Requires optimistic concurrency.
Input schemas incomplete or mismatched with descriptions. All 12 tools show only 'telemetry' parameter in visible schema, but descriptions reference domain parameters (project, content, key, tags, category, source, expected_revision, etc.) that are not visible in the schema.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., insight_id, project_id, revision) without knowing the response structure. Baseline: 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 45 | 2026-07-28+ | v2 |
Full-text search over live insights in a project. Returns bounded snippets and metadata; use insight_get for full content. Use detail=brief for progressive discovery and exclude_ids to omit insights already surfaced in the current recall. query_mode=all requires every term. query_mode=web supports explicit OR, quoted phrases, and -excluded terms. tag_mode controls whether all or any supplied tags must match. Results are ordered by relevance and support opaque cursor continuation.
Updates the content and/or tags of an existing insight. Supply only the fields you want to change and expected_revision for optimistic concurrency.
Writes an insight to a project. Auto-creates the project if needed. Supply a key to upsert by stable identifier and expected_revision for optimistic concurrency. Requires category and source.
Creates a project if it does not exist and returns it. Use when you need a custom display name; insight_write auto-creates projects.
Lists all projects in the caller's personal org.
Returns identity and token scopes. Call this first to verify access.
No error handling guidance. Tools do not indicate what errors are retryable, user-fixable, or fatal. No recovery suggestions (e.g., 'If project not found, call project_ensure first'). Per pattern:recovery-guide, errors must tell the LLM what to do next.
Destructive operations (insight_delete, insight_restore) lack confirmation or dry-run support. Agents can permanently delete insights without a safety gate. Per pattern:confirmation-request, irreversible operations should support confirmation.
Telemetry parameter required on all tools. Every tool mandates a 'telemetry.context' parameter (15-25 words explaining why the call fits the user's goal). This is non-standard and adds friction; most production tools do not require agents to provide intent metadata on every call. Consider moving telemetry to server-side logging or optional metadata.