Skip to main content
Glama

Recommend MaxVideoAI models

recommend_models
Read-only

Use this when the user is undecided or asks for advice on which AI video/image model fits a creative goal. Present the best-fit available executable model first, then strong alternatives from distinct model families when useful. Validate the selected mode with get_model_details. Nullable constraints must be null or omitted when unstated, never placeholders. Ask only for missing choices that change the result or budget. Clarify whether quality means story coherence, multi-shot continuity, reference/character fidelity, motion, audio or delivery resolution; never rank creative quality by resolution alone. Use calculate_project_budget on comparable proposals before calling an option cheaper or lower-cost. Mix models only when each shot has a factual rationale; do not force diversity or dilute a quality-first plan. Do not use when the user already chose a compatible model for validation, pricing or execution. Never substitute a named model without user approval. Use returned editorialGuidance: reference entries are reviewed starting points, alternative entries serve meaningful tradeoffs, and on_request entries are for explicit requests. Inspect reviewStatus, reviewedAt, rationale and provenance. Editorial preference is not measured quality or execution certification; a new version never inherits a review from its family. An idea, a prompt or a single asset can be a complete outcome; do not require a film or a multi-step recipe. Recommendations are capability matches with disclosed editorial preference. Do not use as an exact quote, generation command or guarantee that a provider will accept a request. Respect executable constraints and the user’s choice.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoExact public model ID to consider, or null unless the user named one.
modeNoRequested generation mode, or null unless the user constrained it.
audioNoWhether the user explicitly requires or excludes audio, or null when unstated.
surfaceNoRequested media surface, or null unless the user constrained it.
useCaseNoCreative goal used only with reviewed MaxVideoAI model guidance, or null when unstated.
prioritiesNoOrdered user-stated factual priorities, most important first, or null when none of these values matches. For beautiful cinematography, expressive acting or smooth camera movement without an explicit listed priority, use null. highest_resolution requires a delivery-resolution preference such as 4K; it is not a proxy for overall creative quality. lower_cost requests a budget comparison when cheaper options are explicitly wanted. Asking what a project costs does not mean prefer the cheapest: keep priorities null and use calculate_project_budget for the estimate.
resolutionNoRequested resolution, or null unless the user constrained it.
aspectRatioNoRequested aspect ratio, or null unless the user constrained it.
maxDurationSecNoMaximum duration requested by the user, or null. Never use 300 as a placeholder.
referenceImagesNoWhether the user explicitly requires or excludes reference images, or null when unstated.
excludedModelIdsNoUp to ten public model IDs to leave out of the recommendations, or null.
preferredModelIdsNoUp to ten public model IDs the user would like considered when compatible, or null.
budgetCeilingCentsNoProject budget ceiling in cents, or null when unstated; use calculate_project_budget for current comparable totals.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / priorities / description
      Previous value: -"Ordered user-stated factual priorities, most important first, or null when unstated. highest_resolution applies only when delivery resolution matters and is not a proxy for overall creative quality. Use lower_cost to request a project budget, not a price guess."New value: +"Ordered user-stated factual priorities, most important first, or null when none of these values matches. For beautiful cinematography, expressive acting or smooth camera movement without an explicit listed priority, use null. highest_resolution requires a delivery-resolution preference such as 4K; it is not a proxy for overall creative quality. lower_cost requests a budget comparison when cheaper options are explicitly wanted. Asking what a project costs does not mean prefer the cheapest: keep priorities null and use calculate_project_budget for the estimate."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare read-only/non-destructive; the description goes well beyond that by disclosing that output is a capability match with editorial preference, that editorial preference is not measured quality or execution certification, that a new version never inherits a family review, and by decoding returned editorialGuidance/reviewStatus/reviewedAt/rationale/provenance. It also states the mutation-adjacent constraint of not asking for placeholders and not forcing model diversity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense wall of text with the usage trigger front-loaded, which is good, but it repeats the same caveat family multiple times (editorial preference is not quality; not an exact quote/generation command; recommendations are capability matches) and mixes call-time guidance with output-interpretation guidance. For an advisory tool the volume is heavier than needed and sentences blur together.

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?

No output schema exists, so the description carries extra weight and does explain the key returned concepts (editorialGuidance categories, reviewStatus, reviewedAt, rationale, provenance) plus the mode-validation and budget-comparison workflow. It stops short of describing the full response shape or failure modes, leaving a small gap for a 13-parameter tool.

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 cross-parameter interpretation rules the schema does not fully carry: nullable constraints must be null or omitted rather than placeholder values, and only missing choices that change result or budget should be asked for. It reinforces meaning for priorities and budgetCeilingCents by routing cost questions to calculate_project_budget instead of filling lower_cost.

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 opening sentence states a specific function (advise on / recommend AI video-image models for a creative goal) and distinguishes it from siblings by naming get_model_details for validation and calculate_project_budget for pricing. An agent can tell instantly that this is an advisory recommender, not a lister (list_models) or a detail lookup (get_model_details).

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?

Explicit trigger ('when the user is undecided or asks for advice'), explicit exclusion ('Do not use when the user already chose a compatible model for validation, pricing or execution'), and named alternatives with conditions for delegating to get_model_details and calculate_project_budget. It also states a hard rule: never substitute a named model without user approval.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.