Single tool 'list_registered_tools' has a reasonable description (56 chars, within 10-1024 range) but critically lacks an input schema. The tool accepts no parameters (empty {}), yet the schema is not formally declared in the code. Tool naming follows verb_noun convention ('list_registered_tools'), which is good. However, the output schema is undocumented, callers cannot know what fields to expect from the returned list of dicts. The server is a bridge/wrapper with minimal intrinsic tools; it delegates to LangChain tools registered at runtime. This design means tool definitions are generated dynamically via _bind_tool(), making static schema validation impossible. The _invoke() function wraps LangChain tools but does not expose input schemas to the MCP protocol, schemas are inferred from LangChain's args_schema but not formally registered with FastMCP.

• Formally declare the input schema for list_registered_tools as a JSON Schema object (even if empty) and register it with FastMCP. Example: mcp.tool(name='list_registered_tools', description='...', inputSchema={...}).
• Document the output schema for list_registered_tools. Specify that it returns a list of objects with fields: name (string), description (string), schema (object). Include example output in docstring.
• Enhance _bind_tool() to extract and expose parameter descriptions from LangChain's args_schema. Use Pydantic's field descriptions to populate MCP parameter annotations.
• Improve error messages in _invoke() to categorize failures (retryable vs fatal) and suggest recovery steps. Example: 'Tool invocation timed out after 30s. This is retryable, the agent may retry with the same parameters.'
• Add a tool to introspect registered tools' schemas at runtime. Expose parameter names, types, descriptions, and constraints so agents can discover what inputs each tool accepts before calling.