Server defines 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (search, fetch, prepare_run, execute_node, advance). Descriptions are present but brief (10-60 chars), below the 50-200 char LLM-optimized baseline. Parameter descriptions exist but lack detail on constraints, formats, and error recovery. Output schemas are not documented. Error handling is minimal, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Tool composition is reasonable (single responsibility per tool), but chaining dependencies (e.g., search → fetch → prepare_run → execute_node → advance) are not documented in descriptions.

• Expand tool descriptions to 50-200 chars. Example for 'search': 'Search OysterWorkflow workflows by query string. Returns matching workflows with IDs and metadata. Use this to discover workflows before fetching details. Query supports partial name matching (max 200 chars).'
• Document output schemas for all tools. Specify what fields each tool returns (e.g., search returns [{workflowId, name, revision, description}]). This enables LLMs to plan chaining and extract required IDs.
• Add constraint details to parameter descriptions. E.g., 'q' → 'Search query (1-200 characters, case-insensitive, supports partial name matching)'. 'inputs' → 'Workflow input parameters as key-value pairs. Values must be strings or JSON-serializable objects.'
• Add error handling guidance. E.g., 'execute_node may fail if the node requires external tool calls. If it fails, check the error message for missing dependencies, then call advance with evidence from manual execution.'
• Document tool chaining in descriptions. E.g., 'prepare_run' → 'Prepare a workflow run. Call search() or fetch() first to get workflowId. Returns a run ID for use with execute_node().' This guides agent planning.