Skip to main content
Glama
quickstraw

vision-helper-mcp-server

by quickstraw

List Vision Models on OpenRouter (Vision Helper)

vision_helper_list_models
Read-onlyIdempotent

List vision-capable models from OpenRouter to select one for image analysis. Filter by provider or family, paginate results, and get markdown or JSON output.

Instructions

List vision-capable models currently available on OpenRouter, so you (or the user) can pick which model to use for image analysis.

Models are filtered to those that accept image input. Use the 'search' argument to narrow by provider or family (e.g. 'gemini', 'claude', 'qwen', 'gpt'), and limit/offset for pagination.

Args:

  • search (string, optional): Case-insensitive substring filter on model ID or name.

  • limit (number, default 25, max 100): Maximum number of models to return.

  • offset (number, default 0): Number of models to skip.

  • response_format ('markdown' | 'json', default 'markdown'): Output style.

Returns: For 'markdown': a compact list of model IDs with provider, context length, and input price. For 'json': structured array with has_more / next_offset for pagination.

Examples:

  • "Which vision models can I use?" -> no arguments

  • "Find a fast cheap vision model" -> search="flash"

  • "What vision models does Google offer?" -> search="google/gemini"

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of models to return.
offsetNoNumber of models to skip, for pagination.
searchNoCase-insensitive substring filter on model ID or name, e.g. 'gemini', 'qwen', 'gpt'.
response_formatNoOutput format: 'markdown' for a readable list or 'json' for machine-readable data.markdown
Behavior4/5

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

Annotations already indicate read-only and idempotent behavior, and the description adds valuable context about filtering, pagination, and output formats. It does not contradict annotations, but it does not discuss all edge cases (e.g., errors or rate limits), so a score of 4 is appropriate.

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?

The description is well-structured with a clear summary, args, returns, and examples. Every sentence provides useful information, and it is appropriately sized for a tool with four parameters. No redundancy or fluff.

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

Completeness5/5

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

Given that there is no output schema, the description fully explains return formats and pagination behavior. It also provides examples that cover typical use cases, making it complete for an agent to understand what the tool does and what to expect.

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%, but the description adds meaning beyond the schema by explaining the case-insensitive search filter, the purpose of pagination, and the difference between markdown and json outputs. Examples further clarify parameter usage, making it more helpful than the schema alone.

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?

The description uses a specific verb ('List') and resource ('vision-capable models on OpenRouter'), clearly distinguishing it from sibling tools like analyze_image and check_config. It also notes the filtering by image-input capability, which clarifies the tool's unique scope.

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 provides clear context and concrete examples of when to use the tool ('Which vision models can I use?') and how to narrow results. However, it does not explicitly state when not to use it or mention alternatives, though the sibling list implies them.

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

Install Server

Other Tools

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/quickstraw/vision-helper-mcp-server'

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