Skip to main content
Glama

Zyla API Hub

by com.zylalabs

call_api

Call an API endpoint on Zyla API Hub. Requires the user's API key and a credit card on file. Billing is pay-per-successful-request: you only pay for 2xx responses. Each API has its own price per call (shown in get_api_info), and every successful response includes cost_usd — the exact amount billed for that call. There are no monthly subscriptions or minimums — usage is charged to your credit card automatically. If a 402 error is returned with a payment_url, the user MUST open that URL in their browser to add a credit card before retrying. Pass the api_id, endpoint_id, HTTP method, and parameters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
api_idYesThe numeric API ID
methodNoHTTP method: GET or POST (default: GET)
paramsNoKey-value parameters to send with the request
endpoint_idYesThe numeric endpoint ID within the API

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description fully discloses billing model (pay-per-success), cost_usd in response, 402 error handling with payment_url, and automatic credit card charging. This is comprehensive behavioral transparency.

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 moderately dense but well-structured: purpose first, then billing details, error handling, and parameter hints. Every sentence adds value, though some details like billing could be slightly more succinct.

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 4 parameters, no output schema, and no annotations, the description covers purpose, usage context, billing, error handling, and parameter usage thoroughly. It is nearly complete, though clarification on obtaining the API key is left to other tools.

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%, and the description adds value by specifying that method defaults to GET, params are key-value, and grouping api_id/endpoint_id as main identifiers. It enhances the schema information.

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 'Call an API endpoint on Zyla API Hub' with a specific verb and resource. It distinguishes from sibling tools like browse_catalog or search_catalog by focusing on API endpoint execution.

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 explains when to use (to call an API endpoint) and provides context about required user API key and credit card. It implicitly excludes other operations but does not explicitly name alternatives or when-not-to-use scenarios.

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

All Zyla API Hub toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose covering account management, catalog browsing, searching, API details, payment, and execution. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (e.g., browse_catalog, get_api_info, list_categories), with register being the only single verb but still clear.

Tool Count5/5

8 tools is well-scoped for an API hub, covering registration, account status, catalog exploration, payment setup, and API calling without unnecessary bloat.

Completeness4/5

Core workflows (register, browse, search, get info, call) are covered. Minor gap: no tool for usage history or API key regeneration, but not essential for primary use.

Resources