This is a client demo that wraps a remote MCP server (Pearl API). The single tool 'askExpert' is NOT defined in the source code provided, it is dynamically fetched from the remote MCP server via `await mcp_server.list_tools()`. The source shows only a client implementation that instantiates an Agent and calls the remote server's tools. No tool definitions, input schemas, or parameter descriptions are visible in the codebase. The description provided in the evaluation metadata ('Ask a legal expert for a second opinion on a legal question or answer') is extremely generic and does NOT come from the source code, it appears to be editorial annotation. Without seeing actual input/output schemas, parameter definitions, or explicit tool registration in the source, the tool receives a failing score.

• If this is intended as a client demo, add explicit tool definition(s) to the codebase to document the schema. Do not rely on dynamic schema discovery for tool quality assessment.
• Define askExpert with a detailed JSON Schema input specification: { type: 'object', required: ['question'], properties: { question: { type: 'string', description: 'The legal question to ask the expert' }, ... } }
• Add a comprehensive tool description (50 - 200 chars): e.g., 'Request a second opinion from a legal expert on a specific legal question or your answer. Use when you need expert validation of legal advice.'
• Document each input parameter with a description explaining what it controls, valid values, and format. Include any constraints (length, enum, pattern) in the parameter description, not just in the schema.
• Document the output schema. Specify what fields are returned (e.g., expert_opinion, confidence_level, limitations, references) and their types.
• Add error handling guidance. Provide actionable messages for failures: 'Expert service temporarily unavailable, try again in a few seconds' or 'Question too vague, provide more context and retry.'
• If the tool modifies state (e.g., logs the consultation for billing), state this explicitly in the description so the LLM knows it has side effects.
• If the tool accepts a 'question' parameter, add a constraint on length (e.g., 50 - 2000 characters) to prevent token waste and timeouts.