This server has critical structural deficiencies. Tool definitions are inferred from bash script filenames and install.sh comments rather than explicitly registered with schemas. No input schemas are visible in the source code, tools lack parameter type definitions, constraints, or structured output documentation. Descriptions are minimal (10-20 chars) and do not explain WHEN to use each tool, WHAT it returns, or dependencies. No error handling guidance, no parameter validation rules, and no output schema documentation. The bash implementation uses ad-hoc JSON parsing (grep/sed/python fallback) rather than proper schema validation. Security concerns: tokens stored in /tmp/.kanoniv-session-token (world-readable), no rate limiting, no audit trail structure beyond append-only logs.

• Define explicit MCP tool schemas with JSON Schema. Each tool needs: name, description (50-200 chars), inputSchema with type, properties, required, and descriptions for every parameter.
• Expand descriptions to 50-200 characters. Example: 'delegate' → 'Start a scoped session with delegated authorization. Requires kanoniv-auth CLI. Returns session token, scopes, and TTL. Use before running restricted commands.'
• Document output schemas. Example: 'status' returns {token: string, scopes: [string], expires_at: ISO8601, agent_name: string}. Include all fields the LLM needs for downstream calls.
• Add parameter descriptions and constraints. Example: 'scopes' parameter → 'Comma-separated list of scopes (e.g. code.edit, git.push.repo.main). Required. Validates against kanoniv-auth scope hierarchy.'
• Move session tokens to secure storage (e.g. $XDG_RUNTIME_DIR with 0600 perms). Document permission gates and scope requirements per tool. Implement rate limiting and token rotation.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry