Skip to main content
Glama

List image models

list_image_models
Read-only

Lists available static image-ad models with their reference-image support and aspect ratios so you can retrieve the right model ID before generating an image ad.

Instructions

List every available static image-ad model, its reference-image support and aspect ratios. Call this to retrieve available model ids before calling generate_image_ad.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
modelsYes
defaultModelYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A4.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description's added behavioral value is limited to naming the returned attributes, which the output schema already carries, and it says nothing about ordering, pagination or whether the list is brand-scoped. Some value added, but not much beyond structured fields.

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 sentences, both earning their place: the first defines the payload, the second defines the call sequence. The return content is front-loaded before the usage instruction, which is the right order for a discovery tool.

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?

With no parameters, full annotation coverage and an output schema describing the return shape, the description supplies everything else an agent needs: what the list contains and where it sits in the workflow. Nothing material is missing for a zero-arg discovery endpoint.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. It does not misrepresent any input, and correctly implies the call is unfiltered.

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?

Uses a specific verb ('List') with a precisely scoped resource ('every available static image-ad model'), and even enumerates what attributes come back (reference-image support, aspect ratios). The word 'static image-ad' implicitly separates it from the sibling list_video_models, so an agent can pick the right lister without opening either schema.

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 states the trigger and the downstream step: 'Call this to retrieve available model ids before calling generate_image_ad.' That gives a clear sequencing rule rather than leaving the agent to infer it. It stops short of naming when-not-to-use or pointing at list_video_models as the alternative, so it is a strong 4 rather than a 5.

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