Smart Agent Pro exposes 26 tools for scraping multiple Chinese social media platforms (Bilibili, Xiaohongshu, Douyin, Kuaishou, Zhihu) plus a generic fetch tool. All tools have basic descriptions and input schemas, but the quality is inconsistent. Naming is mostly acceptable (verb_platform_action pattern). Descriptions are present but often terse (10-50 chars) and lack contextual guidance on when to use each tool vs. alternatives. Parameters have type definitions but descriptions are frequently minimal. No documented output schemas. Error handling is not visible in the provided source. The server appears to be a STDIO-only MCP server (fastmcp framework), which hard-caps protocol readiness. Many tools have authentication requirements ('需登入') that are not reflected in parameter validation or error handling guidance.
Descriptions are uniformly terse (10 - 40 chars) and lack actionable context. E.g., 'B站排行榜' (Bilibili rankings) tells the LLM the tool exists but not when to prefer it over similar discovery tools, what data it returns, or dependencies (e.g., default category='all'). No guidance on output structure or downstream tool chaining.
No documented output schemas. LLMs cannot reason about what fields will be returned, making it impossible to plan multi-step workflows. E.g., does bilibili_search_tool return video_id, title, author, view_count? Required for downstream tool chaining (e.g., bilibili_search_tool → bilibili_detail_tool).
Recommendations
Expand descriptions to 100 - 200 chars. Current 10 - 40 char descriptions like 'B站排行榜' are too terse. Format: '[WHAT] This tool fetches [RESOURCE] from [PLATFORM]. [WHEN] Use it when [SCENARIO]. [RETURNS] Returns [FIELDS]. [DEPENDENCIES] Requires [AUTH/PARAMS].' Example: 'Fetch trending Bilibili videos by category. Use this to discover top-ranked content in a specific category (all, anime, music, etc.). Returns video_id, title, author, view_count, upload_date. Category defaults to all; results capped at 50.'
Document output schemas for every tool. Define what fields are returned, their types, and how they chain to other tools. Example for bilibili_search_tool: '{"results": [{"video_id": "string", "title": "string", "author": "string", "view_count": "integer", "upload_date": "ISO8601"}], "total": "integer", "next_cursor": "string or null"}'
Add parameter descriptions for search tools. Clarify what keyword accepts (free-form text vs. field-specific search), character limits, language support, and example valid inputs. E.g., 'keyword (string, 1 - 100 chars): Free-form search text. Matches title, author, tags, and description. Supports Chinese and English. Example: "Python 教程".'
Implement pagination parameters (offset/page, cursor, limit) for all list/search tools. Document in descriptions: 'Results capped at 50 per request. To fetch more, use offset to paginate. Example: offset=0, offset=50, offset=100 for sequential batches.'
Add error recovery guidance to descriptions. E.g., 'If bvid is invalid (not 8 - 12 alphanumeric chars), bilibili_detail_tool returns 404. Validate bvid format before calling or catch the error and call bilibili_search_tool to look up the video by title.'
Authentication requirements ('需登入' / 'needs login') are documented in descriptions but NOT reflected in parameter validation, error handling, or tool structure. No guidance on what happens if credentials are missing, whether the tool fails gracefully, or how to recover. 18 tools have implicit auth dependencies.
Empty input schemas (xiaohongshu_hot_tool, douyin_hot_tool, kuaishou_hot_tool, zhihu_hot_tool) have no parameters documented. If these tools support optional pagination, sorting, or filtering, that MUST be explicit. If truly empty, the schema is correct but the description should explain what the tool unconditionally returns.
No error recovery guidance. If bilibili_detail_tool fails (invalid bvid, rate limited, network error), the description does not tell the LLM what to do next. Should include: valid bvid format, common failure modes, and recovery steps.
Parameter descriptions are missing or minimal. E.g., bilibili_search_tool 'keyword' param: is this a free-form text search or must it match specific fields (title, author)? What character limits apply? Must be explicit so LLMs know what inputs are valid.
No pagination documented. Tools like bilibili_search_tool accept 'count' but no offset/page parameter. If results exceed count, how does the LLM fetch the next batch? Without pagination, large queries may time out or return incomplete results.
smart_fetch tool accepts 'headers' and 'timeout' params but does not document valid header names, timeout range, or when these override defaults. Vague parameter guidance invites misuse.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 26 tools are marked Risk: READ_ONLY in metadata but this is not exposed via tool annotations in the schema. MCP spec 2026-07-28 recommends tool annotations for clarity.
Document authentication requirements explicitly in schema. For tools marked 'needs login', add a 'credentials_required: true' flag or structured error message: 'This tool requires valid Xiaohongshu session cookies. If you see 'unauthorized' error, ensure credentials are configured.'
For hot_tool variants (xiaohongshu_hot_tool, douyin_hot_tool, etc.), clarify what 'hot' means (trending in last 24h? all-time popular?) and whether results can be sorted/filtered. If no filters exist, state: 'Returns top 50 trending items in descending order by engagement.'
Add tool annotations to schema. Mark all READ_ONLY tools with readOnlyHint: true. Even though no tool is destructive, explicit annotation improves LLM decision-making. Example: {"name": "bilibili_search_tool", "description": "...", "inputSchema": {...}, "readOnlyHint": true}
Define smart_fetch 'headers' parameter constraints. Document: 'headers (object, optional): Custom HTTP headers as key-value pairs. Allowed keys: User-Agent, Accept, Accept-Language, Referer. Dangerous headers (Authorization, Cookie) are blocked for security.'
Define smart_fetch 'timeout' parameter range. E.g., 'timeout (integer, 1 - 120, default 30): Seconds to wait before aborting the request. Use higher values for slow or large-response endpoints.'
Consolidate platform-specific discovery tools. Rather than 18 separate tools (search, detail, comment, user, hot), consider a single 'platform_query' tool with a 'query_type' enum parameter. This reduces cognitive load for LLMs and makes composition clearer.
For search tools, document result ranking. Are results sorted by relevance, recency, or engagement? LLMs need to know to plan follow-up queries.
Add rate-limit guidance. If any platform enforces per-minute/per-hour limits, document in descriptions: 'Bilibili search is rate-limited to 10 requests/minute. If you hit a 429 error, wait 60 seconds before retrying.'