Skip to main content
Glama

framesail

by com.framesail
OverviewDiscussions(1)Admin

List models

list_models
Read-onlyIdempotent

List the models allowed for a generation job, with display names, credit estimates, and each model's settings_schema — the valid keys for that tool's settings param (e.g. image quality/orientation, video duration). When model is omitted the server picks: the scope's saved expert-drawer choice if one exists, else the account's default for the job (set on the account page), else the first entry here. The list is personalized — the account default is listed first with its saved settings as the schema defaults. Jobs whose models split into families (voice_block by provider, segment_video by lip_sync) are personalized only when you name the family, since the account default is stored per family. Voice models carry a provider field — a voice_block model must match the project's voice_tts_provider or generate_voiceover rejects it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
jobYesGeneration job whose allowed models to list, e.g. "script", "storyboard", "segment_image", "segment_video", "voice_block"
lip_syncNosegment_video only: whether the shot is lip-synced to the narration (the asset's config.lip_sync). Video models split on it, so pass it to get that family's list and the account default for it.
providerNovoice_block only: the project's voice_tts_provider ("minimax" or "elevenlabs"). Voice models split by provider, so pass it to get that family's list and the account default for it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / lip_sync
      Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "segment_video only: whether the shot is lip-synced to the narration (the asset's config.lip_sync). Video models split on it, so pass it to get that family's list and the account default for it.",
+  "title": "Lip Sync"
+}
    • addedInput schema / properties / provider
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "voice_block only: the project's voice_tts_provider (\"minimax\" or \"elevenlabs\"). Voice models split by provider, so pass it to get that family's list and the account default for it.",
+  "title": "Provider"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / job / description
      Added value: +"Generation job whose allowed models to list, e.g. \"script\", \"storyboard\", \"segment_image\", \"segment_video\", \"voice_block\""
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already cover the safe read-only profile, yet the description adds substantial behavior beyond them: the deterministic default-resolution order (saved expert-drawer choice > account default > first entry), personalization ordering, family-level personalization, and the hard constraint that a voice_block model must match the project's voice_tts_provider or generate_voiceover rejects it. That last item is a cross-tool failure condition an agent cannot infer elsewhere.

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?

Purpose is front-loaded in the first sentence, and the remaining lines each carry distinct information (defaults, personalization, family behavior, provider constraint). It is dense and slightly clause-heavy, but no sentence is filler.

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 compensates by describing the returned data (display names, credit estimates, per-model settings_schema) and how entries are ordered. Combined with full param coverage, an agent has everything needed to call and interpret this tool 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 the baseline is 3, but the description adds meaning not in the schema — chiefly the default-resolution behavior when `job`... is unspecified, and the rationale for the optional family params. It reinforces rather than merely repeats the schema's own lip_sync/provider hints.

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?

States a specific verb and resource ('List the models allowed for a generation job') and goes further to enumerate what the listing contains (display names, credit estimates, settings_schema). This clearly separates it from sibling list_* tools like list_voices/list_styles and tells an agent it is the model-enumeration call for a job.

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?

Explains the selection semantics when `model` is omitted and, more importantly, states when to pass the family parameters (lip_sync for segment_video, provider for voice_block) and why — 'personalized only when you name the family'. It does not name alternative tools or explicit exclusions, but the when-to-pass guidance is concrete and actionable.

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

All framesail toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources