Which integrations are available for this server?

Allows payment settlement via Solana using USDC for generative AI calls.

How do I use GlianaAI MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@GlianaAI MCP Server list all available models" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

GlianaAI MCP Server

Official

by Gliana-Labs

Overview Schema Related Servers Score Discussions

JavaScript

Local

GlianaAI MCP server

Listed on mcpservers.org Glama server page

Pay-per-call generative AI for any MCP client (Claude Desktop, Cursor, …). 90+ models — image, video, video editing, music, speech, LLM chat — plus utility, market-data and SEC-filing tools, with no signup and no API key. Paid calls settle per call from your own wallet over MPP / x402.

Browse + price everything for free (list_models, get_price, get_schema, list_tools).
generate runs a model and settles the gateway's 402 from your wallet (USDC on Base). Your private key is read from the client config and never leaves your machine — non-custodial, same model as ai.glianalabs.com.

Tools

Tool	Paid?	Description
`list_models`	free	Every model: id, category, provider, per-call price.
`get_price`	free	Exact cost of one call (input affects it — video duration, TTS length).
`get_schema`	free	A model's input fields (required, defaults).
`generate`	paid	Run a model → media URL, or assistant text for chat models.
`list_tools`	free	Every utility tool: price, HTTP method, example input, guidance.
`tool`	mostly paid	Run one utility tool — scraping, screenshots, social cards, OCR, structured extraction, market data, chain RPC, reference data.
`recipe`	paid	Run a multi-model pipeline in one call (e.g. text→image→video).

list_tools reads the gateway live, so it is never out of date — which is why this table doesn't enumerate the utility tools. A written-down list goes stale the moment a new endpoint ships, and this one had.

Some utility tools are free and need no wallet at all (list_tools reports them at priceMicroUsd: 0) — currently the Indonesian reference endpoints: official region data, prayer times, and NIK verification.

File inputs

Models that take a source file (image-to-video, video-to-video, transcription) accept a public URL in their file field (e.g. image, video_uri). Have a local file? Upload it first — no key, no payment:

curl -X POST https://api.glianalabs.com/v1/media \
  -H "content-type: video/mp4" --data-binary @clip.mp4
# → { "url": "https://api.glianalabs.com/v1/media/<id>.mp4" }

Pass the returned url into the model field. Max 40 MB; video / image / audio only.

Related MCP server: navi-x402-mcp

Install

Add to your MCP client config.

Claude Desktop (claude_desktop_config.json) / Cursor (~/.cursor/mcp.json):

{
  "mcpServers": {
    "gliana-ai": {
      "command": "npx",
      "args": ["-y", "gliana-ai-mcp"],
      "env": {
        "GLIANA_WALLET_KEY_FILE": "/absolute/path/to/gliana-wallet.key"
      }
    }
  }
}

Payment rails

generate settles the gateway's 402 from your wallet. Pick a rail and set its key:

Use a dedicated wallet, funded with only what you intend to spend. This server signs payments locally — the key never leaves your machine and is never sent to us — but it is still a private key on a machine running an AI agent. Do not use a wallet that holds anything you would miss.
Prefer *_KEY_FILE over the inline variable. Your MCP client config gets synced to cloud storage, committed by accident, and screenshotted when you ask someone for help. A file you chmod 600 does not:
printf '%s' '0xYOUR_KEY' > ~/.gliana-wallet.key && chmod 600 ~/.gliana-wallet.key
Inline still works if you prefer it — the server just warns on stderr.

Rail	Env var	Wallet needs
base (default)	`GLIANA_WALLET_KEY_FILE` or `GLIANA_WALLET_KEY` (0x EVM key)	USDC on Base — gasless EIP-3009 signature
tempo	same key as base	USDC on Tempo
solana	`GLIANA_SOLANA_KEY_FILE` or `GLIANA_SOLANA_KEY` (base58 or JSON-array secret key)	USDC on Solana

GLIANA_RAIL — base | tempo | solana. Optional; defaults to base (or solana if only a Solana key is set). The wallet must hold USDC on that chain.
GLIANA_API_URL — optional, defaults to https://api.glianalabs.com.

Keys are needed only for paid calls. The discovery tools — and the free utility tools list_tools reports at priceMicroUsd: 0 — work without any wallet.

Restart the client. Ask it to "list GlianaAI models" or "generate an image of a red fox with nano-banana-2".

Funding

Fund the wallet with a few dollars of USDC on your chosen chain (Base, Tempo, or Solana). You pay only the per-call price (see get_price); there's no subscription and no balance held by us.

Use a dedicated low-balance wallet for agents. Never paste your main wallet's key into any config.

Available Tools

7 tools

generateA

Run a model and return the result — a media URL for image/video/audio/music models, assistant text for text (LLM) models. Text models take OpenAI-style input: { messages: [{ role, content }, …], max_tokens? }. PAID: settles the price from your wallet over the configured rail (base/tempo/solana). Call get_schema first for the input shape, get_price for the cost. File inputs (image/video/audio, e.g. image-to-video or video-to-video video_uri) take a public URL — upload a local file with POST /v1/media (≤40MB) to get one. Array file fields (e.g. images, reference_images for multi-reference models) take an ARRAY of such URLs.

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes	Model input, e.g. { prompt: "a red fox" } or { text: "hello" }. See get_schema.
`model`	Yes	Model id from list_models.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	No	Media URL of the result, when the model returns media.
`rail`	Yes
`model`	Yes
`output`	No	Raw model output.
`costUsd`	Yes
`costMicroUsd`	Yes

TDQS

A4.5/5.0

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.

get_priceA

Read-only

Quote the exact cost of one call for a model (optionally with input that affects price, e.g. video duration or TTS character count). Free.

ParametersJSON Schema

Name	Required	Description	Default
`input`	No	Optional model input that affects price (e.g. { duration: 8 } or { text: "..." }).
`model`	Yes	Model id from list_models, e.g. "nano-banana-2" or "veo-3.1-fast".

Output Schema

ParametersJSON Schema

Name	Required	Description
`unit`	Yes
`model`	Yes
`units`	Yes
`costUsd`	Yes
`costMicroUsd`	Yes

TDQS

A4.4/5.0

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.

get_schemaA

Read-only

Get a model’s input fields (names, types, which are required, defaults). Use before generate to know what to send. Free.

ParametersJSON Schema

Name	Required	Description	Default
`model`	Yes	Model id from list_models.

Output Schema

ParametersJSON Schema

Name	Required	Description
`model`	Yes
`props`	Yes
`category`	Yes
`required`	Yes

TDQS

A4.5/5.0

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.

list_modelsA

Read-only

List every GlianaAI model (id, category, provider, per-call price). Free — no payment. Use this to pick a model before get_price/generate.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`count`	Yes
`models`	Yes

TDQS

A4.7/5.0

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.

list_toolsA

Read-only

List every GlianaAI utility tool (name, HTTP method, per-call price, an example input, and usage guidance), read live from the gateway so it is always current. Free — no payment. Call this before tool to pick one and learn its input shape. Tools reported at priceMicroUsd 0 are free to call and need no wallet.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`tools`	Yes

TDQS

A4.9/5.0

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.

recipeA

Run a paid multi-model RECIPE pipeline (chains models in one call). PAID: settles the SUM of the steps from your wallet (base/tempo/solana). Recipes: image-to-video {prompt,motionPrompt?} text→image→animated video (3-8x cheaper than a native text-to-video model), image-to-video-hd (crisper still), image-to-video-audio (video with sound), brainrot-video {motionPrompt?,reference_image?} random Italian-brainrot creature → video with audio (no prompt). Override steps with { imageModel, videoModel }. See https://ai.glianalabs.com/docs#recipes.

ParametersJSON Schema

Name	Required	Description	Default
`args`	Yes	Recipe input, e.g. { prompt, motionPrompt?, duration?, resolution? }.
`name`	Yes	Recipe name: image-to-video, image-to-video-hd, image-to-video-audio, or brainrot-video.

Output Schema

ParametersJSON Schema

Name	Required	Description
`url`	No	Final media URL (the last step).
`rail`	Yes
`recipe`	Yes
`result`	No	Each step output.
`costUsd`	Yes
`costMicroUsd`	Yes

TDQS

A4.8/5.0

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.

toolA

Run a UTILITY tool (not an AI model) — scraping, screenshots, social cards, market data, chain RPC, OCR, address parsing, structured extraction, Indonesian reference data. Call list_tools FIRST for the live list with prices and input shapes: it is read from the gateway, so it is never out of date, and this description deliberately does not enumerate them. Most tools are PAID and settle a flat price from your wallet (base/tempo/solana); the ones list_tools reports at priceMicroUsd 0 are free and need no wallet at all.

ParametersJSON Schema

Name	Required	Description	Default
`args`	Yes	The tool's input, as list_tools shows in `example`. For GET tools these become query parameters; for POST tools, the JSON body.
`name`	Yes	Utility tool name exactly as list_tools reports it, e.g. scrape, ocr-id, address-id, extract, exchange-rate, prayer-times.

Output Schema

ParametersJSON Schema

Name	Required	Description
`rail`	Yes
`tool`	Yes
`result`	No	Tool result (markdown, url, prices, or rpc result).
`costUsd`	Yes
`costMicroUsd`	Yes

TDQS

A4/5.0

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.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.5.1Aug 8, 2026
- First observedgenerate
- First observedget_price
- First observedget_schema
- First observedlist_models
- First observedlist_tools
- First observedrecipe
- First observedtool

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

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.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

WarpPay402 Gateway C
com.warppay402.api
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Autonomous Agents Browser Automation Web3 & Decentralized Tech
152
WarpPay402 Gateway CDeprecated
com.warppay402.api
Production-grade MCP gateway delivering 8 real-time AI tools with instant x402 micropayments settled in USDC on Base Mainnet or SPL-USDC on Solana. Features Basescan contract auditing, wallet analytics, headless browser scraping, and pre-scraped oracle data feeds.
Autonomous Agents Browser Automation Web3 & Decentralized Tech
151
mcp-server A
io.github.apihubio
Discover and pay for APIs with USDC credits. No wallet, no gas, MCP-native marketplace.
Cryptocurrency Payments & Billing
92
Cralo
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1

Related MCP Servers

thebuyside-x402-agent
Blockchain Cryptocurrency Payments & Billing
jaysperspective
A
license
A
quality
D
maintenance
The MCP gateway that lets any AI agent discover and pay metered APIs on Base or Solana — without the user wiring payments themselves.
Updated 3 months ago (2026-06-07 14:12 UTC)
3
15
1
Apache 2.0
navi-x402-mcp
Cryptocurrency Weather Services Language Translation
mobileappbyharis
A
license
A
quality
F
maintenance
Enables AI agents to access paid tools like crypto prices, weather, translation, and web intelligence via per-request USDC payments on Base, with no API keys or subscriptions.
Updated 3 months ago (2026-06-11 10:07 UTC)
15
45
MIT
omnicall-mcp
AI & Machine Learning Cryptocurrency
ColinHughes2121
F
license
Not graded
quality
C
maintenance
Keyless, pay-per-call AI gateway: 248 LLMs plus image/video/voice/music generation and live crypto, DeFi, markets, web-search and research tools through one MCP server. Pay per call in USDC via x402 on Base/Solana — no API key, no signup, free tier.
Updated 2 months ago (2026-06-24 15:36 UTC)
-
StatePulse API
Blockchain Finance Travel & Transportation
Ahmed-Achtatar
A
license
Not graded
quality
B
maintenance
55+ pay-per-call tools for AI agents over MCP: live telemetry, blockchain/on-chain checks, environmental, transit, finance, and network utilities. No API key or signup — agents pay per request with x402 USDC micropayments (Base and Solana).
Updated a month ago (2026-07-31 18:38 UTC)
MIT

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

GlianaAI MCP server

Tools

File inputs

Install

Payment rails

Funding

Links

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API