Zyla API Hub
Server Details
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 8 of 8 tools scored.
Each tool has a distinct purpose: account management, catalog exploration, API details, payment, registration, and API calling. No two tools overlap in functionality, making selection unambiguous.
Most tools use a verb_noun pattern (e.g., browse_catalog, get_api_info, list_categories). 'register' is a single verb and 'call_api' uses an acronym, but the overall pattern is clear and predictable.
With 8 tools, the server covers all essential operations for an API hub without being overly broad or sparse. Each tool serves a necessary function.
The surface covers the full lifecycle from registration and payment setup to discovering APIs and making calls. No obvious gaps like missing logout or usage history, but core needs are met.
Available Tools
8 toolsaccount_statusAInspect
Check the current user's account status, billing, and usage. Returns plan info, API call count, whether a credit card is on file, and any failed/pending payments. Use this to diagnose why API calls are blocked (missing card or failed payment). Requires the user's API key in the Authorization header.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the requirement for an API key in the Authorization header and describes the return data. It implies read-only behavior but does not explicitly mention side effects or rate limits. Still, it is sufficiently transparent for a status check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences covering purpose, return values, usage scenario, and authentication requirement. Every sentence is informative and earns its place. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description completely explains the return values (plan info, API call count, credit card, payments) and the usage context (diagnose blocked calls). It is thorough for a simple read-only status tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. Baseline for 0 params is 4. The description adds value by explaining what the tool returns and when to use it, even though there are no parameters to document. It does not detract from parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it checks account status, billing, and usage, listing specific return fields (plan info, API call count, credit card on file, failed/pending payments). This clearly distinguishes it from siblings like get_api_info or browse_catalog.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies when to use: 'diagnose why API calls are blocked (missing card or failed payment).' It also mentions the prerequisite of requiring the user's API key in the Authorization header. While it does not explicitly state when not to use or name alternatives, the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
browse_catalogAInspect
Browse the full Zyla API Hub catalog with pagination. Use this to explore ALL public APIs beyond the top 500. Supports filtering by category and search keyword. Returns paginated results with total count and page info.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (default: 1) | |
| sort | No | Sort order: "popularity", "newest", or "name" (default: popularity) | |
| search | No | Search keyword to filter APIs by name or description (server-side search across ALL public APIs) | |
| category | No | Filter by category name (use list_categories to see available categories) | |
| per_page | No | Results per page (default: 20, max: 100) | |
| include_params | No | If true, include full endpoint parameters in the response (default: false, to keep responses compact) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility. It discloses pagination behavior, filtering, search, and that results include total count and page info. It does not explicitly state read-only or idempotent nature, but for a browse tool, the behavior is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence provides the primary purpose and pagination, and the second expands on usage. Every phrase adds value, and the structure is front-loaded for quick scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers all key aspects: browsing, pagination, filtering, search, and the include_params option. It lacks details on error handling or rate limits, but for a catalog browse tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description adds meaningful context: 'beyond the top 500' for overall scope, 'server-side search across ALL public APIs' for search, cross-reference to list_categories for category, and the rationale for include_params defaulting to false. This enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'browse' and the resource 'full Zyla API Hub catalog', and adds the key differentiator 'beyond the top 500', distinguishing it from sibling tools like search_catalog and list_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using this tool to explore APIs beyond the top 500 and mentions filtering by category and search keyword. However, it does not directly contrast with the sibling search_catalog or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
call_apiAInspect
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). There are no monthly subscriptions or minimums — charges appear on your credit card at the end of each billing cycle. 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.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | The numeric API ID | |
| method | No | HTTP method: GET or POST (default: GET) | |
| params | No | Key-value parameters to send with the request | |
| endpoint_id | Yes | The numeric endpoint ID within the API |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses billing behavior, pay-per-successful-request, requirement for credit card, and specific error handling (402 with payment_url). It does not mention rate limits or destructive behavior, but for an API call tool, the safety profile is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently front-loaded with the core purpose, followed by essential usage details. Every sentence adds necessary context without redundancy. It is well-structured for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description does not explain what the tool returns (response body, status codes beyond 402). Given the tool makes API calls, return value information is important. Also, it doesn't detail how params are sent (query vs body). This leaves moderate gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about usage (requires api_id and endpoint_id, method default GET, params key-value) and ties parameters to billing/error handling. This adds value beyond the schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it calls an API endpoint on Zyla API Hub, which is distinct from sibling tools like browse_catalog or get_api_info. The verb 'call' and resource 'API endpoint' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit prerequisites (API key, credit card on file), billing model (pay-per-successful-request, no subscriptions), and error handling for 402 errors with payment_url. It does not explicitly state when not to use this tool versus alternatives, but the sibling context implies this is for executing API calls while others are for browsing/info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_api_infoAInspect
Get full details of a specific Zyla API by its numeric ID. Returns the API name, description, category, price per successful call (USD), average latency (ms), and all endpoints with their parameters, example values, and a formal JSON Schema (input_schema) for argument validation.
| Name | Required | Description | Default |
|---|---|---|---|
| api_id | Yes | The numeric API ID (e.g. 781) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description clearly states read operation and rich return data, no destructive hints or contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded purpose, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple read tool: describes all return fields including endpoints and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds example value (e.g. 781) beyond schema's type, enhancing meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get full details' and resource 'Zyla API', distinguishes from sibling tools like browse_catalog which list APIs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by numeric ID, but no explicit when-to-use vs alternatives like search_catalog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_payment_urlAInspect
Get a Stripe Checkout URL so the user can add or update their credit card. REQUIRED after registration and whenever a 402 error occurs. The user must open the returned URL in their browser to add/update their card. Billing is pay-per-successful-request: no subscriptions, no monthly fees, no minimums. You are only charged for successful API responses (2xx). Prices vary per API (see get_api_info). API calls are blocked until a valid credit card is on file.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavior: returns a URL, requires user action, explains billing model (pay-per-success), and warns that API calls are blocked without a valid card.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative and front-loaded with the key action. It includes extra billing details which, while relevant, make it slightly longer than strictly necessary. Still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides all necessary context: what the tool does, when to use it, how the result is used, and important billing/blocking implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, and schema coverage is 100%. The description implicitly confirms zero parameters, and the context about billing and blocking adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a Stripe Checkout URL for payment, distinguishing it from siblings like account_status or call_api. The verb 'Get' and resource 'Stripe Checkout URL' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: 'REQUIRED after registration and whenever a 402 error occurs.' Also instructs that the user must open the URL in a browser, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categoriesAInspect
List all available API categories on Zyla API Hub with the real count of public APIs in each. Use the category names returned here as the "category" parameter in browse_catalog to filter APIs by category. Example categories: Sports, Finance, Data, Science, etc.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states that it lists categories with 'real count of public APIs', implying read-only behavior. However, it does not explicitly mention safety, authentication, or rate limits, which is acceptable for a simple listing tool but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Every sentence adds value: first defines the tool, second explains usage in context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what is returned (categories and count). It is complete for the tool's simplicity, though it could mention ordering or absence of pagination for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. Schema coverage is 100% vacuously, and baseline for 0 params is 4. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'available API categories' with the real count of public APIs. It distinguishes itself from sibling tools, especially browse_catalog, by explaining that the output should be used as a parameter for filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (to get categories) and how to use its output (as the 'category' parameter in browse_catalog). It provides clear context but does not specify exclusions or alternative tools for edge cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
registerAInspect
Register a new Zyla API Hub account directly from the AI agent. Returns an API key AND a payment_url. The user MUST open the payment_url in their browser to add a credit card before making any API calls. Billing model: pay-per-successful-request with no monthly fees or minimums. Each API has its own per-call price. The credit card is only charged at the end of the billing cycle for actual usage. No authentication required to call this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the user | |
| Yes | Email address (must be unique) | ||
| password | Yes | Password (min 8 characters) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description covers all key behavioral traits: returns API key and payment_url, user must add credit card, billing model (pay-per-successful-request, no monthly fees, per-call price, charged at end of cycle), and no authentication required. This is comprehensive and helps the agent understand side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is approximately 5 sentences and provides all necessary information without redundancy. It is well-structured with the purpose first, followed by key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of registration with payment flow and no output schema, the description adequately covers the process and user action needed. It is missing details on error handling (e.g., duplicate email), but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the descriptions in the schema already document the parameters. The tool description adds no additional semantic information beyond what is in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Register a new Zyla API Hub account'. It distinguishes from siblings by being the only account creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: to register a new account directly from the AI agent. It also explains the required user action (open payment_url). However, it does not explicitly list alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_catalogAInspect
Semantic search across ALL 10,000+ public APIs on Zyla API Hub. Natural-language queries work best (e.g. "validate an email address", "get stock prices"). Returns matching APIs ranked by relevance with their ID, name, description, category, price per successful call (USD), average latency (ms), and endpoints summary.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results to return (default: 10) | |
| query | Yes | What you need, in natural language (e.g. "validate an email address", "currency conversion", "weather forecast by city") |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool performs semantic search and returns specific fields (ID, name, description, category, price, latency, endpoints). It does not mention authentication, rate limits, or potential side effects, but the operation is clearly a read-only search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and every sentence adds value. No wasted words, and it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return fields comprehensively. It covers the tool's scope (10,000+ APIs) and return details. It lacks information on pagination or empty results handling, but overall is sufficient for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'query' and 'limit'. The description adds value by emphasizing natural-language queries and providing examples, which helps the agent understand how to use the 'query' parameter effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Semantic search across ALL 10,000+ public APIs on Zyla API Hub' with a specific verb and resource, and it distinguishes from sibling tools like 'browse_catalog' and 'call_api' by highlighting its search and ranking nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance that natural-language queries work best with examples, implying the tool is for searching rather than browsing or calling. It does not explicitly state when not to use it, but the context from sibling tools and the description itself provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!