get_finlab_docs取得 FinLab Skill 的開發文件（與 GitHub koreal6803/finlab-ai main 分支同步，skill 更新後自動生效）：不帶參數回傳 SKILL.md 主文件與參考文件清單；帶 doc 參數回傳指定參考文件全文。涵蓋 900+ 資料欄位、sim() 回測 API、60+ 策略範例、因子分析與機器學習等，撰寫 finlab Python 程式前建議先查閱。
| Name | Required | Description | Default |
|---|---|---|---|
| doc | No | 參考文件檔名，例如 "dataframe-reference.md"。省略時回傳 SKILL.md 與文件清單。 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden. It explains both invocation modes (no param returns SKILL.md and doc list; doc param returns full reference text) and adds the sync behavior with the GitHub main branch. It does not cover error cases or rate limits, but for a read-only documentation lookup these omissions are minor.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence but front-loads the core purpose and packs meaningful details (sync, parameter modes, content coverage) without excessive fluff. The content coverage list is useful for relevance assessment, though slightly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return values, and it does: SKILL.md with doc list for no params, full reference text with a param. It lacks explicit mention of invalid filename handling, but the schema example and list-return behavior give enough context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description restates the parameter behavior and adds '全文' (full text), but most semantics are already in the schema. No significant additional parameter meaning is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '取得 FinLab Skill 的開發文件' (get FinLab Skill development documentation). It clearly explains the two invocation modes and distinguishes this tool from siblings like get_data_catalog and get_strategy by targeting documentation retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit usage context: '撰寫 finlab Python 程式前建議先查閱' (recommended to consult before writing finlab Python programs). It does not name alternatives or state when not to use it, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool addresses a clearly distinct purpose: data catalog, developer docs, stock evidence, strategy listing, strategy detail, and getting started. The list_strategies/get_strategy pair is explicitly positioned as a list-then-detail flow, so there is no real ambiguity.
The naming is mostly consistent with a get_*/list_* retrieval pattern, and list_strategies vs get_strategy follows a sensible collection/item convention. The outlier is how_to_start, which breaks the verb_noun pattern but remains understandable.
Six tools is well-scoped for a FinLab assistant covering discovery, documentation, stock-level evidence, and strategy access. Each tool earns its place and none feels redundant.
The surface covers the core workflow well: users can learn how to start, browse the data catalog, read developer docs, inspect stock evidence, and list/retrieve strategies. Minor gaps exist, such as no US-stock evidence tool or strategy search/filtering, but they are not blocking for the stated purpose.