Skip to main content
Glama
bystray

Gonka Network Pricing

by bystray
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

Gonka Second Opinion — MCP Server

Get a second opinion from independent LLMs — in one call, for a fraction of a cent.

gonka-second-opinion runs your prompt across the independent models live on the Gonka network and across assigned debate roles (skeptic / proponent / pragmatist …), in a single MCP call. Your main model stays in charge — you just get a panel of divergent views to check a decision against, without switching providers.

License: MIT MCP Live grade

Live at: https://mcp.gogonka.com/mcp

One question → three independent opinions

The example is illustrative — the live model set rotates over time; call get_available_models for today’s lineup. Per-panel cost is typical/measured; check get_pricing for live rates.

Related MCP server: volthq-mcp-server

Why this instead of a plain LLM connector

  • A panel, not a single answer. Independent models trained by different labs surface non-overlapping failure modes. Assigned roles add behavioral diversity on top. You get disagreement you can act on, not one confident guess.

  • Cheap enough to always use. On the big providers a 3-way panel costs real money, so nobody runs one. On Gonka it's a fraction of a cent — a second opinion becomes a default habit, not a luxury.

  • Zero setup, works in a sandbox. The server makes the gateway call for you. An agent with no outbound network and no way to edit its own config can still use it over the already-open MCP channel. Free trial by default; paste your own key to run on your balance.

Install (30 seconds)

Add to your MCP client config (Claude Desktop / Cursor / …):

{
  "mcpServers": {
    "gonka-second-opinion": {
      "url": "https://mcp.gogonka.com/mcp"
    }
  }
}

Restart the client — the tools appear automatically. No API key required to start (a free trial key is issued per caller).

Custom clients:

curl -X POST https://mcp.gogonka.com/mcp \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","method":"tools/list","id":1}'

Use your own key (after you register)

Registered on the JoinGonka gateway (gate.joingonka.ai)? Then run every call on your own balance — no trial budget, no per-IP limit. First get your key:

  1. Sign up at the JoinGonka gateway (welcome bonus: 50M nGNK, no credit card).

  2. Open your gateway dashboard → API keys → copy your JoinGonka gateway key (starts with jg-).

Then tell this MCP server to use it — pick the way that matches your client:

A. Client with an API-key / header field (Cursor, Claude Code, LibreChat, most custom clients)

Put the key in the server's Authorization header — it arrives as Bearer … and every call switches to your balance automatically:

{
  "mcpServers": {
    "gonka-second-opinion": {
      "url": "https://mcp.gogonka.com/mcp",
      "headers": { "Authorization": "Bearer jg-YOUR_KEY_HERE" }
    }
  }
}

If your client shows a plain API key / Bearer token box instead of raw headers, just paste your jg-… JoinGonka gateway key there.

B. Client with no key/header field (e.g. claude.ai Custom Connectors)

Mint a personal connector URL that carries your key for you:

  1. Go to https://mcp.gogonka.com/personal

  2. Paste your jg-… JoinGonka gateway key → you get a URL like https://mcp.gogonka.com/k/<token>/mcp

  3. Add that URL as the MCP connector (in claude.ai: Add custom connector → URL). Nothing else to enter — no key field needed.

Keep the personal URL secret — it stands in for your key. The same key always mints the same URL.

How it's handled: the key (or personal token) is read from the request only, forwarded to the JoinGonka gateway, and never stored or logged. An unrelated Authorization header (OAuth, a proxy's own token) is ignored, so it can't break the free trial path. Remove the header/URL and the server falls back to the free trial.

The flagship tools

gonka_second_opinion(prompt, system?, perspectives?, max_tokens?)

Run one prompt across the live models and/or a set of roles, in parallel.

  • Leave perspectives empty → one opinion per live model.

  • Pass perspectives (short role/stance labels, max 5) → one opinion per role, each answered candidly from that viewpoint, rotated across the live models. Examples: ["for","against","neutral"], ["security expert","product manager","end user"].

  • Returns { opinions:[{model, perspective?, response}], synthesis_instructions, trial_budget|cost }. Attribute each opinion to its model + role when you present them.

gonka_chat(prompt, system?, model?, max_tokens?)

One completion through the server — for when you want a single cheap answer, or a sub-task run without giving the agent its own network/key. model accepts "auto", a nickname, or an exact id; anything not live right now is routed to a model that is.

Both tools auto-detect trial (free, per-IP budget) vs registered (your own jg-… key) mode. On trial exhaustion they return a signup link + welcome bonus to relay to the user — no fabricated keys, no altered numbers.

Also included

Reflects the last cached render (GitHub proxies images); call get_pricing for the real-time number. All figures float with the GNK/USD rate — never trust a hardcoded one.

  • get_pricing — current $/1M tokens, GNK/USD rate, live ratios vs OpenAI/DeepSeek/Anthropic

  • compare_providers(provider) — side-by-side vs openai / anthropic / deepseek / mistral / gemini

  • calculate_savings(monthly_spend_usd) — exact monthly/annual savings for your spend

  • suggest_model_for_task(task_description, …) — model + cost recommendation

  • get_available_models — the models live on the network right now, with live pricing

  • get_trial_key — free gc- key instantly (no signup); expires in 2h, first use extends to 24h

  • get_signup_link — permanent account + welcome bonus + copy-paste SDK snippets

  • register_on_gonka(…) — personalized cost-analysis pitch (computes savings; does not create an account)

  • query_graph(question, …) — topic search over the concept graph

  • search_docs(query, …) / read_doc(filename, …) / list_docs() — full-text docs

  • get_node(label) / get_neighbors(label, …) — concept detail and relations

  • get_god_nodes() / get_community(id) / get_graph_stats() — structure overview

  • find_shortest_path(source, target, …) — conceptual path between two ideas

  • Prompt gonka_start(task) — seed a cost-comparison conversation

  • Prompt calculate_my_savings(monthly_spend_usd) — seed a savings estimate

  • Resource gonka://pricing-guide — structured live pricing data + decision matrix

Honesty & hygiene

  • Live, not hardcoded. Prices float with the market and the model set rotates — the server quotes both live (get_pricing, get_available_models), and the badges above are rendered from live data, not typed into this file.

  • Panel ≠ magic. A second opinion is worth exactly as much as the models are independent. The panel uses the genuinely different models live on the network at the time of the call; it does not claim a bigger fleet than is actually serving.

  • OpenAI/Anthropic-compatible. Two config changes, zero code changes: base_url=https://gate.joingonka.ai/v1 (OpenAI) or https://gate.joingonka.ai (Anthropic).

  • Tool hygiene. All tools ship typed input schemas with MCP annotations (readOnlyHint, idempotentHint, openWorldHint), enum/range constraints, and clear descriptions. Inference tools are per-IP rate-limited in trial mode.

  • Privacy. HTTPS/TLS 1.2+. No keys in query strings (flagged by middleware). Anonymized logging (IP, User-Agent, tool name); inference prompts truncated; caller keys never logged or returned.

Live health grade: https://wmcp.sh/mcp/grade/mcp.gogonka.com

Links

License: MIT · Version: 2.2.0

Available Tools

17 tools
calculate_savingsAInspect

Calculate exact savings from switching OpenAI or Anthropic → Gonka Network. Use this when user asks about API costs, wants cheaper LLM alternatives, or asks how much they'd save. Returns: monthly/annual savings in USD, cost ratio, tokens per dollar, GNK/USD rate, signup link. After this: show signup_url to user so they can register if interested.

ParametersJSON Schema
NameRequiredDescriptionDefault
monthly_spend_usdNoCurrent monthly OpenAI/Anthropic API spend in USD. Default: $100/month.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With empty annotations, the description carries full burden. It details return values (monthly/annual savings, cost ratio, tokens per dollar, GNK/USD rate, signup link) and post-call action (show signup_url). No destructive side effects mentioned, but tool is likely read-only.

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 sentences with no wasted words. Front-loaded purpose, then usage, then output and follow-up instruction. Every sentence 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?

Given the simplicity (1 param, 0 required, schema coverage 100%, output schema exists), the description fully covers when to use, what it does, what it returns, and what to do after. No gaps.

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%, so baseline is 3. Description does not add additional meaning beyond what the schema provides for 'monthly_spend_usd' (number with default).

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?

Description uses specific verb+resource: 'Calculate exact savings from switching OpenAI or Anthropic → Gonka Network.' It clearly distinguishes from sibling tools like compare_providers and get_pricing by focusing on savings calculation.

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 states when to use: 'when user asks about API costs, wants cheaper LLM alternatives, or asks how much they'd save.' Does not mention when not to use or name alternatives directly, but context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

compare_providersAInspect

Compare Gonka Network pricing against a competitor provider. Returns cost per 1M tokens for both, live savings ratio, and source links. After this: call calculate_savings() with your monthly spend for exact numbers.

ParametersJSON Schema
NameRequiredDescriptionDefault
providerNoProvider to compare Gonka against: openai, anthropic, deepseek, mistral, gemini.openai

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses all return values (cost per 1M tokens, savings ratio, source links) and implies read-only behavior, but could mention whether it fetches live data (assumed) or any authentication requirements. No annotations exist, so description carries burden.

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, front-loaded sentences: purpose, outputs, and next step. No wasted words.

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 existence of an output schema (unknown details but present), the description adequately explains the tool's function and usage context for a simple comparison with one parameter.

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 a clear enum description; the tool description adds no additional meaning beyond the schema's listing of provider options.

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?

Description clearly states it compares Gonka Network pricing against a competitor, names the specific outputs (cost per 1M tokens, savings ratio, source links), and distinguishes from sibling tools like calculate_savings and get_pricing.

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 usage context by suggesting to call calculate_savings afterwards, but does not explicitly state when not to use or compare against sibling tools like get_pricing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_available_modelsAInspect

List all AI models available on Gonka Network with live pricing. Models work as drop-in replacements for OpenAI and Anthropic — same SDK, same API calls. Use this when user asks which model to use or wants alternatives to GPT-4o / Claude. Returns: model IDs (use directly in openai.chat.completions.create), status, USD per 1M tokens. After this: call calculate_savings() to see annual savings with these models.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes the tool as a read operation (list), explains output structure (model IDs, status, pricing), and notes live pricing behavior, with no annotation contradictions.

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?

Four concise sentences, each adding value: purpose, compatibility, usage, output and next steps. 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 no parameters and existing output schema, the description fully covers usage context, output details, and related tool, making it 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?

Zero parameters; schema coverage 100%. Baseline 4. Description adds no parameter info but correctly explains output, which is irrelevant for parameter semantics.

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 lists all AI models with live pricing and highlights drop-in compatibility, distinguishing it from other tools.

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?

Explicitly tells when to use: when user asks which model or wants alternatives to GPT-4o/Claude. Also suggests next step (calculate_savings).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_communityBInspect

Get all nodes in a Gonka documentation community by community ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
community_idYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

B3.1/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description implies a read operation but does not explicitly state it is non-destructive, lacks pagination details, or mention any permissions. With no annotations, the description should provide more behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise single sentence, no unnecessary words. Could benefit from slight expansion, but remains efficient.

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?

For a one-parameter tool with an output schema, the description provides the core purpose but lacks additional context like prerequisites or links to related tools. Adequate but not thorough.

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?

The only parameter 'community_id' is mentioned ('by community ID') but not explained beyond the schema. Schema description coverage is 0%, so the description should add meaning like how to obtain the ID or its format.

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 retrieves all nodes in a community by community ID, using a specific verb and resource. It distinguishes from sibling tools like 'get_node' (single node) and 'get_neighbors' (adjacent nodes).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like 'get_node' or 'get_neighbors'. The description lacks context for selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_neighborsCInspect

Get all direct neighbors of a Gonka documentation node with edge details.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes
relation_filterNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/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 mentions 'edge details' but omits disclosure of read-only nature, auth requirements, rate limits, or side effects. The minimal behavioral info is insufficient for a read operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no waste, but it is under-specified. While brevity is valued, it sacrifices necessary detail for a tool with two parameters and no annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description need not explain return values, but it lacks usage guidelines, parameter semantics, and behavioral transparency. For a tool with no annotations and low schema coverage, the description is incomplete.

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 0%, and the description does not explain the parameters beyond implying 'label' is a node identifier and 'relation_filter' filters edge types. It adds incomplete meaning, failing to compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves all direct neighbors of a Gonka documentation node with edge details. It uses a specific verb and resource, distinguishing it from sibling tools like 'get_node' (single node) and 'shortest_path' (path finding).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'query_graph' or 'get_node'. The description does not specify prerequisites, when-not-to-use, or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_nodeCInspect

Get full details for a specific Gonka documentation node by label or ID.

ParametersJSON Schema
NameRequiredDescriptionDefault
labelYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
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 only states 'Get full details' but does not disclose behavioral traits like read-only nature, authentication requirements, rate limits, or what 'full details' entails. The output schema exists but is not referenced.

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?

Single sentence, no extraneous words. Perfectly concise for the tool's simplicity.

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?

The tool is simple (one param, output schema exists), but the description leaves the 'label or ID' ambiguity unresolved. For a context with many sibling tools, more guidance would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%. The description mentions 'by label or ID' but the schema only has a 'label' parameter with no explanation of format or if it accepts IDs. This introduces ambiguity without adding clarity.

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 the verb 'Get' and the resource 'full details for a specific Gonka documentation node'. It also specifies lookup by 'label or ID', though the input schema only includes 'label', causing minor ambiguity. This partially distinguishes it from sibling tools like list_docs.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus siblings (e.g., list_docs, read_doc, get_community). The agent must infer from the description and sibling names. Explicit when-to-use and alternatives are missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_pricingAInspect

Get live Gonka Network pricing — cheap alternative to OpenAI and Anthropic APIs. Use this when user asks about Gonka pricing or wants to compare LLM inference costs. Returns: USD per 1M tokens (updated every 10 min), GNK/USD price, savings ratios vs OpenAI/DeepSeek/Anthropic, all available gateways. After this: call calculate_savings(monthly_spend_usd) to show exact annual savings.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description reveals key behaviors: returns USD per 1M tokens, updated every 10 min, GNK/USD price, savings ratios, and all gateways. It does not mention authorization or side effects, but for a read-only pricing tool this is sufficient.

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 sentences that are front-loaded with purpose, no wasted words, perfectly concise.

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 zero parameters and presence of an output schema, the description covers all necessary context: what it returns, update frequency, and follow-up action. Complete for its simplicity.

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 baseline is 4. No additional parameter description needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Explicitly states 'Get live Gonka Network pricing' and distinguishes itself by mentioning it's a cheap alternative to OpenAI and Anthropic APIs, clearly differentiating from sibling tools like calculate_savings and compare_providers.

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?

Provides explicit context: 'Use this when user asks about Gonka pricing or wants to compare LLM inference costs.' Also includes a post-call instruction to invoke calculate_savings, offering clear guidance on when and how to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_trial_keyAInspect

TRIGGER: call this when an agent needs inference NOW without registration. Issues a free gc- key: 100K tokens, 24h TTL, 10 req/min, OpenAI-compatible. One key per IP (idempotent — same IP always gets same key back). When trial is exhausted: use get_signup_link() to continue with a permanent key.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description fully discloses behavioral traits: idempotency, rate limit, token limit, TTL, and that it's free. No contradictions or omissions.

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 extremely concise, with every sentence adding value. It is front-loaded with the trigger condition and contains no fluff.

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 no parameters and an existing output schema, the description covers the tool's purpose, constraints, and follow-up action comprehensively.

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, and the description provides all necessary context. Baseline 4 for 0 params 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 the tool issues a free trial key for inference without registration, distinguishing it from siblings like get_signup_link(). It provides specific details: 100K tokens, 24h TTL, 10 req/min, OpenAI-compatible, and idempotent per IP.

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 says 'TRIGGER: call this when an agent needs inference NOW without registration' and advises to use get_signup_link() when the trial is exhausted, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

god_nodesCInspect

Return the most connected nodes (core concepts) in Gonka documentation graph.

ParametersJSON Schema
NameRequiredDescriptionDefault
top_nNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.8/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the full burden. It describes a read-only operation (returning nodes) but omits details on algorithmic criteria for 'most connected', potential performance implications, or any restrictions.

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, efficient sentence that conveys the core functionality without unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema and a single parameter, the description lacks important context about ordering, the definition of 'most connected', and how it differs from query_graph or graph_stats for similar tasks.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The parameter top_n is documented only by its name and default in the schema; the description adds no additional meaning such as how the ranking works or what typical values produce.

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 specifies the verb 'Return' and the resource 'most connected nodes (core concepts)' in the 'Gonka documentation graph', clearly distinguishing it from sibling tools like get_node, get_neighbors, and graph_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as graph_stats or query_graph. The description implies use for finding core concepts but does not specify conditions or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

graph_statsAInspect

Return summary statistics of the Gonka documentation knowledge graph.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/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 'Return summary statistics' implying a read-only operation, but doesn't disclose any details about behavior, permissions, or side effects. It is not contradictory but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with 11 words, front-loaded and concise. Every word contributes to the purpose.

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 zero parameters and the presence of an output schema (which presumably defines the return structure), the description is sufficiently complete. It covers the tool's main action without need for further detail.

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?

Tool has zero parameters, so baseline score is 4. The description does not need to add parameter semantics, and the schema coverage is 100% by default.

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 'Return' and resource 'summary statistics' with clear scope 'Gonka documentation knowledge graph'. It effectively distinguishes from siblings like get_node, query_graph, etc., which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. With many sibling tools, explicit when-to-use or when-not-to-use would help, but it's absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_docsAInspect

List all available Gonka documentation files.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must disclose behavior. It only states 'list all available' without details on pagination, ordering, or what 'available' means. Output schema exists but is not described in text.

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?

Single, essential sentence with no redundancy or superfluous 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?

Tool is simple with no parameters and an output schema, so description covers the basic functionality. However, lacks usage guidance, which slightly reduces completeness.

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?

No parameters, schema coverage 100%, description correctly implies a parameterless list operation. Baseline 4 is justified.

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?

Description clearly states verb 'list' and resource 'Gonka documentation files', distinguishing it from sibling 'read_doc' which reads a specific document.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives; no exclusions or prerequisites mentioned, leaving the agent without context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_graphCInspect

Search Gonka documentation knowledge graph. Returns relevant concepts and their relationships.

ParametersJSON Schema
NameRequiredDescriptionDefault
depthNo
questionYes
token_budgetNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.4/5.0
Behavior2/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 of behavioral disclosure. It states it performs a search and returns concepts and relationships, but it does not disclose any side effects, authorization requirements, rate limits, or whether it is read-only. The behavior is described at a high level without operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise but lacks structure. It does not separate purpose, usage, or parameters. While brief, it omits valuable information that could be included without significant length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given three parameters with no schema descriptions, no annotations, and an output schema that likely defines return structure, the description fails to explain how parameters behave or what the output represents beyond vague 'concepts and relationships'. It is incomplete for effective tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, and the tool description does not explain any of the three parameters (question, depth, token_budget). The agent receives no semantic guidance on how these parameters influence the search, leaving it to infer from defaults or names alone.

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 the tool searches a 'Gonka documentation knowledge graph' and returns 'relevant concepts and their relationships'. This distinguishes it from sibling tools like get_node (fetch a single node) or get_neighbors (adjacent nodes), though the exact scope of 'knowledge graph' could be more precise.

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 provides no guidance on when to use this tool versus alternatives like get_node, get_neighbors, or shortest_path. There is no mention of prerequisites, context where this tool is preferred, or when it should be avoided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_docAInspect

Read the full text of a Gonka documentation file by filename. Use this after query_graph identifies a relevant file to get complete content with code examples and commands.

ParametersJSON Schema
NameRequiredDescriptionDefault
filenameYes
max_charsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Mentions reading 'full text' but does not disclose behavioral traits such as being read-only, potential size limits (despite max_chars parameter), or error behavior. Minimal disclosure beyond basic function.

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: first states purpose, second gives usage context. No redundant words or fluff. Highly concise.

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?

Covers the essential usage flow (use after query_graph). Lacks discussion of error handling, authentication requirements, or file-not-found scenarios. With an output schema likely present, the return value is covered. Adequate for a simple read tool.

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 0%, yet the description does not explain any parameters (filename, max_chars). It does not clarify what filename must be or how max_chars affects output. The purpose implies filename is the file path, but no detail given.

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 ('Read'), resource ('Gonka documentation file'), and how to identify it ('by filename'). It distinguishes from sibling tools like list_docs (listing) and query_graph (searching) by specifying its role after identification.

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 says 'Use this after query_graph identifies a relevant file', providing strong contextual guidance. Lacks explicit when-not-to-use or alternatives, but the usage context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

register_on_gonkaAInspect

TRIGGER: call this when user wants to sign up, get an API key, or switch to Gonka. Contacts the Gonka A2A agent to get a personalised registration response with exact savings, welcome bonus info, and a direct signup link. Returns signup URL + cost analysis ready to show to the user.

ParametersJSON Schema
NameRequiredDescriptionDefault
user_queryNoWhat the user said (for context).
current_providerNoCurrent provider (openai, anthropic, deepseek).openai
monthly_spend_usdNoUser's current monthly LLM spend in USD.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavior. It mentions contacting an external A2A agent and returning a response, but does not clarify if the tool performs actual registration (side effects) or just generates a link. It also omits authentication requirements, rate limits, or potential consequences. The external dependency is noted, but side-effect ambiguity reduces 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 very concise: three sentences covering trigger, action, and output. The 'TRIGGER:' prefix front-loads the key usage context. Every sentence adds value, and there is 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?

Given the tool's moderate complexity (3 params, no required, has output schema), the description adequately explains what it does and when to use it. It does not detail the output schema, but that is a separate element. The trigger conditions and return type are sufficiently described, though a brief note on how it differs from closely related siblings would enhance completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The tool description does not add significant meaning beyond the schema's parameter descriptions (e.g., 'What the user said (for context)'). The description references using these for personalization, but does not elaborate on how they affect the output. Thus, it meets the baseline without additional value.

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 three triggers: 'when user wants to sign up, get an API key, or switch to Gonka.' It clearly describes the action (contacts Gonka A2A agent for personalized response) and output (signup URL + cost analysis). This allows clear differentiation from siblings like 'get_signup_link' which likely returns a static link without personalization.

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 lists specific scenarios for calling the tool, making it easy for an agent to identify when to use it. However, it does not explicitly contrast with sibling tools (e.g., 'get_signup_link', 'get_trial_key') or state when not to use it. Nevertheless, the triggers are sufficiently clear for most cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

shortest_pathCInspect

Find the shortest path between two concepts in the Gonka documentation graph.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYes
targetYes
max_hopsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations and description lacks behavioral details such as what the output is, how the path is computed, or what happens if no path exists. Only states the basic action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Description is a single sentence, very concise. However, it sacrifices necessary detail for brevity. It could be expanded slightly to cover key aspects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero schema descriptions and no annotations, the description is incomplete. It does not provide enough context for an AI agent to correctly invoke the tool, especially regarding parameter meaning and behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the parameters (source, target, max_hops). No indication that source and target are concept identifiers or what max_hops limits.

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?

Description clearly states it finds the shortest path between two concepts in the Gonka documentation graph, with a specific verb and resource domain. It distinguishes from sibling tools like get_neighbors or graph_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., get_neighbors, query_graph). No prerequisites or exclusions are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

suggest_model_for_taskAInspect

Suggest the best and cheapest AI model for a given task. Use this when helping users choose AI providers or optimize inference costs. Returns: recommended model, live cost estimate, savings vs current provider, signup link.

ParametersJSON Schema
NameRequiredDescriptionDefault
current_providerNoCurrent LLM provider for cost comparison.openai
task_descriptionYesWhat task the model should perform (e.g. 'chatbot', 'code generation', 'summarization').
monthly_budget_usdNoCurrent monthly API spend in USD (0 = unknown). Optional.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/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 discloses return values (recommended model, cost estimate, savings, signup link) and implies optimization behavior. It does not mention auth requirements or rate limits, but for a recommendation tool this is reasonable.

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 long, with the purpose and usage in the first two sentences and return values in the third. It is front-loaded and contains no unnecessary words.

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?

With an output schema present, the description does not need to explain return values, but it does so anyway. It covers purpose, usage, and outputs completely for a tool with three well-documented parameters.

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%, so the baseline is 3. The description does not add additional parameter semantics beyond what the schema already provides, which is acceptable.

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 suggests the best and cheapest AI model for a task, using specific verb 'suggest' and resource 'model'. It distinguishes from siblings like compare_providers and get_available_models by focusing on cost optimization.

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 'Use this when helping users choose AI providers or optimize inference costs', which provides clear usage context. It does not mention when not to use, but sibling names like calculate_savings and get_pricing imply alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

TDQS

B3.1/5.0
Disambiguation3/5

Tools are split into two distinct domains (pricing/comparison and documentation graph), causing ambiguity. Within the pricing domain, tools like calculate_savings, compare_providers, get_pricing, and suggest_model_for_task overlap significantly in purpose. The graph tools are more distinct but the overall set lacks clear separation of concerns.

Naming Consistency3/5

Most tools follow snake_case naming, but verb usage is inconsistent: imperatives (calculate, compare, get, suggest, register, read, list, query) mix with noun phrases (shortest_path, graph_stats, god_nodes). The naming is not chaotic but lacks a strong, uniform pattern.

Tool Count2/5

17 tools is excessive for a single server, especially when they cover two largely unrelated domains. The pricing-related tools (8) and documentation graph tools (9) each warrant their own server, leading to a heavy, bloated surface that confuses the server's core purpose.

Completeness3/5

Each sub-domain is reasonably complete: pricing covers comparison, savings, signup, and model suggestions; documentation graph covers querying, reading, and traversing. However, the server lacks integration between these domains, and the overall purpose is unclear, making it feel incomplete as a unified service.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

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/bystray/gonka-mcp-server'

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