agnes-mcp

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Each tool targets a distinct capability (chat, image, video creation, video query, video wait, vision, model listing). Slight overlap between agnes_chat and agnes_vision regarding vision tasks is clarified in descriptions, so agents can disambiguate.
Naming Consistency3/5
All tools use 'agnes_' prefix, but naming patterns vary: some are single nouns (chat, image, models, vision) while others use verb_noun compounds (video_create, video_query, video_wait). The convention is not fully consistent but still readable.
Tool Count5/5
7 tools is well-scoped for an AI API server covering text, image, video generation, and model discovery. Each tool serves a clear purpose without unnecessary overlap or missing essential operations.
Completeness4/5
Core workflows for text generation, image generation/editing, video generation (async with status polling), and vision understanding are covered. Minor gaps include no explicit tool for deleting or updating generated content, but these are typical for generation APIs.
Average 4/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
- 1 commit 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It covers streaming behavior (server-side consumed, full text returned), thinking mode, tool calling, and vision support. However, it lacks details on potential issues like error handling, destructive actions, rate limits, or cost implications, leaving gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and structured: four sentences covering main capability, features, models, and vision. No redundant information, and key points are front-loaded.
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 complexity (15 parameters, no output schema), the description covers the core purpose and capabilities well. However, it does not explain the return format or output structure, which would be helpful for an AI agent invoking the tool. Still, the description is largely complete for the main functionality.
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 descriptions for all 15 parameters. The description adds minor context (e.g., 1M-token context limit, vision via image_url), but most parameter semantics are already well-documented in the schema. Baseline of 3 is appropriate.
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 it is for text generation and reasoning, OpenAI-compatible chat completions, and lists capabilities including multi-turn conversation, system prompts, tool calling, streaming, thinking mode, and vision. It also specifies supported models and context lengths, distinguishing it from siblings like agnes_vision which provides a simpler interface for image understanding.
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 mentions vision is available but suggests using agnes_vision for a simpler interface, providing some guidance. However, it does not explicitly state when to use this tool vs. alternatives like agnes_image or agnes_video_* tools, nor does it provide when-not-to-use scenarios.
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 bears the full transparency burden. It mentions sending images and text but does not disclose behaviors like rate limits, error handling for invalid images, authentication needs, or output format. The description covers basic operation but lacks depth on behavioral nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the core purpose first. Every sentence serves a purpose: stating the capability, explaining input types, and listing models. No extraneous information.
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 7 parameters and no output schema, the description adequately covers the main input types and use case. It explains the image formats and instruction purpose. However, it omits description of the return value (expected to be model-generated text) and does not mention streaming behavior. Still, it is sufficiently complete for a typical vision tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, so the baseline is moderate. The description adds meaning beyond the schema by clarifying that 'images' can be public URLs or data URIs, and that 'instruction' is a text prompt. However, for parameters like temperature, max_tokens, and stream, it provides no additional context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as multimodal understanding, specifying that it accepts images (URLs or data URIs) and a text instruction to describe, analyze, OCR, or answer questions. It also lists the available models. This distinguishes it from sibling tools like agnes_chat (text-only) and agnes_image (image generation).
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?
While the description explains what the tool does, it does not explicitly state when to use it versus alternatives or when not to use it. The context of sibling tools implies vision tasks, but no direct guidance is given for exclusion criteria (e.g., text-only queries should use agnes_chat).
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 dimension constraints and automatic handling of response_format, but does not cover error behavior, rate limits, or destructive nature of edits.
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 and front-loaded with purpose. It lists models and requirements efficiently, though it could be more structured with sub-sections.
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 7 parameters and no output schema or annotations, the description covers input usage and constraints well, but lacks details on return structure and error scenarios, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds value by highlighting required parameters (model, prompt, size) even though model and size have defaults, and by explaining the image parameter usage for image-to-image and extra_body handling.
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 'Image generation & editing' and specifies Text-to-Image and Image-to-Image capabilities, distinguishing it from sibling tools like agnes_chat (text) and agnes_video_* (video). The verb 'generate' and 'edit' with resource 'image' is specific.
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?
It lists required fields (model, prompt, size) and explains when to include the 'image' parameter for image-to-image. However, it does not explicitly state when not to use this tool or compare to alternatives beyond sibling domains.
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 carries full burden. It states the tool lists models with limits, implying a read-only operation, but does not explicitly mention safety, idempotency, or any potential side effects. For a simple listing, this is acceptable but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then usage guidance. Every word earns its place; no wasted text.
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 0 parameters, no output schema, and is a simple list operation, the description fully covers what the tool does and its role among siblings. It mentions the three categories and limits, which is sufficient for an agent to understand the tool's purpose.
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 no parameters (0 params), so baseline score is 4. The description adds value by explaining what the output contains (models with limits and categories), which is meaningful given no output schema exists. It does not need to discuss 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 verb 'list' and resource 'available Agnes AI models' with categories (text/chat, image, video) and what is included (their limits). It distinguishes from siblings by indicating it is useful 'before calling the other tools', making its purpose and relationship clear.
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 says 'Useful to discover model names before calling the other tools', which tells the agent when to use this tool (as a prerequisite for siblings). It does not provide explicit when-not scenarios, but the context is strong enough for correct usage selection.
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?
The description reveals async behavior and constraints like multiples of 64, frame count formula, and duration calculation. With no annotations, it partially covers behavioral traits but omits authentication, rate limits, and resource lifecycle details.
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 a single paragraph with clear sections: capability, model, return type, polling direction, and constraints. It's information-dense without redundancy, efficiently earning each sentence.
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 12-parameter video creation tool with no output schema and no annotations, the description covers return types, constraints, and mode variations. It lacks only minor details like default values for some params, which are in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaningful clarifications: width/height up to 4K, multiples of 64, num_frames formula (8n+1), and seconds relation. It also explains image can be single or array for keyframes, exceeding 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?
The description explicitly states the tool creates a video task from text, image(s), or keyframes, and distinguishes from siblings by referencing polling tools. It names the model and return type, making the purpose clear and specific.
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?
It guides the agent to poll results using agnes_video_query or agnes_video_wait, differentiating after creation. However, it doesn't explicitly contrast with agnes_image or other generation tools, leaving some ambiguity about when to choose this over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses polling behavior, terminal states (completed/failed), timeout, and the return including video URL. It also gives a time estimate. It does not mention error handling, rate limits, or side effects, but covers the core behavioral traits adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core function, and the second adds key details (return value, time expectation). It is front-loaded and efficient.
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 explains the return value (final result with video URL) and mentions failure/timeout states, but lacks detail on the structure of the result or error handling. Given the complexity of a polling tool and no output schema, it is fairly complete but could be enhanced with response format examples. It also does not explicitly reference sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (3 of 4 parameters have descriptions). The tool description adds no extra meaning beyond the schema: it does not explain model_name at all, nor does it clarify the purpose of interval_ms or timeout_ms beyond what the schema provides. Since model_name remains undocumented in both, the description fails to compensate for this gap.
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 polls an async video task by video_id until a terminal state (completed/failed) or timeout. It specifies the verb 'poll' and the resource 'async video task,' and distinguishes itself from siblings like agnes_video_create (which starts the task) and agnes_video_query (likely a non-blocking check).
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 implicitly guides usage: call this after agnes_video_create returns a video_id. It sets expectations with 'Video generation can take tens of seconds to minutes.' However, it does not explicitly contrast with agnes_video_query or give when-not-to-use scenarios. The context is clear but not exhaustive.
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?
Discloses key behavior: async status query, completion condition, and result field (remixed_from_video_id). No annotations provided, so description carries full burden. Could add detail on polling behavior or error states, but adequate.
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 concise sentences with no waste. Front-loads purpose, then usage, then result. Every sentence 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?
Given no output schema and 3 optional params, description explains query methods and result. Lacks mention of error handling, timeouts, or auth. But for a simple query tool, it's fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds meaning beyond schema: video_id is recommended, task_id is legacy, model_name overrides default. Clearly explains the two query methods.
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 the tool queries the status/result of an async video task, specifying the two query methods (video_id recommended, task_id legacy) and what happens on completion. Distinct from siblings like agnes_video_create and agnes_video_wait.
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?
Provides clear guidance on which parameter to use (video_id recommended, task_id legacy). Implicitly tells when not to use this tool (e.g., when needing to create or wait for video). No explicit when-not-to-use, but sufficient.
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:

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

Score Badge

Copy to your README.md:

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

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