Skip to main content
Glama
Sign In

Veynod

by io.github.veynod
OverviewDiscussionsAdmin

Get API Docs

get_api_docs
Read-only

Return the REST/MCP connection guide and core request schemas.

Agent-readable; no admin token required. The live OpenAPI document is also
available at GET /v1/openapi.json. section="retry" returns the canonical
backoff algorithm, "errors" the full error-code registry (code -> class ->
action), "versions" the supported API versions, "capabilities" the feature
flags (on/off here) and REST endpoints without a same-named tool,
"releases" this deployment's release history, "tools" every MCP tool with
the REST method and path that does the same.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_api_docs"
  }
}

Input Schema

NameRequiredDescriptionDefault
sectionNooverview

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare it as a non-destructive read; the description adds genuine context beyond them by stating "Agent-readable; no admin token required", which removes an auth-access question for the agent. It could still say more about output volume or whether the docs are static per deployment, but the auth disclosure is the most important behavioral fact.

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?

Purpose is front-loaded in the first sentence and the section list is scannable in a single semicolon-chained paragraph. The enumeration is dense but every clause conveys distinct content; slight cost in readability from packing eight sections into one sentence.

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

Completeness4/5

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

For a one-parameter documentation tool with an output schema, the definition supplies purpose, access model, an external spec pointer, and per-section content. The remaining gap is the undescribed enum members, which an agent may need to choose the default or the "all" bundle deliberately.

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

Parameters4/5

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

Schema description coverage is 0% and the enum values are opaque on their own, so the description carries the burden and does so for about half the twelve sections, including non-obvious ones like capabilities ("feature flags on/off here and REST endpoints without a same-named tool"). It does not describe the default (overview) or what "all" returns, so coverage is informative but incomplete.

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?

States a specific verb and resource ("Return the REST/MCP connection guide and core request schemas") and frames it as agent-readable documentation rather than a data operation. No sibling tool serves this role, so an agent can identify it immediately.

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 maps six section values (retry, errors, versions, capabilities, releases, tools) to their content and points to GET /v1/openapi.json as an alternative for the live spec. However, six other enum values (guide, limits, events, tokens, all, overview) get no explanation, leaving the agent to guess when those are appropriate.

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

All Veynod toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources