picorn_edit_imageTransform an existing image with Flux 2 Klein. Returns an inline preview and public creationUrl.
| Name | Required | Description | Default |
|---|---|---|---|
| cfg | No | ||
| seed | No | ||
| steps | No | ||
| prompt | Yes | ||
| preview | No | ||
| imageUrl | No | ||
| imageBase64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds return behavior ('inline preview and public creationUrl') which is useful and beyond the annotations. However, it does not disclose potential side effects, whether the original is modified, auth requirements, or rate limits. Given the annotations already flag readOnlyHint=false and openWorldHint=true, this additional context is moderate, not rich.
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 exactly two sentences: the first states the action, the second states the return values. There is no fluff, and the information is front-loaded with purpose. Every word 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?
For a 7-parameter tool with no output schema and minimal annotations, this description is too sparse. It omits parameter semantics, input constraints (e.g., whether imageUrl or imageBase64 is required), and any behavioral details beyond the return. The core purpose is clear, but the description does not sufficiently empower an agent to invoke the tool correctly.
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 0%, so the description must compensate for explaining the 7 parameters. It does not explain any of them, leaving the agent to guess the meaning of 'cfg', 'steps', 'preview', and the relationship between 'imageUrl' and 'imageBase64'. While some names are self-explanatory, the description adds no semantic value over the raw schema.
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 'Transform an existing image with Flux 2 Klein' and the title reinforces 'edit an existing image'. This gives a specific verb and resource, and it differentiates from image generation siblings like picorn_generate_image by explicitly mentioning 'existing image'.
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 provides clear context that this tool is for editing existing images, which implies it should be used when an image already exists rather than generating a new one. However, it does not explicitly name alternatives or when-not-to-use conditions, 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.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or operation, with clear boundaries between image generation/editing and the many editor/video actions. Descriptions further clarify any potential overlap, making misselection unlikely.
Most tools follow a verb_noun pattern, but the projects_* tools (create, inspect, update) reverse to noun_verb, and capabilities is a bare noun. This mixed convention is readable but not fully consistent.
With 30 tools, the set exceeds the 25-tool threshold and feels heavy for an MCP server. While the broad scope justifies some size, many tools could be consolidated or split into focused servers.
Core image, editor, and video workflows are covered, but there are notable gaps such as no delete operations for editor/video projects, no update for video projects, and no lifecycle management for imported assets. These missing operations can create dead ends.