CrafterWIKI defines 8 tools with complete JSON schemas and descriptions. All tools are READ_ONLY and well-scoped. Naming follows verb_noun convention (search_, similar_, event_, patterns, deal, get_, list_). Descriptions are substantive (100-200 chars typical), explaining WHAT and WHEN. However, parameter descriptions lack actionable constraints (no enums for facet IDs, no format specs for slugs). Output schemas are not documented, LLMs cannot predict response structure. Error handling is minimal (only get_record throws; others fail silently). No tool annotations (readOnlyHint, idempotentHint). Facet parameters reference external taxonomy (list_facets) but do not embed enum values, forcing discovery calls. Overall solid foundation but missing production-grade polish.

• Document output schemas for all tools. Example: search_projects returns {results: [{slug, name, placement, domains, mechanisms, ...}], total, limit}. Include field types and nesting.
• Embed enum values for facet parameters or provide a discovery pattern. Instead of 'comma-separated taxonomy ids', return {type: 'string', enum: ['domain-1', 'domain-2', ...]} or link to list_facets output.
• Add readOnlyHint: true to all tool schemas (MCP 2026-07-28 supports tool annotations). Signals to LLMs that these tools are safe to call without confirmation.
• Enhance error messages. When deal() returns no match, return {error: 'No winners match filters. Try: deal() with fewer constraints, or patterns() to see available facets.'}
• Add format/pattern constraints to slug parameters. E.g. slug: {type: 'string', pattern: '^[a-z0-9-]+$', description: 'Hackathon or project slug (lowercase, hyphens, no spaces)'}.