生成二维码。默认 format='svg' 返回 SVG 矢量图字符串（纯标准库生成，可直接保存为 .svg 文件，AI agent 可直接写文件）；format='png' 时返回 PNG 图片的 base64 编码和 data URI（需服务器安装 Pillow，未安装会返回提示）。content 支持 URL、纯文本、WiFi 配置（如 WIFI:T:WPA;S:网络名;P:密码;;）等任意字符串，上限 2000 字节。CPU 密集，走线程池不阻塞事件循环。
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | svg | |
| content | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure — and it delivers comprehensively: return formats for both SVG and PNG, the Pillow dependency and its failure behavior, the 2000-byte content limit, and CPU/thread-pool characteristics. This is exemplary disclosure.
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?
Information-dense with the purpose front-loaded and zero filler; every clause earns its place. Slightly marred by being a single dense paragraph rather than structured lines, which would improve scannability for an agent.
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?
With no output schema, the description must explain return values, and it does (SVG vector string vs PNG base64 + data URI). Both parameters are explained, dependencies disclosed, and constraints stated — complete for this moderate-complexity tool.
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 0% with bare property definitions, and the description fully compensates. It explains the format default and both return types, and enumerates supported content types (URL, plain text, WiFi config) plus the 2000-byte size limit — adding substantial meaning the schema lacks.
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?
States a specific verb+resource ('生成二维码' / Generate QR code) with concrete format options and clear scope. The sibling tools (convert_timestamp, convert_unit, format_json, generate_uuid) are all unrelated utilities, so there is no ambiguity about what this tool does or how it differs.
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 explains the format tradeoffs (SVG vs PNG with the Pillow dependency) which helps an agent select the right output format, but it does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied by the tool's obvious function rather than stated.
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 maps to a distinct operation: timestamp conversion, unit conversion, JSON processing, QR generation, and UUID generation. There is no functional overlap or realistic chance of selecting the wrong tool.
All names follow a clear verb_object snake_case pattern: convert_timestamp, convert_unit, format_json, generate_qr, generate_uuid. The verb prefixes consistently reflect the action category.
Five tools is a well-scoped size for a focused developer utility server; each tool provides a distinct, reusable capability and none feels redundant or extraneous.
Each utility is functionally self-contained: timestamp conversion works in both directions, JSON supports format/minify/validate, QR supports SVG/PNG, and UUID supports v4/v5. The set is a loose collection rather than a tightly defined domain, so common utilities like hashing or base64 are absent, but this is a minor gap rather than a blocking one.