Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
The server demonstrates solid foundations with 21 well-named tools using consistent verb_noun patterns (douyin_browser_*, register patterns). All tools have descriptions in Chinese, though descriptions are terse (average ~50 chars, below the 194 char baseline for A+ tools). Input schemas are present for all tools with type declarations and defaults, but parameter descriptions are minimal or absent. Output schemas are not documented. Error handling is basic (exception wrapping via response_from_exception). Security appears sound (no secrets in params, fastmcp handles auth). Tool composition is logical (each tool has single responsibility), though some tools like sync_if_needed and sync_creator_data show tight coupling via transcript_policy side effects. The codebase shows production maturity (lifespan contexts, transaction-like state capture), but LLM-optimization of descriptions is lacking, Chinese descriptions are not expanded to explain WHEN to use each tool or what prerequisites exist.
Descriptions are uniformly terse (avg ~50 chars) and written in Chinese without English context for LLM reasoning. Baseline is 194 chars; A+ tools include WHEN to use the tool, prerequisites, and next steps. Example: 'douyin_browser_login_start' description is only 29 chars and provides no guidance on when to call it vs login_status, whether it requires prior state, or what the user should do next.
Expand ALL tool descriptions to 50 - 200 characters, following LLM-optimized format: 'Does X. Use when Y. Returns Z.' Example: 'douyin_browser_login_start' should read 'Open a visible browser and start the Douyin login flow. Call this first if not logged in or session expired; user must scan QR code. Returns login status and session info.'
Add parameter descriptions for every input. For enum params like 'mode' and 'scope', list all valid values (e.g. 'Sync mode: one of [visible, background, hybrid]'). For numeric params, add bounds (e.g. 'recent_limit: 1 - 100 items to retrieve').
Declare enum constraints in the JSON Schema. Replace free-form strings with explicit 'enum' arrays: scope: {type: string, enum: [list, details, ...]}. This is machine-parseable and prevents hallucination.
Document output schemas. Add to tool docstrings or a separate schema document: what fields does success_response return? What is the structure of transcript_ingestion? Include example responses so LLMs know what to expect.
Clarify the relationship between login_start, login_status, and get_status. The descriptions should guide LLMs on which to call first, when to poll for status, and when to skip browser interaction.
Extract the transcript_policy orchestration into explicit parameters or a separate tool. If sync tools trigger transcript ingestion as a side effect, document this in the description: 'This tool also queues transcript extraction tasks based on the transcript policy. Returns ingestion_queue status.'
Parameter descriptions are missing or trivial. Example: douyin_browser_sync_if_needed has parameters 'scope', 'max_age_hours', 'mode', 'recent_limit' with only 1-word descriptions ('Sync scope', 'Maximum age in hours') that do not explain constraints, valid values, or reasoning. LLMs cannot determine whether to pass 'list' vs 'details' for scope without enum declarations or richer descriptions.
Output schemas are not documented in the tool definitions. The code shows response_from_exception and success_response wrappers, but there is no visible documentation of what success_response returns, what fields are in the response, or what the LLM should expect for downstream chaining. This forces LLMs to guess the response structure and risks broken tool chains.
String enum parameters lack explicit enum declarations. Example: douyin_browser_sync_if_needed accepts 'scope', 'mode' and douyin_browser_export_data accepts 'format' as free-form strings with no enum constraint. The code shows defaults like 'list' and 'json', but no formal constraint listing all valid values. LLMs will hallucinate invalid values.
Error handling is minimal. The code uses response_from_exception(exc) which is never shown in the provided source. Without visible error classification (retryable vs fatal), recovery guidance, or specific error messages with constraints, LLMs cannot self-correct or plan recovery. Example: what should the LLM do if login fails due to expired session vs network timeout?
Tight coupling between sync tools and transcript_policy side effects. douyin_browser_sync_if_needed and douyin_browser_sync_creator_data both invoke sync_with_transcript_policy, which captures state and modifies result['transcript_ingestion']. This hidden orchestration is not documented in tool descriptions and makes the tools' behavior non-obvious to LLMs. The tools appear to do one thing (sync) but silently trigger policy-driven side effects.
Add error guidance to WRITE operations. For tools like submit_transcript_run and cancel_transcript_run, document what errors can occur (e.g. 'run_id not found', 'run already completed') and how to recover.
Reduce parameter defaults that could cause data loss. douyin_browser_export_data has output_path=null, clarify what 'null' means (auto-generate path? use a default?). Avoid surprises.
For list tools (list_videos, list_transcript_runs), ensure pagination is documented: 'Supports pagination. Pass limit and offset/cursor to retrieve next page. Returns total_count for planning.'
Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) for tools that are read-only (get_*, list_*) vs destructive (cancel_*, delete_*) vs idempotent (retry_*). This guides agent safety and retry logic.