Skip to main content
Glama
devrobotlabs

@devrobotlabs/visionapi-mcp

Official
by devrobotlabs

Identify what a file is, without extracting it

vision_detect

Identify a file type to choose the right extraction preset, providing ranked, confidence-scored suggestions before you commit credits.

Instructions

Identify what a file IS without paying to extract it: the presets that could handle it, ranked, each with a confidence and a one-line reason.

Cost: 1 credit per 5 calls, whatever the file — detection only ever reads page 1, so a 300-page PDF costs the same as a photo. Four calls in five report 0 credits used.

recommended is exactly what preset:"auto" would run on this file, so you can probe first and trust the answer.

Reach for this when the TYPE is the decision: routing a mixed inbox to different handlers, or refusing to spend two credits a page on a 40-page PDF sight unseen. Do NOT reach for it as a step before every vision_analyze call — if you want the data and do not care which preset produced it, preset:"auto" classifies the same way, for free, in the same request. Using detect first and then analyze is two calls where one would do.

If fallback is true, nothing matched confidently and the recommendation is the generic preset. That is an honest "unknown", and it is worth surfacing to the user rather than extracting against a shape nobody has confirmed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
detailNo"high" renders pages at higher resolution for dense or low-quality scans. Same credit cost, slower.
formatNomarkdown (default) — compact, readable, absent fields summarised rather than repeated. compact_json — the same information as data, with _not_found and _low_confidence arrays, for when you will parse it. json — the API response verbatim; use it when you are writing HTTP code against the contract.markdown
file_urlNoPublic HTTPS URL the API fetches itself. Private and internal addresses are refused by the server.
file_pathNoAbsolute or relative path to a file on the user's disk. Must be inside a directory this server was given access to — the error names them if it is not.

Schema Changelog

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

  1. First observedv1.0.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations give basic hints, but description adds substantial context: cost (1 credit per 5 calls), that detection only reads page 1, the meaning of 'recommended' as exactly what preset:'auto' runs, and fallback behavior as an honest 'unknown'. No contradictions with annotations; readOnlyHint false is clarified by the read-only nature described.

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 description is well-structured with front-loaded purpose and cost, but is relatively long. Every sentence contributes value, yet it could be tightened without losing meaning, especially the repeated emphasis on cost and the comparison with vision_analyze.

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?

Given no output schema, the description conveys enough about output structure (presets ranked with confidence and reason, recommended field). It also covers cost, fallback, and usage. However, it leaves ambiguity about file parameter requirement (both optional in schema) and does not explicitly state that at least one file source is needed.

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 descriptions cover all 4 parameters at 100% coverage, so the baseline is 3. The description adds no parameter-level semantics beyond the schema; it does not explain that at least one of file_url/file_path must be provided, nor how to choose between them.

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?

Description states the tool identifies what a file is without extraction, explicitly contrasting with vision_analyze. It also specifies output: presets ranked with confidence and reason. This distinguishes it from sibling tools and provides a clear verb+resource.

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?

Provides explicit when-to-use ('when the TYPE is the decision') and when-not-to-use ('do NOT reach for it as a step before every vision_analyze call'), naming the alternative preset:"auto" within vision_analyze. Includes concrete scenarios like routing a mixed inbox and avoiding costs on large PDFs.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/devrobotlabs/visionapi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server