This server exposes 7 tools with significant definition gaps. Tool names lack clear action verbs (invoke_openclaw_tool, route_callback_action, route_review are vague). Most descriptions are present but generic (10-50 chars), failing to explain WHEN to use each tool or what distinguishes them. Input schemas are visible and typed, but parameter descriptions are sparse or missing context. No output schemas documented. Error handling is absent, tools provide no recovery guidance. The invoke_openclaw_tool is particularly problematic: it's a generic gateway wrapper that delegates to external tools, making it impossible for an LLM to reason about what it actually does without knowing the OpenClaw tool registry. Overall, definitions lack the specificity and LLM-optimization needed for reliable agent selection and execution.

• Rename invoke_openclaw_tool to call_external_tool or delegate_to_gateway, and add a description explaining it is a low-level bridge for invoking pre-registered external tools. Document that callers must know the tool name and schema in advance.
• Expand tool descriptions to 100-200 chars. For route_callback_action, explain: 'Process a card action (approve, reject, snooze) and return a normalized callback decision (e.g., schedule_review, skip_review). Use this after a user interacts with a project-review card.'
• Document output schemas for all tools. E.g., route_review should return {lane: string, card_kind: string, metadata: object}. This enables LLMs to chain tools and extract required fields.
• Add error handling with recovery hints. E.g., 'If gateway_url is unreachable, check OPENCLAW_GATEWAY_URL env var and verify the gateway is running on port 18789.'
• Split invoke_openclaw_tool into domain-specific wrappers (e.g., invoke_feishu_tool, invoke_lark_tool) so LLMs can reason about which external system to target without guessing.