Skip to main content
Glama
naipi11
by naipi11

只读检查 GPT 图片后端

check_image_backend
Read-onlyIdempotent

Check available image backend models via a read-only request without generating images or consuming quota. Listing models does not verify actual image generation permissions.

Instructions

仅 GET /models,不生成、不消耗生图额度。可达/列出主模型不代表已验证生图权限,真实生图必须另行调用。

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds valuable context beyond them: no quota is consumed, and a successful model listing does NOT prove image-generation permission. That caveat is exactly the kind of behavioral nuance annotations cannot convey. It falls short of 5 because there is no output schema and the description does not say what a result looks like or how to read a failure.

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

Conciseness5/5

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

Two short, front-loaded sentences. The scope restriction ('仅 GET /models') comes first and the most important caveat about unverified generation permission closes it; no sentence is redundant.

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?

For a zero-parameter, no-output-schema probe the description covers scope, side effects and the key interpretive limit. The remaining gap is what the response actually contains (model list vs. connectivity status) and how to interpret an error, which an agent would need to act on the result.

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?

The tool takes zero parameters, so the baseline is 4; the schema is empty and fully covered, and no parameter semantics are needed or missing.

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

Purpose4/5

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

The description states concretely that the tool performs only a GET /models call and never generates, which tells an agent this is a backend reachability/model-listing probe. It is clearly distinguishable from siblings generate_gpt_image, get_image_job and cancel_image_job, though the action verb itself is implied by the HTTP call rather than named.

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?

'真实生图必须另行调用' explicitly routes actual generation to another call, and the description establishes this as the read-only pre-check. It gives clear context for use but does not spell out positive triggers (e.g. when to run it before generate_gpt_image) or failure handling.

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