Filura defines 3 tools with clear, descriptive names and well-structured schemas. All tools have descriptions (194 - 250 chars, within baseline 34 - 392 range) and complete input schemas with type definitions and parameter descriptions. However, output schemas are not formally documented, responses are rendered as text summaries rather than structured objects. Error handling is minimal (no recovery guidance or error classification). Tools are read-only and composition-focused, which is appropriate for the domain, but lack the structured output pattern that would enable downstream tool chaining.

• Return structured JSON from all tools: find_tools should return {tools: [{id, description, inputs, outputs}], edges: [{from, to, fromField, toField, score}], suggestedOrder: []}. This enables LLMs to reliably extract and chain tool calls.
• Add error classification to responses: distinguish 'no_match' (try broader goal), 'ambiguous_input' (clarify tool_id), and 'catalog_empty' (fatal). Include recovery hints: 'No tools matched. Try: (1) broader goal, (2) call describe_catalog to see available servers.'
• Document output schemas formally in tool definitions. Use a 'returns' field or extend inputSchema with outputSchema describing the JSON structure, field types, and required fields.
• Enhance parameter descriptions with format/constraint guidance: 'goal: Natural language description of what you want to accomplish (e.g., "create a Jira ticket and assign it to Alice"). 50 - 500 characters. More specific goals return fewer, more relevant tools.'
• Add a 'confidence' or 'provenance' field to each edge in the data flow, and document in the tool description how to interpret confidence scores (e.g., 'score >= 0.8 = high confidence, < 0.6 = verify manually').