Server defines 5 tools with complete JSON Schema input schemas and tool annotations (readOnlyHint/destructiveHint). All tools have descriptions (10-60 chars, below the 50-200 char optimum). Naming follows verb_noun pattern (list_, get_, ask, handoff, openapi). However, descriptions are terse and lack context on WHEN to use each tool or what downstream actions they enable. Parameter descriptions are minimal (e.g., 'Company slug' for slug param). No output schema documentation visible. Error handling present but generic. Composition is sound, each tool has one responsibility. Missing: guidance on tool selection, dependency hints, and structured output documentation.

• Expand tool descriptions to 50-200 chars. Example: 'List public Crane Wiki company records by country, city, or pagination cursor. Returns company name, slug, location, and contact info. Use this to discover companies before calling get_company for details.'
• Document output schemas for all tools. Specify which fields are returned (e.g., company_id, slug, name, country, city) so LLMs know what data is available for downstream calls.
• Add dependency hints to descriptions. E.g., 'If you only have a company name, call list_companies first to find the slug, then call get_company.'
• Clarify gstcranes.ask purpose and constraints. What types of questions does it answer? When should an agent use this vs list_companies? Provide examples of valid queries.
• Document pagination behavior for list_companies. Explain cursor semantics, whether limit is enforced, and how to detect end-of-results.