Knomit has 8 tools with basic naming and descriptions, but significant gaps in schema completeness and parameter documentation. Tool names follow verb_noun convention (knomit_learn, knomit_query, knomit_explain), which is good. However, input schemas visible in the source show minimal parameter descriptions and lack type constraints (enums, ranges, formats). For example, knomit_learn accepts 'paths' (array), 'branch' (string), and 'binding' (string) with only brief descriptions like 'File paths to learn', no guidance on path format, required vs optional, or valid branch patterns. knomit_query's 'limit' parameter has no min/max bounds. No output schemas are documented anywhere in the provided code. Error handling is not visible in the source. The server appears to be a knowledge-base tool for code analysis, but the tool definitions lack the depth needed for reliable LLM invocation.

• Document output schemas for all 8 tools. Specify what fields are returned, their types, and which IDs/references are included for chaining (e.g., if knomit_query returns facts, include fact_id, path, and branch so downstream tools can reference them).
• Expand parameter descriptions to 50-150 characters. For 'paths', explain: 'File paths to learn (relative to repo root; supports glob patterns like src/**/*.go). Required.' For 'limit', add: 'Maximum results to return (1-1000, default 20).'
• Add enum constraints to free-form string parameters. knomit_repos 'action' should declare enum: [list, add, remove]. knomit_query 'branch' should document valid branch names or patterns.
• Add error handling guidance. Document common failures (e.g., 'Branch not found', 'Invalid path', 'Knowledge base empty') and recovery steps (e.g., 'Call knomit_repos to list available branches').
• Mark destructive tools with clear state-modification warnings. Add to descriptions: 'This tool modifies the knowledge base. Changes are permanent.' Consider adding a dry_run parameter to knomit_update and knomit_retract.