Integrates with Google's Gemini API for AI-powered image generation and analysis, enabling proposal diagram creation and iterative refinement.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@paper-banana Generate a CONOPS diagram for the missile defense proposal"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A multiagent AI pipeline for generating process diagrams and CONOPS visuals for government and defense proposals. Based on the Paper Banana framework (arXiv 2601.23265), adapted for proposal-domain aesthetics and distributed as an MCP server.
User Input (proposal text + caption/intent)
|
v
[1] Classifier Agent Determines: process diagram vs. CONOPS image
|
v
[2] Retriever Agent Selects N most relevant examples from library
| (library starts empty; grows via add_example)
v
[3] Planner Agent Synthesizes detailed visual description (few-shot)
|
v
[4] Stylist Agent Applies proposal-specific aesthetic guidelines
|
v
[5] Visualizer Agent Calls gemini-3-pro-image-preview -> generates PNG
| ^
| | (refined description, up to T=3 rounds)
v |
[6] Critic Agent Evaluates image, produces refined description
|
v
Final Image (PNG)
Related MCP server: mmc-mcp
Agent | Model | Role |
Extractor | gemini-3.6-flash | Pulls the relevant section from a full document |
Optimizer | gemini-3.6-flash | Enriches context + sharpens caption (2 concurrent calls) |
Classifier | gemini-3.6-flash | Fast classification, no deep reasoning needed |
Retriever | gemini-3.6-flash | Relevance scoring across examples |
Planner | gemini-3.1-pro-preview | Best reasoning for synthesizing visual descriptions |
Stylist | gemini-3.1-pro-preview | Creative + domain-aware aesthetic refinement |
Visualizer | gemini-3-pro-image | Image generation |
Critic | gemini-3.6-flash | Different model family from Planner/Stylist (anti-bias) |
A Gemini API key with access to the models listed above (get one at aistudio.google.com/apikey)
SSH or HTTPS access to the repo
git clone git@github.com:lexicalninja/paper-banana.git
cd paper-banana
./install.shThe install script will:
Install uv if needed
Prompt for your GOOGLE_API_KEY
Detect Claude Code and/or VS Code and configure them
Optionally seed the example library
On Windows, use install.ps1 instead.
claude mcp add paper-banana -e GOOGLE_API_KEY=your-key -- \
uvx --from "git+ssh://git@github.com/lexicalninja/paper-banana.git" paper-bananaYou can install at the user level (available in every workspace) or the workspace level (scoped to one project).
User-level — edit ~/Library/Application Support/Code/User/mcp.json (macOS) or ~/.config/Code/User/mcp.json (Linux) or %APPDATA%\Code\User\mcp.json (Windows). Add paper-banana inside the top-level servers object:
{
"servers": {
"paper-banana": {
"command": "uvx",
"args": ["--from", "git+ssh://git@github.com/lexicalninja/paper-banana.git", "paper-banana"],
"env": { "GOOGLE_API_KEY": "your-key" }
}
}
}Workspace-level — add the same block to .vscode/mcp.json in your project root. This is safe to commit so teammates get the server automatically.
pip install -e .
export GOOGLE_API_KEY=your-key
paper-bananaAfter setup, the generate_proposal_image and add_example tools will appear in your MCP client.
Generate a proposal diagram image.
Parameter | Type | Default | Description |
| string | required | Communicative intent for the diagram |
| string |
| Raw proposal text to diagram |
| string |
| Path to a document file; |
| string |
| Section heading to extract from |
| string |
|
|
| integer |
| Max visualizer/critic refinement cycles (1–5) |
| string |
| Where to save the generated PNG |
| boolean |
| Save per-iteration PNGs + critique JSON to |
| boolean |
| Append structured diagram YAML/JSON to critique file |
| string |
| Visual identity profile: |
| string |
| Pin output dimensions: |
| string |
| Path to a |
| string |
| Freeform feedback about the prior output; overrides original intent in the critic |
Returns the absolute path to the saved PNG.
Each run saves state to {output_stem}_run/run_input.json. Pass that directory to resume_from to skip the full pipeline and iterate from where you left off:
generate_proposal_image(
caption="",
resume_from="output/my_diagram_run",
user_feedback="Add a decision diamond after step 2 with yes/no branches",
iterations=2
)Use user_feedback to steer the next generation. The pipeline critiques the existing image first, bakes the feedback into a revised description, then generates.
Add a reference image to the example library. The library starts empty; add examples over time to improve retrieval quality.
Parameter | Type | Description |
| string | Written description of what the image shows |
| string | Path to the image file |
| string | Caption associated with the image |
| string |
|
Returns the unique ID assigned to the new example.
The library starts empty (examples/metadata.json contains []). On an empty library, the pipeline proceeds zero-shot (a warning is logged). Use add_example to build up a reference library over time. Retrieval quality improves noticeably after ~5 examples per diagram type.
Two brand profiles ship with the server, selected via the brand parameter.
mlst (default) — MLST purpleToken | Hex | Usage |
Brand purple |
| Primary boxes, borders, headers, flow arrows |
Muted purple |
| Secondary elements, highlights |
Pale purple |
| Interior fill of content boxes |
Blue |
| Data flows, supporting links |
Coral |
| Critical path, key decisions |
Amber |
| Alternate emphasis |
Green |
| Confirmation states, approved paths |
Off-white |
| Page background |
Light gray |
| Swimlanes, grouping zones |
Near-black |
| Body text |
default — government/defenseToken | Hex | Usage |
Navy blue |
| Primary boxes, header bars, key actors |
White |
| Text on dark backgrounds, box interiors |
Gray |
| Connectors, borders, annotations |
Light gray |
| Swimlane backgrounds, grouping zones |
Deep orange |
| Decisions, critical path, highlights |
Teal |
| Data flows, supporting systems, feedback paths |
# Start the MCP server (used by VS Code / Claude Code)
python -m paper_banana.server
# Or via the installed entry point
paper-banana
Add a reference image to the example library.
Args: description: Written description of what the image shows. image_path: Absolute or relative path to the image file. caption: The caption associated with this image. image_type: Diagram type — 'process' or 'conops'. source_context: Optional full methodology text to enrich retrieval scoring.
Returns: The unique ID assigned to the new example.
| Name | Required | Description | Default |
|---|---|---|---|
| caption | Yes | ||
| image_path | Yes | ||
| image_type | Yes | ||
| description | Yes | ||
| source_context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It states the tool adds an image and returns an ID, but does not disclose side effects (e.g., overwrites, storage limits), authentication needs, or error conditions. Basic operation only.
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?
Concise bullet list in docstring format. Each parameter has a short line. Could be more compact, but no extraneous text. Front-loaded purpose sentence is clear.
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?
Covers all 5 parameters and return value. Lacks details on error handling, duplicate handling, size limits, or integration with the example library. Adequate but not comprehensive.
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?
With 0% schema description coverage, the Args section adds meaningful context (e.g., 'Written description of what the image shows' for 'description', 'Diagram type — process or conops' for 'image_type'). However, details like path formats or accepted image types are missing, limiting full semantic clarity.
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 'Add a reference image to the example library,' providing a specific verb and resource. It differentiates from siblings 'generate_proposal_image' and 'get_version' by focusing on adding an image to a library rather than generating or retrieving.
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?
No guidance on when to use this tool versus alternatives. It lacks context about prerequisites, constraints, or situations where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a proposal diagram image using the Paper Banana pipeline.
Provide either source_file (recommended) or source_context — not both.
To resume a previous run, set resume_from to the path of the run-state
directory (e.g. output_run/) created during the original run.
Args:
caption: The caption or communicative intent for the image (required).
source_file: Path to the proposal document (markdown or text). The Extractor
agent will read this file and pull the relevant section automatically.
Recommended over source_context for full documents.
section: Section hint for the Extractor — number, name, or both
(e.g. '1.1', 'Development Services', '1.1 Development Services').
Only used when source_file is provided.
source_context: Raw proposal section text. Use this only when passing a
pre-extracted section directly (not a full document).
image_type: Diagram type — 'process', 'conops', or 'auto' (auto-detected).
iterations: Number of Visualizer ↔ Critic refinement rounds (1-5). Default 3.
output_path: File path where the generated PNG will be saved. Default 'output.png'.
save_artifacts: If True, save per-iteration PNG and critique JSON to
{output_stem}_artifacts/ alongside the final image. Default True.
export_schema: If True (and save_artifacts is also True), extract a structured
diagram schema (elements, connectors, layout) from each iteration's
image and merge it into the critique JSON as 'diagram_schema'. Default True.
brand: Named brand profile to apply — 'mlst' (purple/blue) or
'default' (government/defense palette). Default 'mlst'.
resume_from: Path to a run-state directory ({output_stem}_run/) created by
a previous run. When set, the extractor/optimizer/classifier/
retriever/planner/stylist stages are skipped and the pipeline jumps
directly to the Visualizer ↔ Critic refinement loop using the saved
description, caption, and image type. Leave empty for a fresh run.
user_feedback: Free-text feedback about the previous run's output. Injected as a
prefix into the critic's system prompt so all refinement iterations
take the feedback into account. Only meaningful when resume_from is
also set (but can be used on fresh runs too).
aspect_ratio: Desired output aspect ratio — '16:9', '4:3', '1:1', or '3:4'.
Leave empty (default) to let the Planner recommend a ratio based on
the diagram content. When provided, this hard-overrides the Planner's
recommendation.
Returns: Absolute path to the saved PNG image.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | mlst | |
| caption | Yes | ||
| section | No | ||
| image_type | No | auto | |
| iterations | No | ||
| output_path | No | output.png | |
| resume_from | No | ||
| source_file | No | ||
| aspect_ratio | No | ||
| export_schema | No | ||
| user_feedback | No | ||
| save_artifacts | No | ||
| source_context | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It comprehensively discloses pipeline stages (Extractor, Visualizer↔Critic refinement), default iterations, artifact saving, schema export, and resume behavior. No contradictions.
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 well-structured with an Args section and a Returns line. While somewhat lengthy, every sentence adds value. It is front-loaded with the main purpose and key usage note.
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 13 parameters, no annotations, and presence of an output schema (which description supplements with return path), the description is complete. It covers all inputs, behavior, and output format.
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. It thoroughly explains each of the 13 parameters, including defaults, constraints (mutual exclusivity of source_file/source_context), and purpose. This adds significant value beyond the bare 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 states that the tool generates a proposal diagram image using the Paper Banana pipeline. It clearly distinguishes from siblings (add_example, get_version) by specifying the unique function and pipeline details.
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 explicit guidance: 'Provide either source_file (recommended) or source_context — not both.' It also explains resume behavior and when to use user_feedback. However, it does not explicitly state when not to use the tool or list alternatives beyond siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the current installed version of Paper Banana, with an update notice if behind.
Returns: Version string, e.g. '0.1.0' or '0.1.0 (3 commit(s) behind origin/main — run git pull)'.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses that the tool may return an update notice indicating whether the version is behind, implying it may check remote status. Sufficient transparency for a read-only tool.
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 example output. No wasted words, front-loaded with purpose and return format.
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 zero parameters and existence of an output schema, the description fully explains what the tool returns, making it complete for this simple tool.
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?
No parameters, so baseline is 4. Description adds meaning by detailing the return value format and example, going beyond the empty 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?
Description clearly states 'Return the current installed version of Paper Banana', specifying verb and resource. Differentiates from sibling tools that do not relate to version retrieval.
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?
No explicit alternatives or when-not-to-use, but the tool's function is unambiguous and sibling tools are unrelated, so context is clear. Slight deduction for lack of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0add_examplegenerate_proposal_imageget_versionScored across 3 tools
Each tool has a clearly distinct purpose: generating images, managing examples, and checking version. No overlap or ambiguity.
All tool names follow a consistent verb_noun snake_case pattern (generate_proposal_image, add_example, get_version), making them predictable and easy to understand.
Three tools for a focused image generation pipeline is reasonable. It covers the core workflow and a supporting operation, though slightly minimal.
The set covers the main generate flow and example management, but lacks operations like listing or deleting examples, which limits full workflow coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
MCP-Native LLM Orchestration Agent
