Tool definitions are inferred from site/.well-known/mcp.json metadata only, no actual implementation code visible. The JSON lists 20 tools with names and brief descriptions (10-50 chars), but NO input schemas, NO parameter definitions, NO output schemas, and NO error handling guidance. Descriptions are too short (avg ~25 chars vs. baseline 194 chars) to guide LLM tool selection. Cannot verify schema compliance, parameter types, or composition patterns. This is a metadata stub, not a production-ready tool definition.

• Add full JSON Schema input definitions for all 20 tools. Each parameter must have type, description (50-100 chars), and constraints (enum, min/max, pattern). Example: find_context should document what 'context' parameter accepts and whether it's a name, ID, or search query.
• Expand tool descriptions to 100-200 chars. Include WHAT the tool does, WHEN to call it vs. similar tools, and WHAT it returns. Example: 'List all entities in the knowledge store (contexts, metrics, sources). Call this first to discover available resources before querying specific ones. Returns array of {id, name, type, description}.'
• Document output schemas for all tools. Specify return type (object, array, string), field names, types, and whether pagination is supported. For list_* tools, include total_count and next_cursor fields.
• Add error handling guidance to descriptions. Document common failure modes (not found, permission denied, validation error) and recovery steps. Example: 'If entity not found, call list_entities() to verify the ID exists.'
• For WRITE tools (publish_app, upsert_context, etc.), add a dry_run parameter or document a confirmation flow. Agents need a safe way to preview changes before committing irreversible operations.