Skip to main content
Glama

Revisar prompt de imagem/vídeo

revisar_prompt_visual
Read-only

Audit image or video prompts against validated visual rules to catch cuts, metaphors, real logos, or identity issues; get a score, problems, and an improved prompt.

Instructions

Audita um prompt de placa (imagem) ou de movimento (vídeo) contra as lições dos prompts validados: plano contínuo sem cortes, descrição física em vez de metáfora, mudança espalhada pelo clipe, câmera com destino, placas como edits, sem texto/marcas reais, identidade de pessoas, inglês. Devolve nota, problemas e versão melhorada.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tipoNo
modeloNo
promptYes
assuntoNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.2/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true), so the bar is lower, and the description goes beyond by disclosing the actual return payload: nota, problemas e versão melhorada. That is genuinely useful behavioral context, particularly in the absence of an output schema.

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-loads the verb and the audit target before the criteria list, and the criteria are compact comma-separated fragments rather than prose. It is a long list, but each item carries distinct content and nothing is redundant.

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

Completeness3/5

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

It covers purpose, criteria and return shape, which is decent for a read-only auditor. But with 0% schema coverage on 4 parameters and no output schema, the omission of parameter meaning (modelo, assunto) leaves a real gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 4 parameters, so the description must compensate, but it only clarifies the tipo enum (placa=imagem, movimento=vídeo). It never explains modelo, assunto, or prompt, leaving three parameters semantically dark.

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 (audita) and resource (um prompt de placa para imagem ou de movimento para vídeo), and distinguishes the two modes. The purpose is unmistakable and clearly distinct from project/site siblings, though it doesn't explicitly name an alternative tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists the audit criteria but never says when to invoke this vs alternatives, nor any preconditions (e.g. run before generating, after a failed render). Usage is only implied by the subject matter.

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