nan-mcp-server

by luciferfran

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.6
Disambiguation4/5
Most tools have clearly distinct purposes, such as text_to_speech vs speech_to_text and generate_image vs edit_image. The slight overlap between generate_image and edit_image is easily resolved by their names and descriptions, so ambiguity is minimal.
Naming Consistency3/5
The tool names mix conventions: verb_noun (generate_image, list_voices, list_models, edit_image), x_to_y phrases (text_to_speech, speech_to_text), and bare verbs (embed, rerank). While readable, the inconsistent patterns make it less predictable.
Tool Count5/5
Eight tools is well-scoped for a multi-modal AI API, covering image generation/editing, TTS/STT, embeddings, reranking, and model listing without being excessive.
Completeness4/5
The tool set provides good lifecycle coverage: image generation and editing are paired, TTS includes voice listing, STT is present, and embed/rerank complement each other for RAG. Minor gaps like model details or batch operations exist but are not critical.
Average 4/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 20 commits in the last 12 weeks
- Last stable release on August 8, 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It does disclose the return value ('saved image file path and its URL'), which adds useful behavioral context. However, it does not mention potential side effects like file persistence, overwriting behavior, or cost implications of generating images.
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, focused sentence that immediately states the core function, model, and return behavior. Every word adds value, with no fluff 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 straightforward generation tool, the description covers the essential aspects: what it does, the model used, and what it returns. The schema covers parameters comprehensively, and the lack of an output schema is mitigated by the explicit return description. It could mention file storage details, but this is not critical for basic usage.
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 6 parameters (100% coverage), so the description does not need to elaborate. The description adds no new parameter-level details beyond what the schema already states, which aligns with the baseline score of 3 for high 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 action ('Generate an image'), the specific model ('flux-2-klein'), and the API ('NaN API'). It distinguishes from sibling tools like edit_image by focusing on generation rather than editing or other audio/text operations.
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 does not provide any guidance on when to use this tool versus alternatives. It neither mentions exclusions nor suggests conditions for use, leaving the agent to infer that it's for image generation. While the purpose is clear, there is no explicit usage context or comparison with siblings.
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 must carry the burden. It states the tool returns a saved output image path and that it consumes reference images, which implies file creation and non-destructive behavior. However, it does not disclose permission requirements, rate limits, or what happens if the operation fails.
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 with no redundancy. It front-loads the core purpose and concludes with the return value, making it easy to parse and remember.
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 7 parameters, no annotations, and no output schema, the description gives a high-level overview but omits details like multi-output behavior when n>1 (possibly an array of paths) and any constraints. The schema covers parameters, so the description suffices for basic invocation but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all 7 parameters with 100% coverage, so the description adds little parameter-specific detail. It reinforces that 'images' are reference files and 'prompt' describes the transformation, but does not exceed the schema's information.
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 'Edit' with the resource 'image' and identifies the model 'flux-2-klein image-to-image'. It clearly distinguishes from the sibling tool generate_image by specifying that it takes reference image files and applies a transformation.
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 that the tool is for image-to-image editing, implying it should be used when reference images exist. However, it does not explicitly exclude text-to-image generation or name generate_image as an alternative, so it lacks explicit when-not 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 mentions the model and output dimension but does not disclose authentication requirements, rate limits, error behavior, or output structure. This is a moderate disclosure for a simple embedding 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?
The description is a single, well-structured sentence that immediately states the core purpose, then adds model details and a use case. Every word earns its place with no redundancy or 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 is simple with 2 well-documented parameters and no output schema. The description covers the purpose, model, dimensions, and use case, which is largely complete for an embedding tool. However, it does not explicitly describe the exact response format (e.g., array of floats), leaving a minor gap.
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 parameters are already well-documented. The description adds no additional parameter details beyond what the schema provides, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Generate vector embeddings' with a specific verb and resource. It further specifies the model (qwen3-embedding), dimensions (4096), and use case (RAG, semantic search), which distinguishes it from siblings like rerank.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating 'Useful for RAG and semantic search.' This implies when to use the tool, though it does not explicitly mention when not to use it or name alternative tools. The context is sufficient for a simple tool.
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 provided, so the description carries the full burden. It clarifies that the operation lists models available to the caller's key, but does not disclose additional behavioral details such as network call behavior, rate limits, or return format. The word 'List' strongly implies a non-destructive read, so it's adequate 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?
The description is a single, front-loaded sentence with no filler. Every word contributes the purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—zero parameters, no output schema—the description adequately specifies what the tool does and the scope ('for your key'). It could mention what the list contains (e.g., model IDs or names), but the operation is straightforward enough that the description is complete for this level of complexity.
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 there is no parameter information required. The baseline for zero-parameter tools is 4, and the description doesn't need to add parameter details.
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 the specific verb 'List' to name the action and identifies the resource as 'available NaN API models' scoped to 'your key.' This clearly distinguishes it from sibling tools like generate_image or text_to_speech, which perform different actions.
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 when you need to see which models your key can access, but it does not explicitly state when to use this tool versus alternatives or mention any contextual preconditions. For a simple list tool, the context is reasonably clear, but it lacks explicit 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 full responsibility. It adds useful context by naming the specific API and model (NaN API, Qwen3-Reranker-8B), but it does not disclose return format (e.g., whether scores are included) or other behavioral traits such as tie-handling or ordering guarantees.
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 unnecessary wording. Every word adds value, making it an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the schema covers all parameters, and the description gives sufficient context for typical RAG use. However, since there is no output schema, the description would benefit from explicitly stating the return format (e.g., re-ranked list with or without scores), and it omits any operational prerequisites like authentication or rate limits.
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 all parameters are already documented in the schema. The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action (re-rank) on a specific resource (a list of documents by a query), and explicitly notes it complements embed for RAG pipelines. This clearly distinguishes it from the closest sibling tool (embed) while being unambiguous about its function.
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 that this tool is used in RAG pipelines alongside embed, which implies when it should be used. However, it lacks explicit exclusions or alternatives beyond embed, so it doesn't fully address 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?
With no annotations, the description carries the burden. It states the model (whisper) and that it returns the transcript, but does not disclose side effects, file handling, or error conditions. However, the operation is clearly non-destructive.
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 concise sentence containing only essential information, with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple transcription tool with three well-described parameters, the description gives the fundamental behavior and return type. It could mention supported formats or file size limits, but the schema already covers language and verbose options.
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%, and the description does not add parameter-specific meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Transcribe') and resource ('audio file'), and distinguishes it from siblings like text_to_speech.
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 context is clear: it is for transcribing audio to text. No exclusions are mentioned, but the tool's purpose is self-evident relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. It discloses that the tool returns a saved audio file path and names the backend (kokoro), but does not elaborate on file lifecycle, synchronous/asynchronous behavior, or failure modes.
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, immediately front-loaded with the action and output format. Every phrase adds value; the only mildly cryptic element is 'NaN API TTS' but it does not waste space.
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 five parameters and no output schema, the description provides a clear return value (file path) and points to a companion tool for voice selection. It does not explain output file management or error behavior, but the schema covers input formats, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions and examples, so the baseline of 3 applies. The description's mention of list_voices for the full catalog adds a complementary hint but does not exceed schema 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?
Clearly states 'Synthesize audio from text' with a specific verb and resource. Distinguishes itself from siblings like list_voices and speech_to_text by focusing on synthesis and saving an audio file.
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?
Explicitly recommends using list_voices to discover voices, which gives context for voice selection. It does not explicitly contrast with speech_to_text, but the tool name and description make the use case obvious.
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 is the sole source of behavioral information. It discloses the grouping by language and the exhaustive nature ('all available'), but does not mention return format, ordering, pagination, or any prerequisites. For a simple list operation, this is adequate 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?
The description is a single, focused sentence that is front-loaded with the essential verb and resource. It contains no wasted words and is easy to scan.
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 tool with no parameters, no annotations, and no output schema, the description covers the core purpose and a key behavioral aspect (grouping). It is sufficient for an agent to understand what the tool does and when to invoke it, though it could mention the response format for extra clarity.
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 schema covers everything by default (baseline 4). The description adds value by specifying that the output is grouped by language, which enriches the meaning beyond the empty 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 the tool's function: 'List all available kokoro TTS voices grouped by language.' It uses a specific verb ('list') and resource ('kokoro TTS voices'), and distinctly differentiates from sibling tools like list_models by focusing on TTS voices rather than general models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying that it lists all voices grouped by language, which implies its use for discovering available voice options before text-to-speech. However, it does not explicitly mention alternatives or state when not to use this tool, leaving some room for inference.
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:

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

Score Badge

Copy to your README.md:

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

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/luciferfran/nan-mcp-server'

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