Context Bridge MCP has 9 tools with basic naming (verb_noun pattern) and descriptions present, but significant gaps in schema completeness and parameter documentation. Tool names are clear (bridge_get, bridge_update, bridge_list), but input schemas lack depth: most parameters have only type and description, missing constraints like enums, min/max, or format specifications. Descriptions are terse (10-50 chars) and lack context about when to use each tool or what happens on error. No output schemas documented. Error handling is minimal, tools return text blocks without structured error guidance. The server follows a consistent naming convention but falls short of production-grade definition quality.

• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Get context content for a domain and optional component. Use this to retrieve stored context before updating. Returns the content as a string or null if not found.'
• Document output schemas for all tools. Define the structure of returned data (e.g., manifest has {version, domains: {[domain]: {[component]: string}}}). This enables LLMs to extract fields for downstream calls.
• Add parameter constraints: enums for 'domain' if known, min/max length for strings, item types for arrays. Example: 'watch' array should specify 'array of strings, each 1-50 chars, matching domain names or keywords (contract, context, manifest)'.
• Implement structured error responses. Return {error: string, code: string, retryable: boolean, suggestion: string} instead of plain text. Example: 'Domain not found. Available domains: [list]. Try bridge_list() first.'
• Add tool annotations (readOnlyHint, destructiveHint) to bridge_update, bridge_register_repo, and bridge_sync_skills so LLMs know which tools modify state and require confirmation.