Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. agora_tools has a discovery-focused description but lacks output schema documentation. agora_call accepts destructive operations but parameter descriptions are sparse and lack constraint details. Neither tool documents return structure, pagination, or error recovery paths. Naming is reasonable (verb_noun pattern) but parameter descriptions fall short of the 72-char baseline for production tools.

• Document the return schema for agora_tools: e.g. { tools: [{ name, description, destructive, category }], total, query_matched_count }. Include pagination if results exceed 50.
• Document the return schema for agora_call: e.g. { status, result: { data?, error?, dryRun_preview? }, execution_id }. Clarify what fields appear on success vs error.
• Replace 'args' parameter with a reference to the tool's own schema. Either inline common args (e.g. 'document_id', 'workspace_id') or link to agora_tools output so LLMs can discover valid parameters.
• Add explicit error recovery guidance: 'If confirm:true is omitted on a destructive tool, the response includes a dryRun preview. Call again with confirm:true to execute. If workspace is not found, agora_call returns available workspace names, use one of those.'
• Expand workspace parameter description: 'Workspace name (case-insensitive, e.g. "Platon") or id (18-28 alphanumeric chars). Defaults to configured workspace. If name is ambiguous, returns available matches.'
• Add output field documentation to agora_tools description: 'Returns array of tools with name, description, destructive flag, and category. Use the exact name in agora_call tool parameter.'