napkin-ai-mcp

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes, but generate_visual, generate_and_wait, and generate_and_save all trigger visual generation with different behaviors, which could cause confusion. Description clarifies the differences though, and the other tools (check_status, download_visual, list_styles, verify_api_key) are clearly separate.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (generate_visual, check_status, download_visual, list_styles, verify_api_key). The compound names generate_and_wait and generate_and_save are also consistent with this style, making the set predictable.
Tool Count5/5
Seven tools is well-scoped for a visual generation service, covering submission, status polling, download, convenience wrappers, style listing, and API key verification. Each tool serves a clear function without unnecessary redundancy.
Completeness4/5
The core lifecycle of generating, checking, and downloading visuals is fully covered, plus useful extras like styles and API key verification. Minor gaps exist (e.g., no cancel request or delete operation), but these are not essential for the primary use case.
Average 3.8/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 5, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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?
There are no annotations, so the description must carry the full burden. It only says 'Get information' without disclosing return format, pagination, or that the response is not exhaustive. The note about the full list is the only behavioral caveat, but it is vague.
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 front-loaded with the main action. The note about the website is relevant and doesn't waste words. It is appropriately sized for a simple tool, though it lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values are covered, but the description lacks guidance on how this tool fits into the workflow (e.g., getting styles before generating visuals). The absence of annotations and usage context makes it incomplete for an agent to know when to invoke it.
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 no parameters, so the baseline score is 4. The schema is empty, so there is no parameter information to add, and the description doesn't need to explain any.
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 retrieves information about visual styles, which is a specific resource. It distinguishes from sibling tools that generate, check, or download visuals, so the purpose is unambiguous.
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 compared to alternatives. The note about the full list URL is a weak hint about potential limitations, but it doesn't provide clear context or exclusions for using this tool.
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?
No annotations are provided, so the description must carry the burden. It only discloses that a request ID is returned, leaving out important behavioral details such as authentication requirements, rate limits, or whether execution is synchronous or asynchronous. Even the async nature is only implied through the polling reference.
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?
Two sentences, front-loaded with the primary action, and no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description is minimal for an async tool with 18 parameters and several sibling tools. It fails to mention prerequisites (e.g., API key), processing expectations, or how it differs from generate_and_wait beyond returning a request ID. The description does not fully map the tool's role within the broader toolset.
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 description coverage is 100%, so the schema already documents all 18 parameters thoroughly. The description adds no parameter-specific meaning, and the baseline of 3 is appropriate since the heavy lifting is done by 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 a specific action ('Submit a visual generation request to Napkin AI') and resource. It distinguishes from sibling tools by noting it returns a request ID and pointing to check_status for polling, unlike generate_and_wait or generate_and_save.
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?
It provides a clear workflow (submit then poll with check_status) but does not explicitly mention when to prefer this tool over alternatives like generate_and_wait, nor does it state any exclusions. The guidance is more implied than explicit.
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 carries the full burden. It mentions waiting for completion, implying a blocking operation, but it doesn't disclose potential timeouts, failure modes, authentication requirements, or that it makes API calls. It also omits side effects like resource creation or quota consumption, leaving the agent insufficiently informed.
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?
Two sentences, zero fluff. Every word contributes to understanding the tool's core function and composition. It is appropriately terse for a composite tool, though one could argue for more detail given complexity, conciseness is a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 18 parameters and a composite operation, the description is extremely short. It names the two operations but doesn't cover orchestration details like polling interval, timeout, error handling, or how the waiting behaves with multiple visuals. An output schema exists but return values are not the gap; the tool's behavioral semantics remain underspecified.
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 provides descriptions for all 18 parameters (100% coverage), so the description adds no parameter semantics. Baseline is 3 when schema coverage is high, and the description doesn't clarify interactions like visual_id vs visual_query, which the schema already documents individually.
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 primary action: 'Generate a visual and wait for completion.' It distinguishes itself from siblings by explicitly mentioning it combines generate_visual and check_status into one operation, making its purpose unambiguous and unique.
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 context by stating it combines generate_visual and polling check_status, signaling that this is the one-shot operation when you need the final completed visual. It references sibling tools indirectly but doesn't explicitly say when NOT to use it, such as when you need to poll manually or perform other tasks in between.
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 fully disclose behavioral traits. It honestly states the side effect of saving and the asynchronous waiting behavior. Yet it omits details such as failure handling, return value semantics, or storage specifics, leaving some informational gaps beyond what the schema provides.
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, front-loaded sentence that efficiently states the core workflow. Every word earns its place, with no filler or repetition of schema content.
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's complexity (19 parameters) and the rich schema and output schema, the description provides a minimal but adequate high-level overview. It covers the key workflow (generate, wait, save) but lacks contextual details about multi-visual generation, regeneration, or failure modes. These gaps are partially mitigated by the schema's parameter descriptions, making the description adequate but not comprehensive.
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 description coverage is 100%, so the baseline is 3. The description adds no parameter-level meaning, but since the schema already documents all 19 parameters with descriptions and constraints, no extra compensation 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 clearly states the tool's function: 'Generate a visual, wait for completion, and save to configured storage.' This distinguishes it from siblings like generate_visual and generate_and_wait, which focused on generation without saving. The verb+resource structure 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it generates, waits, and saves, and explicitly notes a prerequisite ('Requires storage to be configured in server settings'). However, it does not explicitly contrast with generate_and_wait or other alternatives, so I deduct one point for lacking explicit when-to-use vs. alternative 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that output is base64-encoded data and that the input URL comes from check_status. However, it does not mention authentication requirements, potential failure modes (e.g., invalid URL), or any side effects. This is adequate for a simple download tool but lacks depth.
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 highly concise and well-structured: two sentences that front-load the action and output format, followed by a precise instruction on where to obtain the input. Every sentence earns its place, with no redundant or unnecessary detail.
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 (one required parameter, output schema present), the description is almost complete. It covers the workflow (use check_status URL) and the output format (base64). A note about authentication or error handling would complete it, but the existing description is sufficient for most use cases.
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 documentation already provides 100% coverage for the file_url parameter, including its format and source ('File URL from check_status generated_files'). The description's mention of the URL from check_status does not add information beyond what the schema already states, so it meets the baseline for schema-covered parameters.
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: 'Download a generated visual file as base64-encoded data.' It uses a specific verb (download), identifies the resource (generated visual file), and specifies the output format (base64). This distinguishes it from siblings like generate_visual and check_status by focusing on the download step.
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: 'Use the URL from check_status response's generated_files array.' This tells the agent the prerequisite and source of the input parameter. However, it does not explicitly mention alternatives or when not to use this tool, such as generate_and_save, which might be a direct alternative.
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 for behavioral disclosure. It discloses that the tool returns progress and file details, but it does not mention non-destructive behavior, polling limitations, or error conditions. This is adequate but minimal for a status check tool.
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?
Two short, clear sentences convey the purpose and return value with no filler. Well-structured and easy to scan.
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 single-parameter status tool, the description fully covers what the tool does and returns. The existence of an output schema means return format specifics need not be duplicated here. Sibling tools provide enough context for placement.
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% with the request_id parameter already described as 'Request ID from generate_visual.' The description adds no further parameter detail, so it does not exceed the baseline set by 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 uses a specific verb 'Check' with a clear resource: 'status of a visual generation request.' It explicitly states what is returned ('progress information and file details'), making it distinct from sibling tools like generate_visual or download_visual.
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 after a generation request, reinforced by the parameter description 'Request ID from generate_visual.' However, it does not explicitly state when not to use this tool versus alternatives like generate_and_wait, though the context makes it reasonably clear.
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. It states the tool verifies validity, implying a read-only check, but does not explain what happens on failure, whether it makes a network request, or what the response contains. The existing output schema may cover return format, but the description lacks richer behavioral context.
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 two sentences, directly states the purpose and usage, and contains no filler or redundant information. It is well-structured and easy to parse quickly.
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 (0 parameters, output schema present, low complexity), the description is nearly complete. It conveys the purpose and when to use it. The only minor gap is the lack of detail on failure behavior, but this does not significantly impact usability for a simple API key check.
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 value by indicating the tool tests the configured API key, which gives context for why there are no user-supplied inputs. No additional parameter semantics are 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 clearly identifies the action ('Verify') and the resource ('configured Napkin AI API key'), with a specific objective ('is valid'). It is distinct from sibling tools like generate_visual or download_visual, which perform different operations.
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 'Use this to test your setup before generating visuals' provides explicit context for when to use the tool. It does not mention alternatives or exclusions, but for a simple validation tool with zero parameters, this guidance is sufficiently clear.
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:

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

Score Badge

Copy to your README.md:

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

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