Skip to main content
Glama

Taiwan Road Safety Data (Unofficial)

get_county_drunk_enforcement

查詢某年各縣市(22 縣市加署所屬機關)的酒駕舉發件數(cases,酒精濃度超過規定標準者)與毒駕舉發件數(drugCases,吸食毒品迷幻藥麻醉品及其相類似之管制藥品者,資料集 39362);這些是行政舉發件數,不是事故件數,反映執法強度而非酒駕或毒駕發生率,不可與道安總動員或警政署統計查詢網的數字互比;毒駕舉發的 114 年數字與交通部草案說明差 616、與 113 年差 4.9 倍,原因不明,限制說明有寫;毒駕事故(傷亡事故層)請用 get_period_comparison 的 吸食違禁物駕駛 分類;目前只有 114 年,內建離線資料,不連上游

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "year": "<year>"
    },
    "name": "get_county_drunk_enforcement"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearYes民國年,目前只有 114

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so: it discloses that data is built-in offline (不連上游), that only year 114 is available, that figures are enforcement counts reflecting 執法強度, and it flags known unexplained discrepancies (差 616, 差 4.9 倍) rather than hiding them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose and output fields are front-loaded, and every clause conveys usable information, but it is delivered as one long semicolon-chained sentence with heavy embedding, which hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup with no output schema, the definition covers availability, data provenance, interpretation caveats, known data anomalies, and the alternative tool for the adjacent question. An agent has everything needed to call it and interpret the result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There is only one parameter, year, and schema coverage is 100% with the note 民國年,目前只有 114. The description repeats the same 114-only constraint and adds that data is offline, but supplies no further format or semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource (查詢各縣市酒駕/毒駕舉發件數), enumerates the returned fields cases and drugCases with their definitions, and cites the source dataset (39362). It also distinguishes itself from accident-level statistics by pointing to get_period_comparison for 毒駕事故.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when not to use the data (事故件數 vs 舉發件數), forbids comparison with 道安總動員 and 警政署統計查詢網, and routes the agent to get_period_comparison for the 吸食違禁物駕駛 category. Both the positive use case and the alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources