Loading ToolBench
This server provides 7 tools for Taiwan legal research via a FastMCP wrapper. While tool names follow verb_noun convention and descriptions exist, multiple critical gaps prevent higher scoring: (1) tool definitions appear to be inferred from code rather than explicitly registered with schemas in the visible source; (2) parameter descriptions are inconsistent in completeness; (3) output schemas are not documented; (4) error handling lacks recovery guidance; (5) STDIO-only transport severely limits accessibility. The server is functional for a niche use case (Taiwan legal database queries) but lacks production-grade structure expected of agent tools.
取得完整法規的所有條文內容。可接受法規名稱或法規代碼(pcode)作為輸入，提供pcode效率較高。支援摘要模式（每條只顯示第一行）以及設定條文數量上限，以控制 Token 消耗。
快速取得特定法規的專屬代碼(pcode)，供後續工具呼叫時使用。
查詢特定法條的詳細內容（單條條文）。例如：查詢「民法第1條」、「刑法第271條」。提供 pcode 比提供 name 效率更高，可先用 get_law_pcode 取得。
在全部台灣法規中以關鍵字搜尋相關條文。適合用於「找出所有提到某詞彙的法條」的情境，例如搜尋「安全無虞」、「契約」等關鍵字。
依據法規名稱與條號，搜尋司法院裁判書系統中的相關判例。當使用者已經查閱完法規內容，並希望知道實務上法院如何判決時使用。
搜尋台灣法規名稱，取得法規基本資訊和官方網址。當使用者想搜尋法規名稱、確認某法規是否存在，或是取得法規代碼(pcode)時使用此工具。
驗證法規代碼(pcode)是否為有效的台灣法規代碼。
Tool definitions are inferred from code rather than explicitly visible in source. No explicit tool registration via @server.call_tool decorator or equivalent MCP tool definition mechanism is shown in the provided archive/mcp_server.py or src/taiwan_law_mcp/server.py files. Tool names and descriptions appear to come from docstrings and function signatures, not from an explicit MCP schema declaration.
Output schemas are not documented. The code shows functions that parse and return data (e.g. parse_law_content returns Dict[str, Any], search_law_by_name returns {'status': ..., 'result': ..., 'suggestions': ...}), but there is no explicit JSON Schema documentation visible in the tool definitions for what the response structure contains, what fields are present, or what types they are. LLMs cannot plan downstream tool calls without knowing the response schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 50 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 50 | - | v1 |
Parameter descriptions are inconsistent and sometimes incomplete. Example: 'max_suggestions' in search_law has a description, but 'pcode' in get_law_pcode has only '法規代碼，例如：B0000001' (literal example in description, not actionable constraint). 'article' in get_single_article lacks format specification (what format is '16-1'?). Descriptions should include format, range, and valid values, not just examples.
No error handling guidance. The code shows exception raising (RuntimeError, requests exceptions, parsing failures) but tool descriptions do not explain what errors can occur, when they are retryable, or what the LLM should do if a call fails. E.g. search_law may fail to parse ASP.NET form state, what should the agent do? Retry? Call a different tool? Reset the session?
Parameter values in descriptions violate the 'no example values' rule. Examples like '民法', '刑法', '安全無虞', '契約' appear in parameter descriptions. LLMs latch onto examples and may reuse them literally instead of adapting to the user's actual query. Use enum constraints or format patterns instead.
Mutually exclusive parameters lack explicit documentation. In get_full_law, 'name' and 'pcode' are documented as 'one or the other', and get_single_article has 'name' and 'pcode' with the same pattern, but the descriptions do not state clearly: 'You must provide either name or pcode, but not both. pcode is preferred for efficiency.' This forces LLMs to reason about exclusivity.
Token consumption warnings are buried in descriptions. get_full_law and search_by_keyword mention 'Token 消耗' (token consumption) in parameter descriptions, but there is no corresponding rate limiting, pagination guidance, or explicit caps on result size in the tool definition. The description warns about tokens but does not declare a hard limit (e.g. 'max_articles defaults to 0 [unlimited]; recommended max is 500 to avoid context overload').