invokeai-mcp

by sandraschi

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct domain (queue, gallery, models, generation, workflows, boards, system), and the operation-based tools (invokeai_generate, invokeai_queue) are clearly separated. Minor overlap exists between show_invokeai_dashboard_card and invokeai_system (both report health/version), but descriptions mitigate confusion.
Naming Consistency3/5
Naming is inconsistent: four tools use a 'show_invokeai_*_card' pattern while the rest use bare 'invokeai_*' nouns with operation parameters. Some tools are verb-like (invokeai_help, invokeai_shutdown), others are noun-objects (invokeai_gallery, invokeai_boards), making the pattern unpredictable.
Tool Count5/5
13 tools is well within the ideal range for a server covering a rich creative domain. Each tool addresses a distinct area (generation, queueing, model management, gallery, workflows, system), and the card-based display tools serve as convenient views rather than redundant functionality.
Completeness4/5
Core workflows are well covered: generation includes txt2img, img2img, inpaint, and upscale; queue handles lifecycle and result retrieval; models support CRUD; gallery and boards manage images; workflows have full CRUD. Minor gaps exist (e.g., no explicit single-image delete outside 'manage' operations, and no batch generation interface), but agents can accomplish tasks without major dead ends.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 31 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (ToolResult with PrefabApp card and plain text fallback), which is useful. However, it does not mention error behavior, empty state, or other operational nuances, so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the core action, and logically structured with a Return Format and Example sections. Every sentence adds value and there is no wasted text.
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?
The tool is simple, has one optional parameter, no output schema, and no annotations. The description explains what it does, the return format, and gives an example, which covers most practical needs. It lacks details about empty results or edge cases, but for a 'show card' tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a description for the 'limit' parameter with default, min, and max, and schema coverage is 100%. The description adds no extra semantic meaning beyond the example call, so the baseline of 3 is appropriate.
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?
The description states a specific verb ('Show') and resource ('most recent gallery images') and clearly distinguishes this from sibling tools like show_invokeai_queue_card or show_invokeai_models_card. However, it does not explicitly contrast with the sibling invokeai_gallery, which could also list gallery images, so it's clear but not fully differentiated.
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?
No guidance is given on when to use this tool versus alternatives such as invokeai_gallery or other show_*_card tools. The description simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a 'graceful' shutdown and specifies the return format, which is useful. However, it does not disclose the destructive consequences (e.g., terminating the server, losing state, irreversibility) or any permissions needed. With no annotations provided, the description carries the full burden and falls short for a shutdown operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. The additional return format and example are directly relevant and help the agent understand the call. No unnecessary information is included.
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?
Given the tool's simplicity (zero parameters, clear purpose, and an output schema), the description provides enough for correct usage. The only gap is the lack of warning about the destructive side effects, but it is otherwise complete.
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?
The tool has zero parameters, so the baseline is 4. The description adds minimal value beyond the empty schema, but the example invocation 'invokeai_shutdown()' clarifies that no arguments are expected, which is sufficient.
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 description clearly states the action ('Gracefully shut down') and the resource ('this MCP server'). It is specific and distinguishes the tool from siblings like show_invokeai_dashboard_card or invokeai_generate, which are all non-shutdown operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the tool's name and description, but there is no explicit guidance on when to use it or mention of alternatives. The sibling tool invokeai_system could potentially handle system-level operations, but the description does not differentiate or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It discloses the output format (PrefabApp card with plain text fallback) but doesn't specify any side effects, permission requirements, or edge cases like empty queue.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise and front-loaded, with a clear first sentence and a compact return-format note and example.
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?
For a zero-parameter, read-only display tool, the description covers purpose, output format, and usage example. It lacks detail about the card's content but is otherwise sufficient given the tool's simplicity.
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?
The tool has zero parameters, so the empty schema is fully covered. The description reinforces this with an example showing no arguments.
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 description clearly states the tool displays the generation queue status as a rich card, using a specific verb and resource. This distinguishes it from sibling card tools for gallery, models, and dashboard.
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?
No explicit when-to-use or comparison with alternatives is provided. The description only gives an example call, leaving the agent to infer when to choose this over other show_*_card tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It does add useful behavior details: a full return format with 'success', 'operation', 'data', 'message', and 'images' arrays, plus a note that URLs are absolute and usable in chat/browser. However, it does not disclose consequences of destructive operations such as 'delete' (e.g., irreversibility, permission requirements) or any rate limits/auth caveats. This is a noticeable gap given the tool includes mutations.
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?
The description is well-structured with a concise summary line followed by rationale, return format, examples, and notes. It is front-loaded with the primary purpose. The rationale and return format are useful, though the description is somewhat long (over 150 words) and could be tightened without losing value. Overall, it is efficient and each section serves a purpose.
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?
Given the tool's complexity (7 params, 8 operations, no annotations), the description provides substantial context: a return format, examples for three operations, and a note about URL behavior. It does not explicitly explain pagination behavior (offset/limit) or error handling beyond the 'message' field, but the schema covers parameters and the examples clarify common usage. The description is reasonably complete for a multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage with descriptions for all seven parameters, so the baseline is 3. The description does not add extra parameter semantics beyond the schema, but it does include one example that demonstrates using 'operation', 'limit', 'query', and 'image_name' in context. This confirms the mapping but does not enrich understanding of parameter values or formats.
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 description opens with a specific verb+resource combination: 'Browse, search, download, and manage generated images.' It explicitly names the gallery feed and per-image actions, and the required 'operation' enum (list, search, get, metadata, download, delete, star, unstar) clarifies the scope. This clearly distinguishes it from sibling tools like invokeai_generate or queue management, which handle different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the gallery is a 'single searchable feed' with per-image actions, and the rationale explains why one tool covers both discovery and mutation. Examples show when to use list, search, and download operations. However, it does not explicitly contrast with sibling tools (e.g., show_invokeai_gallery_card) or state when not to use this tool, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('ToolResult with PrefabApp card; plain text fallback in content'), which is helpful for understanding what the tool produces. However, it does not mention error handling or behavior for invalid/missing model_type, but for a read-only display tool this is a reasonable level of disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear first sentence, a 'Return Format' section, and an 'Examples' section. It uses headers to separate concerns, is front-loaded with the main purpose, and every sentence adds value without unnecessary fluff.
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?
For a simple tool with one optional parameter and no output schema, the description is sufficiently complete: it states the return format and provides an example. It could go further by describing what the card includes (e.g., model names, versions), but the essence is captured. The tool's simplicity means the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%: the only parameter, model_type, has a description listing allowed values ('main, lora, vae, controlnet, spandrel_image_to_image'). The description merely says 'a type' and the example uses 'main', adding no new meaning beyond the schema. Baseline 3 applies because the schema already documents the parameter thoroughly.
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 description states exactly what the tool does: 'Show installed models of a type as a rich card.' This specifies the verb ('Show'), resource ('installed models'), and output format ('rich card'). It also distinguishes from sibling card tools (e.g., show_invokeai_queue_card, show_invokeai_gallery_card) by focusing on models and including an example.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an example call (show_invokeai_models_card(model_type="main")) that implies usage, but it does not explicitly state when to prefer this tool over alternatives like invokeai_models (which likely provides a text list). No when/not-to-use guidance or alternatives are mentioned, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format and includes examples that clarify operation behavior. However, it does not warn about destructive actions (e.g., delete is permanent), permissions, or side effects. The 'shared record store' note is vague and not actionable.
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?
The description is well-structured with a brief opening, rationale, return format, examples, and a note. Each section earns its place, though the phrase 'one portmanteau' is obscure and adds little. It is not overly verbose for the complexity of a 7-operation tool.
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?
The tool has 7 operations and 4 parameters, and the description covers the return format, common examples, and a key reference detail (how to obtain IDs). It does not document every operation in depth, but the pattern is inferable, and the output schema exists to provide return details. Overall, it is sufficiently complete for invocation.
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. The description adds value by showing concrete invocation patterns (e.g., board_id from list, image_names as a list) and pairing parameters with the operations that need them. This goes beyond the schema's field-level descriptions and helps the agent construct valid calls.
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 description opens with a clear, specific verb+resource pair: 'Manage boards (collections of generated images).' It distinguishes this tool from gallery/workflow/etc. siblings by explicitly scoping it to board operations. The rationale reinforces the unique role of boards in the gallery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (any board management task), and provides examples for common operations (list, create, add_image). It does not explicitly mention alternatives or exclusions, but the context is sufficient for most decisions. The note about board IDs coming from list adds a practical prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It does disclose the return format (PrefabApp card, plain text fallback), but it does not explicitly state that the operation is read-only or side-effect-free. The verb 'Show' implies non-mutating, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured: a clear purpose sentence, a brief return format note, and an example. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter display tool with no output schema, the description is complete enough. It specifies what the card shows, the return format, and provides an invocation example, leaving no ambiguity about usage or expected results.
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?
The tool has zero parameters and an empty schema, so the description cannot add parameter-level detail. According to the rubric, 0 parameters gets a baseline of 4; no additional explanation is needed.
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 description uses a specific verb ('Show') and clearly identifies the resource ('InvokeAI fleet status') along with the content covered (version, queue, model counts). This distinguishes it from sibling card tools (queue, gallery, models) by indicating it is the overall dashboard view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit statement about when to use this tool versus alternatives. However, the scope 'fleet status' and the 'dashboard' name imply it is for overall status overviews, which provides indirect guidance but no clear exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (success, operation, data, message, configured) and specifically notes that health returns configured=false when unreachable, which is valuable behavioral context. It does not discuss side effects, but the introspective nature is clear from 'check' and 'introspection.'
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?
The description is well-structured with a clear opening purpose, a rationale section, explicit return format, examples, and notes. It is not overly verbose for the information conveyed. Every section serves a purpose, though the rationale section could be considered slightly meta but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter introspection tool with an output schema, the description is complete. It covers purpose, usage context, return format, examples, and a special case (configuration flag). Sibling tools are clearly different domains, so confusion is unlikely. The description fully equips an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameter is fully documented with an enum. The description adds examples and a note about the health operation, but it does not add deep semantic meaning beyond what the schema provides. Baseline is 3, and the added examples are helpful but not substantial enough to raise it.
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 description clearly states the tool's function with a specific verb and resource: 'Check InvokeAI connectivity, version, and runtime configuration.' It also enumerates the specific operations (health, version, config, stats) and distinguishes itself from sibling tools that focus on queue, gallery, models, or generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by calling it 'the standard first call for onboarding and debugging,' which implies when to use it. It also gives examples and notes about the health operation's behavior. However, it does not explicitly name alternative tools or state when not to use this tool, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does a strong job: install runs asynchronously; polling is done via operation='installs'; the return format is specified; installs may download multiple GB; model_type taxonomy is described. It does not go into depth on delete/update side effects, but the critical async and return behaviors are well covered.
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?
The description is well-structured with sections for rationale, return format, examples, and notes. It is slightly on the longer side but each section earns its place, providing essential operational details without fluff. The front-loaded opening sentence is strong.
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?
Given the tool's complexity (7 parameters, multiple operations, async install, output schema exists), the description is quite complete. It covers the return format, operation set, parameter mapping, sources, and async progress polling. It does not detail every operation's behavior, but the output schema and examples fill most gaps, making this a robust description for a multi-operation 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?
The schema already has 100% coverage for parameter descriptions, so the baseline is 3. The description adds value by mapping operations to required parameters (e.g., source required for install, key for get/update/delete) and by providing examples that show how config overrides are passed. This goes beyond simply restating schema descriptions.
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 description opens with a specific verb+resource: 'Manage installed models in the local InvokeAI instance.' It then enumerates the operations (list, get, install, update, delete, installs, stats) and provides a rationale for why these are grouped. This clearly distinguishes it from sibling tools like show_invokeai_models_card, which is a UI card display, and other domain-specific tools (queue, gallery, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by explaining the model lifecycle domain and giving concrete examples of valid calls (list, install, delete). It also notes accepted install sources and asynchronous behavior. However, it does not explicitly state when *not* to use this tool or directly contrast with the sibling show_invokeai_models_card, so it falls short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does well by disclosing the return format, polling behavior ('polls every 3s up to wait_seconds'), and immediate-return behavior without wait_seconds. It does not detail potential destructive effects of operations like 'clear' or 'cancel', which would warrant a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into clear sections (rationale, return format, examples, notes) and is appropriately sized for a multi-operation tool. Every sentence contributes, with no filler, and the key summary is front-loaded in the first line.
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?
Given the tool has 9 operations and 7 parameters, the description covers many through examples, return format, and polling notes. It could be more complete by explaining each operation explicitly (especially clear, pause, resume), but the schema and examples cover the main use cases, and the output schema exists.
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?
The schema already provides 100% parameter coverage, but the description adds value by giving operation-specific context: wait_seconds is explained with polling semantics, download_image is described as saving locally, and examples show how parameters like status_filter and limit are used. This goes beyond the raw schema.
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 description opens with a clear verb and resource: 'Manage the InvokeAI generation queue and retrieve results.' It explicitly distinguishes the 'result' operation as the natural partner of invokeai_generate, and the rationale explains the grouping of queue lifecycle operations, differentiating it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The rationale and examples provide clear context for when to use the tool and its operations, especially the 'result' operation and wait_seconds for synchronous flows. However, it does not explicitly name alternative tools for non-queue tasks, only implies that invokeai_generate is the upstream partner.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return format as a JSON object with 'success' and 'help' fields, and provides examples of usage. While it doesn't explicitly state read-only behavior or side effects, the nature of 'getting documentation' implies a safe, non-mutating operation, and the return format adds useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-line purpose, a structured return format, and two examples. No wasted words, and the use of headers improves scannability. Every sentence contributes to understanding the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description is complete: it states the purpose, return format, and provides examples. It also mentions that omitting 'topic' returns the index, covering the default behavior. The presence of the return format in the description means no need for a separate output schema explanation.
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?
The schema already describes the 'topic' parameter as 'Help topic, or omit for the index' with 100% coverage. The description adds value by showing concrete examples (invokeai_help() and invokeai_help(topic='tools')), clarifying how the parameter is used and what 'index' means in practice.
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 description clearly states the tool's purpose: 'Get documentation for this server's tools and workflows.' This is a specific verb-resource pair that distinguishes it from sibling tools like invokeai_generate or invokeai_queue, which perform operations rather than provide help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever you need documentation for tools or workflows. It doesn't explicitly compare with alternatives, but as a help tool, its role is self-evident. The context is clear, though no formal when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It discloses the return format, save/update behavior, and that workflow_json must be a full workflow object. It does not mention whether delete is irreversible or how errors are surfaced, but it covers key behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, rationale, return format, examples, and notes. Each section earns its place without redundancy, and critical information is front-loaded in the opening sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a CRUD manager with moderate complexity, and the description covers it fully: operations, return format, examples, save semantics, and required fields. It clearly differentiates from sibling tools, making it adequately complete for an agent to select and invoke correctly.
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 description coverage is 100%, so parameters are already documented. The description adds value beyond the schema by explaining save semantics, requiring a full workflow object, and providing examples that tie parameters to operations. This goes beyond the baseline mid-rating.
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 description opens with a specific verb-resource pair: 'Manage InvokeAI node workflows (list, get, save, delete)', which clearly states the tool's scope. It further distinguishes from siblings by noting that running a workflow graph goes through invokeai_generate or enqueue, so this tool is for the stored library.
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?
The description explicitly provides when and when not to use the tool: 'Running a workflow graph goes through invokeai_generate or a raw enqueue - this tool manages the stored workflow library.' It also clarifies save semantics (create vs update) and gives usage examples for each operation, which serves as clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses that jobs are enqueued and run asynchronously, specifies the return format including how to poll for results, and notes prerequisites like model base determining graph family. It also mentions that upscale uses RealESRGAN 4x, adding behavioral detail.
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?
The description is longer than average but well-structured with headings, bullet lists, examples, and notes. The rationale section justifies why operations are combined, and each section (operations, return format, examples, notes) serves a distinct purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 4 operations, 14 parameters, async execution, and external dependencies, the description covers all essential aspects: operation semantics, parameter requirements, polling instructions, return format, and example calls. It is complete enough for an agent to select and invoke the tool correctly without additional context.
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?
The schema already covers all 14 parameters with descriptions (100% coverage), so the baseline is 3. The description adds value by mapping each operation to its required parameters (e.g., 'img2img: needs image_name, uses strength') and providing concrete examples, which helps the agent understand parameter combinations beyond the schema.
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 description clearly states 'Generate images through the local InvokeAI creative engine' and enumerates four specific operations (txt2img, img2img, inpaint, upscale). It distinguishes itself from sibling tools like invokeai_queue and invokeai_gallery by focusing on image generation, with a clear verb+resource scope.
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?
The description explicitly explains when to use each operation (e.g., img2img needs image_name and strength, inpaint needs mask_image_name), states that all paths share one enqueue flow, and instructs the agent to poll invokeai_queue for completion. It also lists prerequisites (InvokeAI running, model installed), giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![invokeai-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/invokeai-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sandraschi/invokeai-mcp)

Score Badge

Copy to your README.md:

[![invokeai-mcp MCP server](https://glama.ai/mcp/servers/sandraschi/invokeai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sandraschi/invokeai-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sandraschi/invokeai-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server