This server has severe definition quality gaps. Of 17 tools, only 2 have visible input schemas (draft_manifest, create_context_from_draft). Most tools lack parameter documentation, descriptions are generic and often under 20 characters, and no output schemas are documented. The codebase shows tool definitions scattered across multiple files with inconsistent documentation patterns. File references point to chat-tools.ts and context-builder-tools.ts, but the actual schema definitions are not included in the provided source snippets, making it impossible to verify parameter types, constraints, or descriptions for the majority of tools. Per the hard scoring rule: 'If you cannot see the actual tool definition in the source (only inferred): cap that tool's overall at 50.' Most tools fall into this category. Additionally, STDIO transport caps the overall protocolReadiness at 50, which cascades into lower definition scores for remoteness concerns.
Tools (17)
automatewriteauth23/100
Set up automated workflows or scheduled tasks.
browse_libraryread onlyauth35/100
Browse the shared library of contexts and resources.
callread onlyauthsource verified23/100
Call an external MCP source or tool.
catch_upread onlyauth30/100
Retrieve recent activity and pending mentions in the workspace.
Descriptions for 12+ tools are under 70 characters and lack actionable context (WHEN to use, WHAT it returns, HOW it differs from similar tools). Examples: 'read' (70 chars), 'comment' (50 chars), 'catch_up' (85 chars), 'organize' (75 chars).
Generate and document full JSON Schema for all 17 tools, including: input schema with type, description, minLength/maxLength, enum (where applicable) for each parameter; output schema with field types and descriptions. Example: { 'type': 'object', 'properties': { 'artifact_id': { 'type': 'string', 'description': 'UUID of the artifact' }, 'title': { 'type': 'string', 'description': 'User-facing title' } }, 'required': ['artifact_id'] }
Expand descriptions to 50-150 characters with explicit structure: [ACTION]: what it does | [WHEN]: when to use instead of similar tools | [OUTPUT]: what fields it returns | [SIDE EFFECTS]: if it creates/updates/deletes. Example: 'publish: Create or update a workspace artifact. Use after drafting content in stage. Returns artifact_id, version, and updated_at timestamp. Creates a new version history entry.'
Rename or clarify generic verbs: 'use' → 'invoke_agent' or 'apply_context'; 'call' → 'invoke_external_mcp_tool'; 'organize' → 'move_to_collection' or 'update_visibility'; 'automate' → 'create_workflow'; 'catch_up' → 'get_recent_activity'
Add parameter descriptions for all tools specifying: data type, valid enum values (if constrained), min/max length, format (email, URL, ISO-8601 date), and whether the parameter is required. Example: 'artifact_id (required, string, UUID format), the unique identifier of the artifact to read'
Score history
Overall score trend
First recorded score · v2 rubric
40/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
F
40
2025-06-18+
v2
writeauth47/100
Generate or execute code artifacts with centralized approval.
draft_manifestread onlyauthsource verified65/100
Record the drafted Context as a card for the person to review. Call again when they request a revision.
findread onlyauthsource verified32/100
Find artifacts in the workspace by title, content, or metadata.
list_workspacesread onlyauth45/100
List workspaces accessible to the current connection.
organizewriteauth23/100
Organize artifacts into collections or change their visibility.
publishwriteauthsource verified30/100
Create or update an artifact in the workspace.
readread onlyauthsource verified28/100
Read the full content and metadata of an artifact.
shelvewriteauth32/100
Archive or remove an artifact from active view.
stagewriteauth30/100
Upload a file or asset to stage for publishing.
usewriteauthsource verified20/100
Invoke a packaged agent or context to process information.
Multiple tools combine two responsibilities in a single tool, violating single-responsibility principle: 'publish' (create OR update), 'organize' (group into collections OR change visibility), 'shelve' (archive OR remove), 'automate' (workflows OR scheduling), 'derive_code' (generate OR execute).
No visible error handling documentation, recovery guidance, or error classification for any tool. If a tool fails, the LLM has no hint whether to retry, ask the user, or give up.
Tool 'derive_code' is WRITE risk but lacks confirmation/dry-run pattern. Code generation with centralized approval should support a preview or review step before execution, preventing accidental code deployment.
Add error handling guidance: For each tool, document common failures and recovery steps. Example: 'If artifact not found, call find() first to search by title; if find() returns empty, ask the user to confirm the artifact name'
Implement pagination for discovery tools (find, list_workspaces, browse_library): add optional page/offset and limit parameters; document default limit (e.g. 20); return total_count and next_cursor (or has_more) in response
Add confirmation/dry-run pattern to destructive or approval-required tools (derive_code, publish, delete_artifact): Return a preview with 'Do you want to proceed? Say yes to confirm' or support a confirm_id parameter on a second call
Document which tools are idempotent (safe to retry) and which are not. Agents retry on ambiguous failures, non-idempotent tools risk duplicates. Example: 'find' is idempotent; 'publish' (create) is not without deduplication; 'publish' (update) is idempotent if keyed by artifact_id