GlianaAI MCP Server

Official

by Gliana-Labs

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: v0.5.1
Disambiguation5/5
Each tool targets a distinct concern: listing models vs. listing utility tools, pricing vs. schema vs. generation, and single-model generation vs. multi-model recipes. There is no meaningful overlap that would confuse an agent.
Naming Consistency3/5
Most tools follow a verb_noun pattern (list_models, get_price, get_schema, list_tools), but 'generate' is verb-only and 'tool' and 'recipe' are bare nouns. The mix is readable but not uniformly consistent.
Tool Count5/5
Seven tools is well-scoped for a server that covers both AI model access and utility tool execution. Each tool has a clear role without redundancy or bloat.
Completeness4/5
Core workflows (list, price, schema, generate, run utility, run recipe) are covered. However, file upload for media inputs is only available via an external HTTP endpoint, not an MCP tool, and there is no wallet management tool, leaving minor gaps.
Average 4.5/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
- 42 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 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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the annotations: tools are paid from a wallet (base/tempo/solana), free tools are marked by priceMicroUsd 0, and the tool list is read dynamically from the gateway so it never goes stale. It also explains GET vs POST parameter handling. It does not fully describe side effects, but it contradicts nothing and supplements the readOnlyHint/openWorldHint annotations.
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 the core purpose and packs useful operational details into a few sentences. Every sentence earns its place, covering discovery, pricing, and parameter semantics. It is a bit long with the em-dash list, but nothing is redundant.
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 dynamic dispatcher with an external tool list, the description covers the critical gaps: how to discover tools, what to pay, wallet requirements, and how to pass arguments. Since an output schema exists, return-value details are not required here. It omits error/timeout behavior, but that is not essential for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds substantial guidance: `name` must match list_tools exactly, `args` should follow the `example` from list_tools, and the HTTP method affects how args are sent. This is valuable beyond the raw schema, even though the per-tool args are intentionally dynamic.
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 that the tool runs a UTILITY tool by name, not an AI model, and lists concrete categories like scraping, OCR, and chain RPC. It distinguishes from sibling tools by contrasting with AI model usage and pointing to list_tools for discovery, though the tool name itself is generic.
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 gives an explicit usage instruction: call list_tools FIRST to get the live list with prices and input shapes. It also explains which tools need payment and which are free, and it clarifies that this is not for AI model calls. It does not name specific sibling alternatives for each category, but it provides clear context for when to use the dispatcher.
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?
Annotations already declare readOnlyHint, and the description adds useful behavioral details: the tool is 'Free', returns an 'exact cost', and its output depends on optional input like video duration or TTS character count. This enriches the safety profile without contradicting annotations.
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. It front-loads the core purpose and immediately follows with the key nuance about input-dependent pricing and the 'Free' attribute.
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, an output schema exists, and parameters are well-described, the description covers the essential context: cost per call, optional input effects, and no charge. It doesn't explain edge cases like invalid model IDs, but that's not critical for this straightforward 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?
Though schema coverage is 100%, the description adds valuable examples for the 'input' parameter (e.g., duration, text) and clarifies that the model id comes from list_models. This helps the agent understand how to construct pricing queries beyond the schema alone.
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: 'Quote the exact cost of one call for a model' with a specific verb and resource. It also distinguishes itself from sibling tools like list_models or generate by focusing on pricing, including optional input that affects cost.
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 on when to use the tool: to get pricing for a single call, optionally with input that affects price. It doesn't explicitly name alternatives or exclusions, but the context implies it's the pricing companion to generate and list_models.
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?
Beyond annotations (readOnlyHint=false), the description discloses the paid nature ('settles the price from your wallet'), output types (media URL vs assistant text), and file upload constraints. It adds significant behavioral context without contradicting the annotations.
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 somewhat long but every sentence carries useful information. It is front-loaded with the main purpose, then precision details. The structure flows logically from general to specific, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers all critical aspects: output formats, input variations, payment side-effects, prerequisites, and file handling. An output schema exists, so return values are not required, and the description does not omit essential operational details.
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?
Despite high schema coverage, the description substantially enriches parameter understanding: it explains OpenAI-style input for text models, the requirement of public URLs for file fields, and the array format for multi-reference images. This goes well beyond the bare schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Run a model and return the result', clearly stating the core function with a specific verb and resource. It distinguishes between media and text model outputs, and contrasts with sibling tools like get_schema and get_price by identifying generate as the execution 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, instructing to call get_schema first and get_price for cost, and explaining how to handle file inputs (public URL, upload limit). It doesn't explicitly state when not to use the tool, but the referenced sibling tools make the distinction obvious.
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?
Annotations already mark readOnlyHint=true, and the description adds value by noting 'Free' (likely cost-related) and summarizing the return contents (names, types, required, defaults). It doesn't contradict annotations and provides useful behavioral context beyond the structured metadata.
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?
Three concise sentences deliver purpose, usage, and cost without waste. The first sentence is front-loaded and informative, and each subsequent element (usage and cost) earns its place.
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 read-only tool with one well-documented parameter and an output schema (indicated by context), the description covers purpose, usage, cost, and a summary of the returned content. It is complete for an agent to decide to invoke the 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 100%; the model parameter is already described as 'Model id from list_models.' The description adds no extra parameter semantics, so the baseline score 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 uses a specific verb 'Get' and resource 'a model's input fields', clearly distinguishing it from sibling tools like list_models (lists models) and generate (produces output). It explicitly states 'Use before generate to know what to send.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Use before generate to know what to send', providing a clear workflow tie-in. It also references list_models in the parameter description, indicating the prerequisite step. This gives clear context for when to use the tool.
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?
Annotations already provide readOnlyHint and openWorldHint, so the safety and scope are known. The description adds the non-obvious trait that the call is free, and 'every' reinforces the open-world nature. No contradiction; meaningful context added beyond annotations.
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, each earning its place: the first states what the tool lists, the second states cost and usage guidance. No unnecessary words, information is front-loaded.
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 zero-parameter list tool with an output schema and strong annotations, the description covers purpose, cost, and usage guidance. Nothing material is missing; the output schema handles return structure details.
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?
There are zero parameters, so the baseline is 4. The description compensates by listing the output fields (id, category, provider, per-call price), giving the agent a preview of what to expect even though an output schema exists.
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 'List' with a clear resource 'GlianaAI model' and scope 'every', enumerating the fields returned (id, category, provider, per-call price). It explicitly separates this tool from siblings by positioning it as a prerequisite before get_price/generate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to pick a model before get_price/generate' explicitly states when to use the tool and implies the ordering relative to alternatives. The cost note 'Free — no payment' also guides the agent on when it's safe to call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only signal not-read-only and open-world, but the description adds critical disclosure: payment is charged, the pipeline chains models, and specific recipes behave differently (e.g., brainrot-video requires no prompt and generates audio). This goes well beyond the annotation hints and matches them.
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 dense but every clause adds value: payment warning, recipe list with inline parameters, cost comparison, override syntax, and a doc link. It is front-loaded with the core purpose and reads as a compact reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, paid, multi-model tool, the description covers cost, recipe variants, parameter specifics, and model overrides. Since an output schema exists, return-value documentation is unnecessary. The provided info is sufficient for an agent to select and invoke the tool correctly.
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?
The schema's args description is generic ('Recipe input, e.g. { prompt, motionPrompt?, duration?, resolution? }'), but the description adds concrete per-recipe parameter shapes: image-to-video takes { prompt, motionPrompt? }, brainrot-video takes { motionPrompt?, reference_image? }, and steps can be overridden with { imageModel, videoModel }. This meaningfully enriches 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 opens with a specific verb and resource: 'Run a paid multi-model RECIPE pipeline (chains models in one call).' It then enumerates concrete recipes (image-to-video, image-to-video-hd, image-to-video-audio, brainrot-video) with transformations, clearly distinguishing the tool's purpose from single-model generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong usage context: 'PAID: settles the SUM of the steps from your wallet' warns of costs, and '3-8x cheaper than a native text-to-video model' suggests when to choose this over a native alternative. It does not explicitly mention sibling tools like generate, but the recipe list and override guidance imply appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description adds valuable behavioral context: 'read live from the gateway so it is always current' and 'Free — no payment'. It also clarifies that tools with priceMicroUsd 0 are free and need no wallet. This enriches the agent's understanding without contradicting annotations.
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 three sentences, each earning its place. The first front-loads the core purpose and content, the second confirms free usage, and the third provides additional pricing guidance. No wasted words, well-structured.
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 low complexity (no parameters) and presence of an output schema, the description covers all necessary context: what is listed, that it is live, free, and provides usage guidance. It also names the sibling 'tool' as the next step, making the tool's role clear.
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 fully covers them (100% coverage). The description adds no parameter-specific details but does clarify the output fields (name, HTTP method, etc.), which is indirectly useful. Per rubric, 0 params baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'List every GlianaAI utility tool (name, HTTP method, per-call price, an example input, and usage guidance)'. It uses a specific verb (List) and resource (utility tools), and details the contents. It clearly distinguishes from siblings like list_models or get_schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs when to use: 'Call this before `tool` to pick one and learn its input shape.' It also provides context about free usage and pricing, giving clear guidance. While it doesn't list exclusions, the instruction is direct and 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:

[![gliana-mcp MCP server](https://glama.ai/mcp/servers/Gliana-Labs/gliana-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Gliana-Labs/gliana-mcp)

Score Badge

Copy to your README.md:

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

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