The Apiosk MCP lets AI agents discover, pay for, execute, and publish APIs through the Apiosk gateway. It is a machine endpoint, not a website, so connect it from an MCP client (Claude, Cursor, ChatGPT, and others) rather than browsing it here.
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.
Average 4.2/5 across 10 of 10 tools scored. Lowest: 3.2/5.
Each tool targets a distinct action: discover vs search differ in goal (paid data vs browsing), execute vs fetch_paid separate internal vs external APIs, inspect_x402 is read-only payment inspection, etc. No overlapping purposes.
All tools start with 'apiosk_' and use snake_case, but the verb pattern is not uniform: most are verb_noun (get_api, list_wallets), one is noun_noun (payment_guide), and some are verb_adj (fetch_paid). This minor inconsistency prevents a perfect score.
10 tools cover discovery, inspection, execution, payment, wallet listing, and help. This is well-scoped for a paid API marketplace MCP server without being too heavy or thin.
The consumer workflow is well-covered: find (discover, search, explore), inspect (inspect_x402), pay (fetch_paid), execute (execute), and manage wallets (list_wallets). Missing tools for provider-side publishing or wallet management beyond listing, but that's likely out of scope.
apiosk_discoverAFind the best paid x402 API for a data capability across discovery sources (Apiosk catalog + federated external listings). Decompose the user's request into capability segments first, then call this once per capability. Returns a normalized, ranked list; each result's executable_via says whether to call apiosk_execute (Apiosk-settled) or apiosk_inspect_x402 + apiosk_fetch_paid (external). Use this instead of apiosk_search when the goal is 'get real paid data for X', not just browsing.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The data capability to find, e.g. 'realtime USD exchange rate' or 'company registry lookup by domain'. | |
| sources | No | Discovery sources to query. Default ['apiosk','bazaar']. Use ['all'] for every directly wired free REST source. Paid sources 'x402scan' and 'apify' are opt-in and return their payable endpoint for apiosk_inspect_x402 + apiosk_fetch_paid; discovery never spends automatically. Add 'wellknown' with probe_hosts for a specific host. | |
| segments | No | Optional: the user's request pre-decomposed into distinct data capabilities. Each is searched and merged. | |
| max_results | No | Maximum results to return (default 8, max 25). | |
| probe_hosts | No | For the 'wellknown' source: explicit hostnames to probe for a /.well-known/x402 document (e.g. 'x402.example.com'). No speculative crawling — only hosts you name here are probed. | |
| max_price_usdc | No | Optional per-call price ceiling in USDC. Results above this are dropped. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is set. The description adds behavioral context by explaining that the tool returns a normalized, ranked list and that each result includes an `executable_via` routing indicator. It also mentions that discovery never spends automatically (via the schema's sources parameter). This goes beyond the annotations without contradicting them.
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 three sentences, each earning its place: purpose/scope, procedural guidance, and differentiation from sibling. It is front-loaded with the core action and avoids fluff. The structure is highly efficient.
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?
The tool has a complex discovery/routing feature set, but the description, combined with a complete input schema and an output schema, covers the essential context: what it finds, how to call it, and how to interpret routing. It could mention a concrete example or edge cases, but the current description is sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all six parameters have descriptions. The main description adds usage-level guidance (e.g., decomposing into segments, using `segments` for pre-decomposed requests) but does not substantially enhance parameter semantics beyond the schema. Baseline 3 is appropriate.
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 opens with a specific verb and resource: 'Find the best paid x402 API for a data capability across discovery sources.' It clearly separates this tool from apiosk_search by stating 'Use this instead of apiosk_search when the goal is get real paid data for X, not just browsing.' This makes the tool's purpose unambiguous and distinguishes it from siblings.
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?
Explicit guidance is given on when to use the tool ('Use this instead of apiosk_search when the goal is get real paid data for X') and how to call it ('Decompose the user's request into capability segments first, then call this once per capability'). The description also explains how to route results via `executable_via`, giving concrete next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_executeCExecute any Apiosk API by slug through the uniform /execute contract.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Apiosk API slug. | |
| input | No | Raw JSON body for the default operation, or the envelope input field when operation is provided. | |
| query | No | Optional query override when using the execute envelope. | |
| operation | No | Optional explicit operation id or path. | |
| path_params | No | Optional path parameter override when using the execute envelope. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive potential (destructiveHint=true), but the description does not disclose any behavioral traits such as side effects, potential costs, or need for user confirmation. It simply says 'execute any API', which is overly broad and fails to warn about the consequences of invoking arbitrary operations.
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 a single efficient sentence with no wasted words, and it's front-loaded with the main purpose. However, it could be slightly more structured to explain the /execute contract, but it's not verbose.
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?
The tool is complex: it can execute any API with optional operation, query, and path parameters, and it has destructive annotations. The one-sentence description does not explain the execute envelope, the meaning of 'default operation', or how to choose between direct input and envelope mode. This is insufficient for reliable use despite the presence of an output 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?
With 100% schema coverage, the input schema provides descriptions for all 5 parameters. However, the description itself adds no extra clarity on how parameters like `input`, `operation`, and `path_params` interact, and the two execution modes (default operation vs. envelope) are ambiguous. Baseline 3 is appropriate since the schema covers the parameter meanings.
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 identifies a specific action ('Execute') and a resource ('any Apiosk API by slug'), distinguishing it from sibling discovery/search tools. However, the phrase 'uniform /execute contract' is jargon and not self-explanatory, so it could be clearer about what execution entails.
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 no guidance on when to use this tool versus alternatives like apiosk_discover, apiosk_get_api, or apiosk_search, and it doesn't mention prerequisites such as payment or authentication. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_exploreABrowse Apiosk listing groups and explore one group at a time before narrowing with search.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| order | No | ||
| offset | No | ||
| search | No | Optional free-text search when listing_type is set. | |
| listing_type | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe read-only operation (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds useful behavioral context: 'explore one group at a time' highlights a group-scoped approach uncommon in search tools. It does not discuss pagination or output details, but the output schema likely covers returns. No contradiction with annotations.
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 a single sentence of 17 words, front-loaded with the primary action and resource, and ends with a usage hint. Every word earns its place; there is no repetition of schema or annotation information.
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?
The output schema exists and handles return values, but the description does not fully clarify how 'explore one group at a time' works operationally or how it differs from apiosk_discover. Given the tool's 6 parameters and sibling competition, the description could better explain the grouping mechanism and search prerequisites for a complete picture.
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 only 17% (only 'search' has a description), but the enums for sort, order, and listing_type are self-explanatory. The description adds semantic context for 'listing_type' (one group at a time) and 'search' (narrowing), but it does not explain limit, offset, or the interaction between listing_type and search beyond what the schema already states. It partially compensates for low coverage but not fully.
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's function: 'Browse Apiosk listing groups and explore one group at a time.' It uses a specific verb (browse/explore) and resource (Apiosk listing groups), and explicitly contrasts with search ('before narrowing with search'), which distinguishes it from sibling tools like apiosk_search and apiosk_discover.
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 phrase 'before narrowing with search' provides clear guidance on when to use this tool relative to search, implying it is a preliminary exploration step. However, it does not explicitly name alternative tools or state when not to use it, leaving some ambiguity about its relationship to apiosk_discover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_fetch_paidAPay an EXTERNAL x402 endpoint (one Apiosk does not host) from the connected wallet and return its data. Use this only for external results from apiosk_discover (executable_via='apiosk_fetch_paid'); for Apiosk catalog listings use apiosk_execute. REQUIRED: call apiosk_inspect_x402 on the url first, tell the user the exact price, and pass that amount as confirmed_price_usdc — the gateway refuses if the live price is higher. The gateway enforces the wallet's per-tx/daily spend limits. Base + USDC only.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The external x402 resource URL to pay and fetch (from a discovery result's `url`). | |
| body | No | Optional JSON request body for POST/PUT/PATCH. | |
| query | No | Optional query parameters to send to the provider. | |
| method | No | HTTP method for the provider request. Defaults to GET. | |
| headers | No | Optional extra request headers (allowlisted server-side; secrets are never accepted here). | |
| max_price_usdc | No | Optional additional per-call ceiling. The gateway also enforces the wallet's per-tx and daily limits. | |
| idempotency_key | No | Optional. Reuse the same key to safely retry without paying twice; a fresh one is generated if omitted. | |
| confirmed_price_usdc | Yes | The price you read via apiosk_inspect_x402 and confirmed with the user. The gateway refuses if the live price exceeds this. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate destructiveHint=true and readOnlyHint=false, the description enriches with critical behavioral details: it requires a confirmed price, the gateway refuses if the live price exceeds the confirmed amount, per-tx/daily spend limits are enforced, and only 'Base + USDC' is supported. It also notes that secrets in headers are never accepted, adding safety context beyond the schema.
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 yet dense: three sentences cover the core purpose, usage boundaries, and critical workflow requirements. Every sentence adds essential information without fluff. The structure front-loads the primary action and follows with the necessary disambiguation and mandatory steps.
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?
For a high-complexity tool with 8 parameters and an output schema, the description covers the essentials: external vs. catalog use, the inspect-first flow, price confirmation, limits, and currency. It leverages the output schema for return values and the schema for parameter details, filling in the workflow gaps that are not otherwise specified.
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 baseline is 3. The description adds meaningful context for confirmed_price_usdc by explaining it must come from apiosk_inspect_x402 and be user-confirmed, and that the gateway enforces it. It also clarifies max_price_usdc as an additional ceiling. This goes beyond the schema's simple descriptions, warranting a 4.
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's function: paying an external x402 endpoint and returning its data. It explicitly distinguishes itself from sibling tools by specifying 'Use this only for external results from apiosk_discover' and 'for Apiosk catalog listings use apiosk_execute', making its unique purpose 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 usage guidance: it says when to use this tool (external results from apiosk_discover with executable_via='apiosk_fetch_paid') and when not to (Apiosk catalog listings should use apiosk_execute). It also mandates a prerequisite step: call apiosk_inspect_x402 first, pass the confirmed price, and warns of gateway refusal if the price is higher.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_get_apiAFetch full listing detail and agent metadata for a specific Apiosk API slug.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Apiosk API slug, for example 'agent-json-diff'. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description's 'Fetch' aligns with this safe read operation. The description adds context about what is fetched (full listing detail and agent metadata) but does not disclose additional behavioral aspects such as rate limits or response size, which is acceptable given the strong annotation coverage.
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 a single, clear sentence that immediately states the action and object. It contains no filler or redundant information, making it highly scannable for an AI agent.
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?
With an output schema present, the description does not need to explain return values. The tool is simple (one required parameter, safe read operation), and the description fully covers the purpose and scope. A minor gap is the lack of guidance on when to use this versus sibling tools, but that is more relevant to the usage dimension.
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% for the single 'slug' parameter, and the schema already includes an example. The description does not add new parameter details, but it does reinforce that the slug identifies a specific Apiosk API, matching the baseline for high schema coverage.
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 uses a specific verb 'Fetch' with a clear resource: 'full listing detail and agent metadata' for a specific Apiosk API slug. This distinguishes it from sibling tools like 'apiosk_search' or 'apiosk_discover' by emphasizing retrieval of a complete detail record for a known slug.
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 implies usage when you have a specific slug and need full listing/agent metadata, but it does not explicitly state when to avoid this tool or mention alternatives. With several sibling tools, explicit guidance would improve differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_helpAExplain what Apiosk MCP is, how to connect it, how auth and USDC/x402 payments work, and the recommended workflow for discovery, wallets, and publishing.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional help topic. Defaults to overview. Use 'discovery' to learn which live sources apiosk_discover searches (Apiosk catalog + Coinbase Bazaar + well-known); use 'rails' for how USDC/x402 settlement works. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description's 'explain' action aligns with that. The description adds context about covering setup, auth, and payments, but does not disclose any deeper behavioral traits (e.g., whether it makes network calls, response length, or that it is purely informational). No contradiction with annotations.
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 a single, well-structured sentence that front-loads the verb 'Explain' and immediately lists the scope. It is concise with no filler or redundant phrasing.
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 presence of an output schema and read-only annotations, the description adequately covers the tool's purpose and scope. It could explicitly note that it is the go-to for help, but the context is sufficient for a help 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?
Schema coverage is 100% and the parameter description already details specific topics (e.g., 'discovery' and 'rails' with additional context). The main description adds marginal value by listing the topics in prose, but the schema carries the semantic weight, so a baseline 3 is appropriate.
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 explains Apiosk MCP, connection, auth, payments, and workflow. This establishes a specific verb ('explain') and resource, and distinguishes it from sibling action tools like apiosk_discover or apiosk_execute.
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 main description does not explicitly say when to use this tool versus alternatives. It implies usage via its explainer nature, but lacks direct guidance like 'use when you need help' or 'instead of using discovery directly, consult this.' Additional topic-specific guidance exists in the parameter schema, but not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_inspect_x402ARead an arbitrary URL's x402 payment terms (price, asset, network, payTo) WITHOUT paying. Use this on an external result's url from apiosk_discover before paying: it makes one unauthenticated request, parses the 402 offer, and returns the exact amount so you can confirm the price with the user. Read-only; never spends. apiosk_execute (for Apiosk catalog listings) does not need this.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The https:// URL of the x402 resource to inspect (e.g. a federated listing's resource URL). | |
| method | No | HTTP method the resource charges on. Defaults to GET. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with annotations marking readOnlyHint and idempotentHint, the description adds valuable behavioral context: it makes one unauthenticated request, parses the 402 offer, and returns the exact amount. The phrase 'Read-only; never spends' reinforces the safety profile without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action and then usage guidance and alternatives. Every sentence serves a purpose, with no redundant filler.
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 tool's simplicity (2 parameters, 1 required), the presence of an output schema, and strong annotations, the description covers all necessary context: purpose, usage trigger, behavioral expectations, and an exclusion for sibling tools. Nothing essential is missing.
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 extra context by specifying that the url is an external result from apiosk_discover, and it mentions the return of the exact amount, but it does not elaborate on the method parameter beyond the schema. Still, the added context slightly elevates the score.
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 reads x402 payment terms from an arbitrary URL without paying, using a specific verb and resource. It distinguishes itself from siblings by explicitly noting that apiosk_execute does not need this tool for Apiosk catalog listings. This makes the purpose unambiguous and differentiated.
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?
Explicit when-to-use guidance is provided: 'Use this on an external result's url from apiosk_discover before paying.' It also gives a when-not-to-use alternative by stating 'apiosk_execute (for Apiosk catalog listings) does not need this.' This fully satisfies the dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_list_walletsAList the signed-in user's managed Apiosk wallets. Requires an Apiosk dashboard session from local env auth or hosted MCP authorization.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and idempotent. The description adds value by specifying the auth requirement and user scoping ('signed-in user's managed wallets'), which goes beyond the structured annotations. No 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?
The description is a concise two-sentence structure that immediately states the purpose and then adds the auth requirement. Every word earns its place with no redundancy.
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 simplicity of the tool (no parameters, annotations covering safety, and an output schema present), the description covers the essential context: what it lists, who it lists for, and the required auth. No gaps that would hinder selection or 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?
The tool has zero parameters, so the baseline is 4. The description appropriately does not attempt to explain parameters, and the schema has 100% coverage with an empty object. No additional semantics needed.
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's function with a specific verb ('List') and resource ('signed-in user's managed Apiosk wallets'). However, it does not explicitly distinguish this from sibling tools like apiosk_search or apiosk_explore, so it misses the top score.
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 a clear prerequisite (requires an Apiosk dashboard session) but gives no guidance on when to use this tool versus alternatives. The usage context is implied rather than explicitly contrasted with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_payment_guideAExplain how to pay through the Apiosk gateway. Returns a buyer guide (how an agent settles a paid API call over USDC/x402, tailored to the current auth) and a provider guide (how to publish an API and get paid). Pass slug to scope buyer guidance to one listing, or role to pick a side.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Which side to explain. Defaults to both. | |
| slug | No | Optional API slug to scope buyer guidance (price, payment steps) to one listing. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so no safety contradiction exists. The description adds useful behavioral context by stating it returns two distinct guides, that buyer guidance is 'tailored to the current auth,' and that slug and role alter the output—these are non-obvious behaviors beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: two sentences that first state the core verb and resource, then detail the returned artifacts and parameter behavior. Every clause earns its place, with no fluff or repetition.
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 tool's informational nature, read-only annotations, and presence of an output schema, the description covers all necessary context: buyer/provider perspectives, role and slug usage, and auth tailoring. No important behavioral or scope information is missing.
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 baseline is 3. The description enriches both parameters by explaining their purpose: 'Pass slug to scope buyer guidance to one listing, or role to pick a side.' This adds real semantic value beyond the schema's terse descriptions.
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 uses the clear verb 'Explain' plus a specific resource: 'how to pay through the Apiosk gateway.' It explicitly differentiates the tool by describing both a buyer guide and a provider guide, which distinguishes it from sibling tools like apiosk_discover, apiosk_execute, or apiosk_help.
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 gives clear usage context: it explains when to use for buyers ('how an agent settles a paid API call') and when for providers ('how to publish an API and get paid'). It also explains how parameters affect usage (slug scopes buyer guidance, role picks a side), but it doesn't explicitly name alternative tools or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_searchASearch and browse the Apiosk catalog by capability, price, or category. For browsing/filtering the catalog. When the goal is to fulfil a user request with real paid data ('get me the live X'), prefer apiosk_discover, which decomposes the need and ranks the best endpoints across sources.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order for results. | |
| limit | No | Maximum number of APIs to return. | |
| order | No | Sort direction. | |
| offset | No | Pagination offset. | |
| search | No | Free-text search over API names and descriptions. | |
| category | No | Optional category filter. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the safety profile is covered. The description adds behavioral scope by clarifying this is for catalog browsing/filtering rather than fulfilling live data requests, which is a useful distinction beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the action and scope. It includes the key alternative guidance without redundancy, making it efficiently concise.
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 a full output schema, complete parameter coverage in the schema, and clear annotations, the description sufficiently covers purpose, usage, and sibling differentiation. No critical information is missing for a search/browse 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?
Schema covers 100% of parameters with descriptions, so the baseline is 3. The description mentions search by capability, price, or category, which aligns with schema fields but adds no new parameter-level 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?
The description uses a specific verb 'Search and browse' with a concrete resource 'Apiosk catalog' and scope 'by capability, price, or category.' It also distinguishes from sibling apiosk_discover, making the purpose unmistakable.
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?
It explicitly states when to use this tool ('For browsing/filtering the catalog') and when not to ('When the goal is to fulfil a user request with real paid data... prefer apiosk_discover'), naming the alternative tool and the reasoning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publish_x402_routePublish a paid x402 routeAPublish an API endpoint as a paid x402 route on the Apiosk gateway. The route gets a paid URL that returns 402 Payment Required until the caller pays in USDC, then forwards to your upstream API. New routes enter Apiosk's review queue (status pending_review) and go live on approval. Requires an Apiosk provider token (Authorization: Bearer sk_live_…).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Human-readable API name, e.g. 'Weather API'. | |
| path | No | Public path under the route's gateway slug, e.g. /weather. Defaults to the last segment of upstream_url. | |
| slug | No | Optional gateway slug override (lowercase letters, numbers, hyphens). Defaults to a slug derived from name. | |
| tags | No | ||
| price | Yes | Price per call in USDC, e.g. "0.01". | |
| method | No | Defaults to GET. | |
| network | No | Settlement network. Defaults to base. | |
| currency | No | Only USDC is supported. | |
| description | No | ||
| input_schema | No | ||
| upstream_url | Yes | Full HTTPS URL of your existing endpoint the gateway forwards paid requests to. | |
| output_schema | No | ||
| settlement_address | Yes | Wallet that receives 98% of each payment (Apiosk keeps a 2% platform fee). |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate mutation and open-world side effects. The description adds that routes return 402 until payment, forwards to upstream, and mentions the review process and token requirement, providing meaningful behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with no filler; the first sentence front-loads purpose, the rest cover route behavior, review process, and authentication. Each clause contributes necessary information.
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 13 parameters, the description captures the tool's purpose, behavior, and auth requirements, with the output schema handling return-value documentation. It omits edge cases like duplicate routes or failure scenarios, but for an initial selection it is nearly 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?
Schema description coverage is 69% with required parameters (name, upstream_url, price, settlement_address) all described. The description does not restate parameters but mentions the 2% fee and payment flow, supporting understanding of price and settlement_address. However, parameters like tags, input_schema, and output_schema lack descriptions, and the description does not compensate.
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 begins with 'Publish an API endpoint as a paid x402 route on the Apiosk gateway', clearly identifying the action (publish), resource (API endpoint), and target (Apiosk gateway). It distinguishes from sibling tools like apiosk_execute and apiosk_fetch_paid by focusing on route creation rather than consumption.
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 notes that new routes enter a review queue and go live on approval, and requires a provider token, giving clear operational context. It implies this tool is used to monetize an upstream API, but does not explicitly exclude alternatives or mention when not to use it.
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.
No comments yet. Be the first to start the discussion!
