devtools-mcp

Convert Unit

convert_unit

单位换算，支持四类：长度(m/km/cm/mm/mile/foot/inch，含毫米/厘米/英里/英尺/英寸)、重量(kg/g/mg/t/lb/oz，含克/磅/盎司)、温度(c/f/k，摄氏度/华氏度/开尔文，自动做偏移换算)、数据存储(B/KB/MB/GB/TB/PB，按1024二进制换算)。不支持的单位或跨类别换算（如米换算成千克）会返回清晰错误。

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": {
      "value": "<value>",
      "from_unit": "<from_unit>",
      "to_unit": "<to_unit>"
    },
    "name": "convert_unit"
  }
}

Input Schema

Name	Required	Description
`value`	Yes	待换算的数值
`to_unit`	Yes	目标单位，如 "mile"、"kg"、"c"、"MB"
`from_unit`	Yes	源单位，如 "km"、"lb"、"f"、"GB"

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedNov 9, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / from_unit / description
```
Added value: +"源单位，如 \"km\"、\"lb\"、\"f\"、\"GB\""
```
- removedInput schema / properties / from_unit / title
```
Removed value: -"From Unit"
```
- addedInput schema / properties / to_unit / description
```
Added value: +"目标单位，如 \"mile\"、\"kg\"、\"c\"、\"MB\""
```
- removedInput schema / properties / to_unit / title
```
Removed value: -"To Unit"
```
- addedInput schema / properties / value / description
```
Added value: +"待换算的数值"
```
- removedInput schema / properties / value / title
```
Removed value: -"Value"
```
- removedInput schema / title
```
Removed value: -"convert_unitArguments"
```
- changedOutput schema / (root)
```
Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "type": "object"
+}
```
First observedSep 6, 2026

TDQS

A4.3/5.0

Behavior4/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 well: it discloses the accepted unit vocabulary per category, the 1024-based binary convention for data storage, the offset handling for temperature, and the failure mode for invalid or cross-category input. It does not mention rounding/precision behavior, which is the main remaining gap.

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?

A single dense sentence, front-loaded with the capability and then the constraints; every clause (categories, unit lists, offset note, 1024 note, error behavior) carries information. The parenthetical bilingual unit glosses add slight redundancy but aid disambiguation.

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

Completeness4/5

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

An output schema exists, so return values need not be explained. For a 3-required-parameter pure function, the description covers inputs, valid domains, conversion conventions, and error cases; only precision/rounding semantics are left unstated.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by enumerating the valid unit strings per category (m/km/cm/mm/mile/foot/inch, kg/g/mg/t/lb/oz, c/f/k, B/KB/MB/GB/TB/PB), which is meaning the schema's example-only descriptions do not provide.

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?

States a specific verb+resource ('单位换算') and immediately enumerates the four supported categories with their unit tokens, so an agent knows exactly what the tool does and can distinguish it from the unrelated siblings (timestamp, JSON, QR, UUID, DNS).

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

Usage Guidelines4/5

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

The description defines the operating envelope clearly: which categories and units are accepted, that temperature uses offset conversion, and that unsupported units or cross-category conversions (e.g. meters to kilograms) return a clear error. It does not name alternatives, but the sibling tools are unrelated utilities, so no routing guidance is needed.

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

All devtools-mcp tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.