Skip to main content
Glama
veniceai

Venice MCP Server

Official
by veniceai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Venice List Models

venice_list_models
Read-onlyIdempotent

List live Venice AI model catalog entries page by page, filter by type, and inspect context length, capabilities, privacy, and pricing.

Instructions

List the live model catalog, one page at a time. Omitting type lists every model type (sent upstream as type=all). Each entry is a compact summary (id, type, name, context length, enabled capabilities, traits, privacy, pricing); set verbose=true for the full upstream model objects. Returns total, next_offset, and every matching model id in ids; call again with offset=next_offset until next_offset is null. No authentication required.

Input Schema

NameRequiredDescriptionDefault
typeNoCatalog type: text, image, inpaint, upscale, video, music, tts, asr, embedding, decision, "code", or "all" (default). Without a type Venice returns only text models, so pass one to find video, image or audio ids.
limitNoMax models per page. Defaults to 50. A page may hold fewer when entries are large; follow next_offset.
offsetNoIndex of the first model to return. Defaults to 0.
verboseNoReturn full upstream model objects instead of compact summaries. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.3.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "Max models per page. Defaults to 50. A page may hold fewer when entries are large; follow next_offset.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Index of the first model to return. Defaults to 0.",
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / type / description
      Added value: +"Catalog type: text, image, inpaint, upscale, video, music, tts, asr, embedding, decision, \"code\", or \"all\" (default). Without a type Venice returns only text models, so pass one to find video, image or audio ids."
    • removedInput schema / properties / type / enum
      Removed value: -[
-  "text",
-  "image",
-  "video",
-  "audio",
-  "music",
-  "embedding",
-  "all"
-]
    • addedInput schema / properties / type / maxLength
      Added value: +64
    • addedInput schema / properties / type / pattern
      Added value: +"^[a-z][a-z0-9_-]*$"
    • addedInput schema / properties / verbose
      Added value: +{
+  "description": "Return full upstream model objects instead of compact summaries. Defaults to false.",
+  "type": "boolean"
+}
  2. First observedv0.2.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds valuable context beyond them: 'No authentication required', the upstream type=all behavior, the pagination contract, and the shape of returned entries. Only missing piece is any error or rate-limit behavior.

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?

Front-loaded with the core action and dense but purposeful; the pagination instruction and return-shape sentence each earn their place. Slightly heavy on semicolon-chained clauses, but nothing is wasted.

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 output schema, the description carries the return contract itself — naming total, next_offset, ids, and the compact-summary fields — and explains the pagination termination condition. An agent has everything needed to call and iterate correctly.

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%, so baseline is 3, but the description adds real nuance: it resolves the apparent tension in the schema by explaining omission is sent upstream as type=all, and clarifies that verbose switches between compact summaries and full objects beyond the schema's terse wording.

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?

States a specific verb and resource ('List the live model catalog') and clarifies the scope (one page at a time, compact summaries). An agent can distinguish it from detail-oriented siblings like venice_model_details or venice_model_traits, though the description never names those alternatives explicitly.

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?

Gives clear operational context: omitting type fetches all types, and gives an explicit pagination loop ('call again with offset=next_offset until next_offset is null'). It does not, however, state when to prefer this tool over sibling catalog/inspection tools.

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

Deploy Server

Other Tools