Three tools present with descriptions, but critical gaps in schema definition and parameter documentation. All tools are READ_ONLY status checks with empty input schemas ({}), making them trivial from a definition perspective. Descriptions are present (100-150 chars each) but lack actionable guidance on when to use each tool vs. the others. No input parameters means no parameter descriptions to evaluate. Output schemas are not documented in the visible code. Tool names follow verb_noun pattern (cameo_status, cameo_get_capabilities, cameo_probe_bridge) but lack clarity on distinctions, all three appear to probe bridge health, creating potential LLM confusion about which to call first.

• Define explicit output schemas for each tool in the FastMCP registration. Document field names, types (string, object, array), and what each field represents. Example: cameo_status should return {status: string, plugin_version: string, compatible: boolean, endpoints: {status_url: string, ...}}.
• Clarify tool selection logic in descriptions. Add a sentence like: 'Use cameo_status first to check if the bridge is running. If you need detailed capability info, call cameo_get_capabilities. Use cameo_probe_bridge only if you are unsure of the endpoint URL.'
• Add error handling guidance to each description. Example: 'If the bridge is unreachable, ensure CATIA Magic is running and the plugin is deployed. Check the CAMEO_BRIDGE_PORT environment variable.'
• Replace internal jargon with plain language. Instead of 'compatibility.clientCompatible', say 'whether this client version is compatible with the installed plugin'. Instead of 'endpoint groups', say 'available API endpoints'.
• Add a dependency hint to cameo_status: 'Call this tool first before attempting any model operations to verify the bridge is ready.'