Skip to main content
Glama

APICK

이미지 대량 작업 결과

image_batch_result
Read-only

완료된 대량 작업 결과 중 지정한 한 장을 이미지 콘텐츠로 반환합니다. [무료]

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYes0부터 시작하는 이미지 번호
job_idYes작업 ID

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, so the read-only behavior is covered. The description adds useful context: only one image is returned, only from completed jobs, and the operation is free. It does not describe error behavior for invalid job IDs or out-of-range indices, but the schema and annotations cover much of the safety profile.

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?

One short sentence contains the operation, the object, the condition (completed), and the return type (image content), with '[free]' appended. There is no filler or repetition of schema fields.

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 simple two-parameter read-only tool with full schema coverage and no output schema, the description is nearly complete: it identifies the return content and the required job state. It could be more explicit about using image_batch_status first, but this is a minor gap.

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?

Schema description coverage is 100%, with job_id and index already documented including zero-based indexing and the 0-49 range. The description adds no parameter-level information beyond saying 'specified one image', so it stays at the schema-covered baseline.

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 uses a specific verb and resource: it returns one specified image from a completed batch job as image content. It does not explicitly name sibling tools, but the contrast with image_batch_create and image_batch_status is clear from the wording (completed result vs creating/status).

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

Usage Guidelines3/5

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

The word 'completed' implies the tool should be used after a batch job finishes, and the 'result' phrasing distinguishes it from status-checking or creation. However, it does not explicitly state when-not-to-use it or point to image_batch_status as a prerequisite/alternative.

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.

TDQS

B3.1/5.0
Disambiguation2/5

Multiple tools target the same documents with unclear boundaries: identi_card_image1, ocr_identi1, and identity_document_id_card all accept a resident registration card image but differ in verification vs extraction vs masking, which agents will struggle to distinguish. The identi_card1-5 vs identi_card_image1-5 vs ocr_identi1-5 clusters are especially confusing, despite some helpful descriptions.

Naming Consistency2/5

Naming is highly inconsistent: some tools use verb_noun (check_phone_valid, search_juso, pdf_merge), some are bare nouns (whois, nslookup, ocr, stt), and identity tools use three parallel schemes (identi_card1, identi_card_image1, ocr_identi1, identity_document_id_card) with no clear pattern. No single convention is followed across the toolset.

Tool Count1/5

88 tools is an extreme count for a single MCP server, spanning identity verification, parcel tracking, LLM chat, image generation, PDF conversion, TTS, and network lookups. This is an API marketplace dump rather than a focused toolset, and the number far exceeds any reasonable scope.

Completeness2/5

The server's scope is unbounded, so it has gaps everywhere: no video transcription shortcut, no PDF splitting, no batch cancellation for images (only TTS), and identity clusters lack clear differentiation between verify/extract/mask workflows. Some subdomains like TTS have a full lifecycle, but overall the coverage is scattered and incomplete for the implied breadth.