sd-api-mcp

by mcaimi

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct operations (sync generation, async submission, batch, compare, merge variants), and descriptions clarify the differences. A few near pairs such as generate_image/submit_generate and batch_merge_models/recipe_merge could cause misselection, but the descriptions separate them well.
Naming Consistency3/5
The dominant verb_noun pattern (list_models, get_job_status, merge_models) is readable, but there are notable deviations like health_check, system_info, recipe_merge, and submit_generate. The mix of verb-first and noun-first names is inconsistent enough to slow an agent down.
Tool Count4/5
Eighteen tools is slightly above the ideal 3-15 range, but the breadth is justified by covering generation, async jobs, model metadata, system health, and model merging. It feels like a complete API surface rather than an inflated one.
Completeness4/5
The surface covers generation, inpainting, async job lifecycle, model listing/metadata, schedulers, and multiple merge workflows. Obvious gaps are minor, such as the lack of a general image-to-image tool or batch async variants, but core workflows have no dead ends.
Average 3.8/5 across 18 of 18 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description emphasizes the difference between 'status' and 'result' but never explains it, leaving the behavioral contract (blocking? error semantics? readiness) undefined. With no annotations to fill in the gaps, the description carries the full burden and falls short of clarity.
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 a tight two sentences; it front-loads the action and resource, then tucks parameter documentation away in a nested Args block that preserves skimmability. Nothing is wasted, and nothing essential is missing.
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?
For a simple get-by-identifier operation, the description is adequate but thin—it doesn't mention error conditions or the shape of the result, although the output schema may cover the latter. The description gives no warning about potential unavailability of a 'result' while processing is still ongoing, a likely pitfall.
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 description identifies the job_id as 'returned when the job was submitted,' resolving ambiguity about its origin. The schema merely labels it 'Job Id,' so this detail adds genuine signal and is valuable to a model.
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 verb 'Get' and resource 'status and result of a specific job' are clear and unambiguous, and the word 'specific' helps set it apart from list-style siblings like list_jobs. It's a recognizable get-by-identifier pattern that is easy to act on without confusion.
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 offers no guidance on when to prefer this tool over alternatives such as list_jobs or cancel_job, nor does it explain the polling or persistence semantics. A developer is left to infer that this is a getter associated with submissions from sibling tools like submit_generate, a connection the text never draws.
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 present, so the description carries the full disclosure burden. It states the tool lists models and gives filter scope, but it doesn't expose aspects such as ordering, pagination, rate limits, or confirm the read-only nature beyond the word 'List'. This adds some behavioral context but remains minimal.
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 short and well-structured, with a leading sentence and two concise parameter lines. Every element contributes. A tiny bit more context on usage could be added without bloating the text, so it's not perfect but highly efficient.
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?
The output schema covers return values, avoiding the need to describe them. All parameters are documented, and the tool is low complexity (2 params). However, given the rich set of sibling tools like get_model_metadata and compare_models, the description lacks contextual guidance on when this checking function is 'the' right choice.
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 has no parameter descriptions (0% coverage), but the description compensates well by explaining both parameters with explicit value prompts (e.g., 'sd15' or 'sdxl', 'checkpoints', 'loras', or 'vaes'). This gives essential meaning, though it falls short of describing exact combination rules or default behavior.
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 uses a specific verb 'List' and a clear resource 'models', and the parameter explanations make the scope explicit (list by architecture and resource category). It doesn't mention siblings explicitly, but its function is clearly differentiated from tools like get_model_metadata or compare_models.
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?
There is no guidance on when to use this tool versus alternatives, no preconditions, and no context about its role in workflows (e.g., fetching IDs before generation). The parameter descriptions imply a lookup, but an agent gets no explicit when/when-not cues.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'Waits for completion' which hints at synchronous behavior)Skip but doesn't explain what happens on failure, whether intermediate results are persisted, permission requirements, or how the output checkpoint is created. For a lengthy multi-step operation, critical behaviors like blocking, error handling, and side effects are unspecified.
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 concise, front-loads the core purpose in the first sentence, then provides a compact parameter list. Each sentence earns its place, though some parameter details (e.g., allowed method values) are missing from the text.
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?
The description gives a good overview (multi-step merge, wait-for-completion behavior) and parameter meanings, but omits key details such as the allowed values for 'method' or 'model_type', how the steps chain and whether intermediate results are preserved, and any error/timeout behavior. Since an output schema exists, return values are presumably covered there, but the multi-step merge semantics and options need more depth.
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 has zero property descriptions (coverage 0%), so the description compensates well. It explains each parameter's meaning: model_type as architecture, base_model as checkpoint, output_name as final output, and steps as objects with target_model, method, and alpha (float 0-1). This goes beyond the bare schema and provides the essential semantics needed to invoke the tool correctly.
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 clearly states the tool's function: 'Execute a multi-step merge recipe' with each step merging the current result with a new target. This is a specific verb+resource combination that distinguishes it from a single-step merge tool, though it doesn't explicitly name sibling tools like merge_models or batch_merge_models.
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 implies usage context by mentioning 'multi-step' recipe and 'waits for completion', suggesting this is for sequential merges rather than single or batch parallel merges. However, it doesn't explicitly state when to use this vs. merge_models or batch_merge_models, nor any prerequisites or when-not-to-use guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says only 'cancel' and restricts the job state to pending or running; it does not mention side effects, whether cancellation is irreversible, what happens to associated resources, or error behavior for invalid or terminal job IDs.
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 compact: an introductory action sentence followed by a single parameter line. There is no filler, and the key action is front-loaded, making it immediately scannable for an agent.
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?
Given the tool has a single required parameter and an output schema exists, the description does not need to explain return values. However, with no annotations, it omits behavioral context like cancellation semantics and error cases; this is a gap, though the tool's simplicity makes the description minimally viable.
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 has 0% description coverage, so the description must supply parameter meaning. It states that job_id is 'the job identifier to cancel,' which provides useful intent but largely restates the parameter name and title; no format, example, or guidance for obtaining the identifier is given.
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 and resource: 'Cancel a pending or running job.' It clearly identifies the operation and distinguishes it from sibling tools such as list_jobs, get_job_status, and submit_generate, none of which perform cancellation.
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 phrase 'pending or running job' implies when the tool should be used and that completed or already-canceled jobs are out of scope. However, it does not explicitly state alternatives or provide when-not-to-use guidance, leaving usage conditions implied rather than explicit.
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 the full burden of behavioral disclosure. It does disclose the blocking nature ('Waits for completion and returns the result') and encodes validation constraints (width/height ranges, seed -1 semantics, loras structure). But it omits operational realities such as expected runtime, compute cost, failure modes (missing checkpoint, generation errors), and whether inputs are validated server-side.
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?
One purpose sentence followed by a scannable, Google-style Args block covering all 12 parameters without redundancy. Every line earns its place by adding a range or value hint, and the text is neither bloated nor under-specified.
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?
The parameter surface is thoroughly covered, and the output schema handles return-value expectations, so nothing about arguments is missing. What is missing for a complex 12-parameter generation tool is routing context: when to prefer this over submit_generate or batch_generate, and what operational cost/latency to expect from a blocking GPU call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — no property is documented in the schema — and the description compensates fully. It enumerates valid pipeline values ('sd15', 'sdxl', 'illustrious'), gives numeric ranges (256-2048, 1-150, 1-30), explains seed -1 semantics, and defines the nested loras structure (name + optional strength 0-1). This is exactly the compensation a low-coverage schema requires.
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 opens with a specific verb and resource ('Generate an image using Stable Diffusion') and adds a behavioral differentiator: 'Waits for completion and returns the result,' which separates it from the async submit_generate sibling. However, it never names the siblings it is not, so the differentiation remains implicit rather than explicit.
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 on when to call this tool versus its alternatives. With submit_generate, submit_inpaint, and batch_generate present, an agent must infer that this is the synchronous single-image path; the description never states exclusions, conditions, or the async alternative, so the sync/async choice is left entirely to the agent.
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 carries the burden of behavioral disclosure. The verb 'Get' and 'current' signal a read-only snapshot of app configuration, but no details are given about scoping, default behavior, or potential error conditions. This is acceptable for a trivial no-param getter but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that says exactly what the tool does with no filler or repetition. Every word earns its place.
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 getter with an output schema, the description is mostly sufficient. It lacks explicit context about how 'application configuration' differs from system-level info, but the overall picture is complete enough for an agent to invoke it 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?
The tool takes zero parameters and the input schema is empty, so the baseline is 4. The description correctly implies no inputs are required and adds no misleading parameter information.
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 clear verb ('Get') and resource ('current application configuration parameters'), making the tool's purpose obvious. It does not explicitly contrast with sibling tools like system_info or health_check, but the resource is distinct enough for basic disambiguation.
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 call this tool versus alternatives such as system_info or list_models. The description implies a simple read operation, but it does not state contexts, exclusions, or preferred alternatives.
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 the burden of behavioral disclosure. The word 'Get' implies a read-only operation and the response categories are listed, but there is no explicit statement about side effects, permissions, or failure behavior. This is adequate for a simple info endpoint but not richly transparent.
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?
One sentence, front-loaded with the operation and resource, then a compact list of content areas. Every word adds information; no filler or redundancy.
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 parameterless tool with an output schema, the description does not need to explain return values, and it correctly identifies the main response categories. It is slightly incomplete only in that it doesn't provide routing guidance among the many sibling tools.
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 input schema has zero parameters, so there is nothing for the description to document. A 0-parameter tool gets a baseline of 4 because parameter semantics are trivially satisfied.
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 uses a clear verb-resource pair ('Get system information') and enumerates specific content areas: GPU device, dtype, model cache stats, and job queue stats. This gives enough detail to tell it apart from generic health or job-list siblings, though it never names an alternative explicitly.
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?
There is no statement about when to choose system_info instead of the many siblings such as health_check, list_jobs, get_job_status, or list_models. The description only states what the tool returns, leaving the agent to infer the appropriate use case.
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 exist, so the description carries the full behavioral burden. It does disclose the most important trait — synchronous blocking until completion — which is genuinely valuable. However, for a GPU-bound image operation it stays silent on timeouts, resource intensity, failure semantics, or payload size constraints, which an agent might reasonably need to choose this over alternatives.
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 behavioral summary is front-loaded in one crisp sentence, followed by a conventional param-per-line docstring. Each line earns its place with additional detail. Minor deduction: entries like 'model_checkpoint', 'scheduler', and 'custom_vae' mostly restate their names, and the docstring could be trimmed slightly, but nothing is redundant enough to hurt.
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?
Across description and schema, an agent has everything needed to call this correctly: valid pipeline strings, the masking convention, LoRA structure, and defaults. The existence of an output schema covers return-value details. Gaps like expected base64 format (raw vs data URI) and image dimension limits exist, but for moderate-complexity tooling, the documentation is strong.
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?
With 0% schema description coverage, the description must compensate fully — and it does. It captures the white=mask convention for mask_base64, enumerates valid pipeline values (sd15/sdxl/illustrious), gives ranges (1-150, 1-30), documents the -1 random seed sentinel, and explains the LoRA config structure. Nearly every parameter gains meaning beyond its name.
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 pairs a specific verb+resource+method ('Inpaint an image using Stable Diffusion') with a key differentiator ('Waits for completion and returns the result') that separates it from the async submit_* siblings. It doesn't name the sibling explicitly like the gold standard, but the synchronous/blocking qualifier makes the distinction clear.
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?
'Waits for completion and returns the result' is a genuine usage signal that implies contrast with submit_inpaint and cancel_job, telling the agent this is the synchronous inpainting path. However, it's implied rather than stated — there's no explicit 'use this for X, use submit_inpaint for Y' guidance despite the pair being the most obvious alternative.
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?
With no annotations, the description must carry the burden of behavioral disclosure. It only reveals that the operation is a 'Submit' and that batches are capped at 10. It does not describe asynchronous/job behavior, returned job identifiers, partial failure behavior, validation, or resource cost semantics. The 10-item cap is useful, but it is the only meaningful behavioral detail beyond the obvious 'submit' action.
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 a single purpose line followed by a compact Args block with only two parameters. Every sentence adds needed information: the batch nature, the limit, pipeline values, and required per-request fields. There is no repetition of schema property names or off-topic filler.
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?
Given the small parameter count and the presence of an output schema, the description is adequate for constructing a basic request, but not for fully navigating the surrounding tool suite. It does not clarify whether a job is queued and later queryable via list_jobs/get_job_status, nor does it give any decision rule for choosing this over generate_image or submit_generate. The description leaves those gaps to inference.
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 input schema has 0% description coverage and an open-ended requests array with additionalProperties true. The Args block compensates well by listing the allowed pipeline values ('sd15', 'sdxl', or 'illustrious') and specifying that each request must contain at least positive_prompt and model_checkpoint. This is enough to form a correct minimal request, though optional per-request fields are not enumerated.
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 opening sentence is a specific verb-resource pair: 'Submit a batch of image generation requests.' The explicit '(up to 10)' distinguishes it from the single-generation siblings and clearly communicates the batch scope. The purpose is immediately understandable and not buried in boilerplate.
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 implies this tool is for multiple generation requests because it is a 'batch' tool, but it does not explicitly state when to use it versus siblings like generate_image, submit_generate, or submit_inpaint. It also fails to explain what happens if the batch exceeds 10 requests or how to decide between synchronous generation and submission endpoints. The usage guidance is present only by implication.
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?
With no annotations provided, the description must carry full behavioral transparency. It discloses that the tool 'Waits for completion,' which is useful, but omits any mention of side effects, permissions, idempotency, or potential long-running behavior. Similar to the calibration example, a batch operation of this nature should clarify reversibility or failure handling; the description does not.
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 front-loaded with a one-sentence summary followed by a structured parameter list. Every line provides necessary information, though the docstring format is somewhat mechanical; it is appropriately sized for a 7-parameter tool and avoids 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?
The presence of an output schema means return values are documented elsewhere, so the description doesn't need to cover them. For the complexity (7 params, no enums, no nesting), the description covers the operation's purpose and all parameter semantics adequately. Minor gaps like validation rules or error behavior exist but aren't critical for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description is the only source of parameter meaning. It explicitly explains each parameter (e.g., 'model_type: Model architecture — "sd15" or "sdxl"') with types, enums, and defaults, going far beyond the schema's bare types and titles.
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 verb ('Merge'), the resource ('base model with multiple target models'), and the batch scope ('in batch'). It distinguishes itself from the sibling 'merge_models' by implying the batch variant, and the summary sentence is specific and unambiguous.
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 implies when to use the tool (for batch merging) via the phrase 'in batch', but it never explicitly contrasts with alternatives like 'merge_models' or states when not to use it. The behavior 'Waits for completion' hints at synchronous execution but does not provide explicit exclusions or prerequisites.
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 carries the burden of behavioral disclosure. It correctly identifies the source (safetensors header) and the parameter constraints (sd15/sdxl, checkpoints/loras/vaes). It does not mention side effects, error conditions, or latency expectations. For a read operation this is acceptable, but it doesn't go beyond the schema in explaining behavior.
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 focused and space-efficient. The first sentence states the purpose, followed by parameter documentation. It doesn't waste words. Minor deduction as it could front-load the key fact that this is a read-only metadata/safetensors_header query more explicitly, but overall it's concise and scannable.
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?
There is an output schema (not shown in this evaluation), which reduces the need to describe return values. Given that, the description covers the key context: what metadata source (safetensors header), and the constrained parameter values. It could add expected behavior when a model isn't found or how the response is structured, but the output schema presumably covers that. Effective and complete for the common case.
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 0%, so the description must compensate. It does: each parameter includes its purpose and allowed values (e.g., model_type: "sd15" or "sdxl"). This is a strong contribution over the bare schema which just has parameter names. All three params are explained with concrete examples.
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 clearly states it gets metadata for a model, naming the source (safetensors header) and the resource type. This differentiates it from list_models (which likely lists available models) and other sibling tools. The verb 'get' plus specific resource 'model metadata' is clear enough, though it could be slightly more explicit about being a read-only operation.
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 indicates when to use it: to retrieve metadata for a specific model, as opposed to listing all models (list_models). The usage context is explicit in the parameter descriptions (model_type, resource_type). However, it doesn't explicitly exclude when not to use it or name direct alternatives, though the tool name itself is descriptive enough.
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 states the tool checks 'health and reachability', implying a read-only operation, but does not explicitly disclose that it has no side effects or what exactly constitutes 'healthy'. The description is minimal but not misleading.
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?
A single, front-loaded sentence with no filler. Every word serves the purpose, and the description is appropriately sized for a parameterless 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?
Given zero parameters and the presence of an output schema (which likely describes the response format), the description is complete enough for an agent to decide when to call it. It could optionally mention that it's safe to call anytime, but the description does not leave critical gaps.
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 does not need to add parameter semantics since there are none, and the schema is complete (100% coverage).
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 verb 'Check' and the resource 'Stable Diffusion API', making the tool's purpose unmistakable. None of the sibling tools perform a health check, so it is effectively differentiated even without naming alternatives.
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 implies usage (before interacting with the API) but does not explicitly state when to use this tool versus alternatives like system_info or get_app_settings. There is no guidance on when not to use it, though the purpose is self-evident given the sibling set.
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?
There are no annotations, so the description carries the behavioral disclosure burden. It explains the core behavior (same prompt across multiple models) and useful constraints (model count 2-6, fixed seed for fair comparison), but it does not mention execution semantics such as whether the call is synchronous, returns a job, or has notable side effects. Adequate but not deeply transparent.
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 opens with a concise one-line purpose statement followed by a compact, complete parameter list. Every line carries useful information, with no filler or redundant restatement of the tool name.
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 10 parameters and no annotations, the description covers all parameters with constraints and defaults, which is sufficient for an agent to invoke it correctly. An output schema is present, so explaining the return format is not required; the main omission is explicit guidance on job/execution behavior, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates exceptionally well by documenting all 10 parameters with meaningful details: allowed pipeline values, model count range, numeric bounds for width/height/steps/cfg_scale, seed default and purpose, and scheduler meaning. This adds real value beyond the bare input schema.
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 action ('Generate images') and a specific resource/scope ('from multiple models using the same prompt for comparison'), which clearly conveys the tool's purpose. It is distinguishable from siblings like generate_image by the 'multiple models' comparison angle, though it does not explicitly name any sibling alternative.
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 phrase 'for comparison' gives clear context for when to use this tool relative to single-image or batch tools. It does not explicitly mention when not to use it or name an alternative, so it stops short of full routing guidance.
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 burden of behavioral disclosure. It states the outcome (list of jobs) and included fields, which indicates a read-only style operation, but it does not mention sorting, pagination, limits, or side effects. This is acceptable but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence that front-loads the verb, scope, and return content with no filler. Every word contributes.
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 list tool with an output schema, the description covers the essential return dimensions and intended scope. The output schema can carry detailed return-value structure, so nothing required to invoke the tool correctly is missing.
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 0 parameters, so the parameter-semantics baseline is 4 and there is nothing for the description to add beyond the schema. The schema coverage is trivially 100%, so no parameter 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?
Description uses the specific verb 'list' with the resource 'all jobs' and states the returned dimensions (status, progress, timing). It distinguishes from the sibling get_job_status by emphasizing 'all', so an agent can tell aggregate listing from a single-job lookup.
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 implies the tool is for retrieving all jobs, but it does not explicitly state when to prefer it over get_job_status or exclude cases like single-job lookup. Context signals show a relevant sibling, but the routing decision is left implicit.
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 async behavior (returns job ID, doesn't wait) and implies the tool is non-blocking. However, it doesn't disclose what happens on failure (does it throw an error or return a job ID that later fails?), rate limits, or whether the job is queued or immediately started. The description adds some value but lacks depth on error handling and lifecycle.
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 one-sentence purpose statement followed by a parameter list. It's front-loaded with the key behavioral fact (async, returns job ID). The parameter list is concise and each line is informative. Minor waste: the parameter list repeats parameter names that are already in the schema, but since schema coverage is 0%, this is justified. No 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?
The tool has 12 parameters, 3 required, and an output schema exists. The description covers all parameters with semantics and ranges. It explains the async behavior and return value (job ID). However, it doesn't mention how to poll (which sibling tool to use — get_job_status is a sibling), nor does it explain the output schema structure beyond 'job ID'. Given the complexity (12 params) and no annotations, this is fairly complete but could mention the polling mechanism.
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 0%, so the description must compensate. It does: it explains each parameter's purpose (e.g., 'positive_prompt: Text prompt describing the desired image', 'cfg_scale: Classifier-free guidance scale', 'loras: Optional list of LoRA configs, each with name and optional strength'). It adds semantic meaning beyond the raw schema, including value ranges for width/height/steps/cfg_scale and the meaning of seed=-1. This is strong compensation for the 0% schema coverage.
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: 'Submit an image generation job without waiting. Returns the job ID for manual polling.' This is a specific verb (submit) + resource (image generation job) with a clear behavioral distinction from synchronous generation. It distinguishes itself from siblings like generate_image (which likely waits) and submit_inpaint (which is for inpainting).
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 explicitly states 'without waiting' and 'for manual polling', which tells the agent when to use this tool (async submission) versus alternatives. However, it doesn't explicitly name sibling tools like generate_image as the synchronous alternative, nor does it mention when NOT to use this tool (e.g., when you need the result immediately). The context is clear but exclusions are implicit.
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 carries the burden of behavioral disclosure. It clearly states the async nature and return of a job ID, which is important. However, it does not mention potential failure modes, rate limits, or what happens if the job fails, leaving some behavioral gaps.
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 sentence followed by a parameter list. It is reasonably concise given the 12 parameters, and the key behavioral point (async, returns job ID) is front-loaded. The parameter list is necessary and not padded with 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?
The description covers the essential aspects for an async job submission tool: what it does, the parameters, and the return value. It lacks details on error handling and job lifecycle, but given the output schema exists and the tool is part of a larger job system, the description is fairly complete for an agent to invoke it 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 0%, so the description must compensate. It provides detailed explanations for each parameter, including the meaning of mask_base64 (white = inpaint region), the range for steps and cfg_scale, and the structure for loras. This adds significant value beyond the bare schema, though some parameters like scheduler and custom_vae are only named without further detail.
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 submits an inpainting job asynchronously and returns a job ID for polling. It distinguishes itself from synchronous alternatives like inpaint_image and submit_generate by emphasizing the non-blocking nature and manual polling requirement.
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 usage for asynchronous inpainting jobs and mentions manual polling, which guides the agent on when to use this tool versus waiting for results. However, it does not explicitly contrast with sibling tools like inpaint_image or submit_generate, nor does it state when not to use it.
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 of behavioral disclosure. It states the tool lists all schedulers, which implies a read-only operation, but it does not mention any additional behavioral traits such as ordering, filtering, or potential errors. For a simple list it is acceptable, but the description is minimal and lacks explicit statement of non-mutating behavior.
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 a single, clear sentence with no redundancy. It front-loads the action and resource, and every word contributes to the meaning. Perfectly concise.
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?
Given the tool has no parameters and an output schema is present (as indicated by context signals), the description sufficiently covers what an agent needs to know to invoke it correctly. No additional context about return structure is needed since it's provided by the output schema. The description is complete for a zero-argument listing 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 tool has zero parameters, so the description does not need to explain parameter semantics. Baseline for 0 params is 4, and the description adds no unnecessary detail. The schema already indicates no arguments, so the description is adequate.
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 verb 'list' and the resource 'available noise schedulers used for image generation'. It is specific and immediately distinguishes this from sibling tools like list_models or generate_image. There is no ambiguity about what the tool does.
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 its usage context (when listing schedulers for image generation) but does not explicitly state when to choose this over alternatives or mention any exclusions. Since this is a simple list operation with no alternative that overlaps in function (schedulers vs models), the implied usage is sufficient for an agent to select it correctly.
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 takes on the full burden of behavioral disclosure. It explicitly states the operation is synchronous ('waits for completion'), which is crucial for an agent deciding whether to call it. It also enumerates all parameters with constraints (e.g., model type enums, alpha range), going beyond the schema. Missing only are details on error handling and side effects, but the core behavior is well-transparent.
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 efficient: a single sentence states the action, another notes the blocking behavior, and the Args list is scannable and consistent. No redundant information exists, and every line adds value.
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?
Given the tool's complexity (7 params) and the absence of schema descriptions, the description covers all necessary aspects: what it does, its parameters, and its blocking behavior. Since an output schema exists, return values are not needed. The only minor gap is the lack of interaction guidance with sibling merge tools, but that's already addressed in usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters. It does so comprehensively: each of the 7 parameters is listed with its type and allowed values (e.g., method: 'linear', 'slerp', etc.; alpha: 0.0-1.0). This fully compensates for the schema's lack of descriptions, providing the agent exactly what it needs to invoke the tool correctly.
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 'Merge two model checkpoints' with a specific verb and resource. It also adds the blocking behavior 'Submits the job and waits for completion', which immediately distinguishes it from asynchronous siblings. The purpose is unambiguous and not confused with other tools.
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 implies usage through its scope (merging exactly two checkpoints) but does not explicitly mention when not to use it or contrast with siblings like batch_merge_models or recipe_merge. An agent could infer appropriate usage, but the guidance is implicit rather than explicit.
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:

[![sd-api-mcp MCP server](https://glama.ai/mcp/servers/mcaimi/sd-api-mcp/badges/card.svg)](https://glama.ai/mcp/servers/mcaimi/sd-api-mcp)

Score Badge

Copy to your README.md:

[![sd-api-mcp MCP server](https://glama.ai/mcp/servers/mcaimi/sd-api-mcp/badges/score.svg)](https://glama.ai/mcp/servers/mcaimi/sd-api-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/mcaimi/sd-api-mcp'

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