Codex ImageGen MCP

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

The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is clear. The description adds valuable behavioral context: that it costs no image quota, which is not in annotations. This extra detail helps the agent understand the cost-free nature of the call, but it doesn't describe other behavioral traits like response format, which is acceptable given no 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.

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

The description is concise, front-loaded with the core purpose, and includes a clear usage trigger. Every sentence serves a purpose: defining the tool, noting the non-cost, and specifying when to call it. No wasted words.

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

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

For a read-only status tool with no required parameters and full schema coverage, the description is complete. It covers what it reports, the absence of quota cost, and when to use it. The output format is not described, but without an output schema, this is acceptable for a simple status check. The tool is simple enough that nothing critical is missing.

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

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

Schema description coverage is 100%, so the schema fully documents the 'check_usage' parameter. The description does not add additional meaning beyond the schema, but it does mention usage-limit windows, which aligns with 'check_usage'. Since the schema is complete, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: shows sign-in status, account/plan, credential source, and usage-limit windows. It distinguishes itself from siblings like sign_in and generate_image by focusing on status rather than action. However, it could be slightly more specific about the tool's name, but the resource is clear.

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

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

The description explicitly tells when to use this tool: when another tool reports an auth or quota problem, or after sign_in. This provides clear context and routes the agent correctly. It also implies when not to use it (e.g., for actual image generation), which is helpful.

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

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

Beyond the annotations, the description adds meaningful behavioral context: the operation uses the user's ChatGPT plan with no API key, the input file is never modified, and the result is saved as a new file. This complements destructiveHint=false and readOnlyHint=false without contradicting them.

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

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

The description is dense but efficient: core capability first, then usage protocol, then example use cases, then a safety guarantee. Every sentence contributes, and no space is wasted on restating the title or repeating schema details.

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

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

For a tool with 9 parameters and rich schema documentation, the description is largely complete: it covers the core workflow, prompt construction, non-modifying behavior, and output-file semantics. The only minor gap is explicit routing to sibling tools such as remove_background or generate_image in edge cases, but the strong schema compensates elsewhere.

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

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

Schema coverage is already 100%, so the baseline is 3, and the description adds extra value by specifying the prompt convention ('Image 1, Image 2…') and the Image 1 primary-target rule. It also clarifies that edits should explicitly preserve unchanged content, which is not fully captured by the schema's brief prompt example.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb-resource pair: 'Edit or transform existing images, or create a new image guided by reference images.' It enumerates concrete use cases and clearly distinguishes this reference-driven editing/creation tool from a plain text-to-image generator by requiring 1-5 reference images.

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

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

The description gives explicit, actionable guidance: pass 1-5 images, refer to them as Image 1, Image 2..., keep Image 1 as the primary target, and state both what must change and what must stay unchanged. It does not explicitly name sibling alternatives like generate_image or remove_background, but the intended context is clear and practical.

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

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

Beyond the annotations, the description discloses important behaviors: it saves the full-resolution file, returns a path plus preview, lets the service choose resolution and quality, typically takes 15-60 seconds, and requires no API key while using the user's ChatGPT plan. It also notes that the service controls resolution, which is useful operational context and contradicts nothing in the annotations.

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

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

The description is four tight sentences with no filler. It front-loads the core purpose, then adds useful behavioral and usage details (output, resolution control, alpha guidance, expected latency) in order of importance.

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

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

Given the rich input schema, output schema, and annotations, the description is complete enough for an agent to invoke the tool correctly. It covers what the tool creates, how the result is returned, how to control key parameters, quota/cost context, and expected runtime. No critical call-related detail is missing.

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

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

Schema coverage is 100% and each parameter already has rich descriptions, so the baseline is 3. The description adds extra meaning by explaining when transparent backgrounds are appropriate, how aspect_ratio can steer orientation, and that multiple variants count against quota. That additional context lifts it above baseline, though the schema already does most of the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Generate') and resource ('new raster image'), enumerates concrete use cases (photo, illustration, texture, sprite, mockup, icon, product shot), and emphasizes that it creates a new asset rather than editing one. This makes it clearly distinct from the sibling edit_image and remove_background tools.

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

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

It provides clear context for when to use the tool: to create raster images from a text prompt and save them with a preview. It also gives targeted guidance such as using background="transparent" for assets needing alpha and steering orientation with aspect_ratio. However, it never explicitly contrasts with edit_image or remove_background or states when not to use it, so it stops short of a 5.

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

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

The description discloses local execution ('no network, no quota') and the key color sampling behavior ('sampled from the image border unless key_color is given'), adding value beyond annotations. Annotations already cover readOnly/destructive/idempotent hints, and the description does not contradict them. It doesn't mention overwrite behavior, but that's in the schema.

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

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

Two sentences with zero fluff. The core function and key differentiator (local, no quota) are front-loaded; the usage guidance and sampling detail follow logically. Every clause earns its place.

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

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

Given 12 parameters but 100% schema coverage and no output schema, the description covers purpose, usage, and one parameter's default behavior. It also names alternatives. It doesn't explain return values, but without an output schema that's not required. The tool is well-scoped and the description is sufficient.

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

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

Schema description coverage is 100%, so all 12 parameters are documented there. The description adds context only for key_color (border sampling) and mentions input_path implicitly. Per the rubric, high coverage sets a baseline of 3, and the description adds a small increment for key_color but nothing for other parameters like despill or soft_matte.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a precise verb-resource pair: 'remove a flat, solid-color background from a PNG/JPEG and save a transparent PNG'. It distinguishes from siblings by explicitly recommending generate_image/edit_image with background='transparent' for new asset creation, making its niche clear.

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

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

It gives explicit usage scenarios: 'Use for images with a uniform backdrop' or 'to clean up a cutout'. It also provides a clear exclusion: 'Prefer background="transparent" on generate_image/edit_image when creating new assets', so an agent knows exactly when to pick this tool over alternatives.

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

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

Annotations already convey read-only false, open-world true, idempotent true, and non-destructive. The description adds valuable behavioral context beyond those flags: it returns a user-facing link or code that must be relayed verbatim, sign-in completes in the background, and auth_status is the confirmation mechanism. This is solid but stops short of describing failure modes or timeouts.

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

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

The description is three sentences with no wasted words. It front-loads the purpose and prerequisite, then explains the output and follow-up action. Every sentence earns its place.

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

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

Given there is no output schema, the description correctly explains what the agent will receive (link or code) and how the user must act on it. It also tells the agent to call auth_status to confirm completion. This is nearly complete, though it could mention what to do if the user fails to complete the sign-in or if the returned link/code expires.

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

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

Schema description coverage is 100%, so the parameters are already fully documented with their defaults and meanings. The description reinforces the browser/device distinction without adding materially new parameter-level semantics. The 'relay it verbatim' instruction is about the output, not the parameters, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (starting sign-in), the resource (the image server's ChatGPT account), and the prerequisite context (required before generating unless an existing sign-in is detected). It also clearly distinguishes sign_in from the sibling auth_status by explaining that auth_status is the follow-up confirmation step.

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

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

The description gives clear context: sign-in is needed once before generating, unless an existing sign-in is detected, and auth_status should be called afterward to confirm. It does not explicitly tell the agent to check auth_status before calling sign_in, but the 'unless an existing sign-in is detected' phrasing implies that pre-check. Slightly more explicit when-not-to-use guidance would earn a 5.

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