Apiosk
Server Details
AI-native payments: discover, pay for, execute, and publish monetized APIs through MCP.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- obcraft/apiosk-mcp
- GitHub Stars
- 0
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.3/5 across 9 of 9 tools scored. Lowest: 3.6/5.
Every tool has a clearly distinct purpose: discover vs search are differentiated by goal (get paid data vs browse), execute vs fetch_paid distinguish hosted vs external APIs, inspect_x402 is a read-only prerequisite, and help/payment_guide serve different informational roles. There is no ambiguity between tools.
All tools follow the consistent 'apiosk_verb_noun' pattern in snake_case, with verbs like 'discover', 'execute', 'fetch_paid', 'list_wallets', etc. The naming is predictable and clearly indicates the action and resource.
With 9 tools, the server is well-scoped for a paid API discovery and execution platform. Each tool contributes to the core workflow of discovering, inspecting, paying for, and executing APIs, without being overly numerous or sparse.
The tool set covers the full consumer workflow: discovery, search, detail retrieval, payment inspection, execution, and help. Missing are wallet management actions beyond listing (e.g., creation) and provider-side publishing, but these are arguably out of scope for a consumer-focused MCP server.
Available Tools
10 toolsapiosk_discoverARead-onlyIdempotentInspect
Find 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds key behavioral context: discovery never spends automatically, paid sources are opt-in, and results include actionable executable_via field. 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?
Single, well-structured paragraph with no wasted words. Front-loaded with purpose, then usage, result semantics, and sibling differentiation. Every sentence adds value.
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 complex tool with 6 parameters, 1 required, and output schema present, the description covers all critical aspects: purpose, decomposition, source selection, result interpretation, and when to use vs. alternatives. Leaves no gaps.
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%, baseline 3. Description adds strategic context: segments parameter is pre-decomposed capabilities, and explains results structure (executable_via). Also clarifies that probes for wellknown source are explicit hosts only, adding clarity beyond schema description.
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?
Clearly states it finds the best paid x402 API for a data capability, with decomposition and ranking. It distinguishes from sibling apiosk_search by specifying when to use each: 'use this instead of apiosk_search when the goal is get real paid data for X, not just browsing.'
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 guides when to use: 'Decompose the user's request into capability segments first, then call this once per capability.' Also provides when-not-to-use by contrasting with apiosk_search. Explains sources, defaults, opt-in paid sources, and next steps via executable_via field.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_executeADestructiveInspect
Execute 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the tool's mutability is clear. The description adds no further behavioral details (e.g., side effects, authorization needs, or rate limits). With annotations present, the bar is lower, but the description misses an opportunity to provide context beyond the purpose.
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 concise sentence that front-loads the key action. It avoids unnecessary words and is efficient, though it could slightly expand on the 'execute contract' concept without losing brevity.
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 existence of an output schema (not shown) and full parameter documentation, the description is functionally complete for basic usage. However, it does not clarify the 'execute envelope' or provide examples, leaving some ambiguity for a complex generic executor 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%, so each parameter is already well-documented in the input schema. The description adds no extra meaning to the parameters; it only states the overall purpose. Baseline 3 is appropriate as the schema carries the burden.
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 'Execute any Apiosk API by slug through the uniform /execute contract,' providing a specific verb (execute) and resource (Apiosk API by slug). It distinguishes itself from sibling tools that are specialized for individual Apiosk operations, making its 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 implies use for arbitrary API execution, but lacks explicit guidance on when to use this tool versus the sibling-specific tools (e.g., apiosk_create_wallet). No alternative or exclusion criteria are provided, leaving the agent to infer from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_exploreARead-onlyInspect
Browse 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 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the read-only behavior is covered. The description adds that it explores 'one group at a time,' which hints at pagination or filtering, but does not elaborate on other traits like rate limits or how the browsing works.
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, short sentence with no redundant information. However, it could be structured to include more about parameters without being verbose. It is concise but slightly under-informative.
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 required ones, and an output schema, the description is too brief. It lacks details on how to use offset/limit, the meaning of listing groups, and the expected workflow beyond a vague 'explore then search.' The output schema exists but does not compensate for missing usage context.
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). The description does not explain the other 5 parameters, such as 'sort,' 'limit,' 'order,' 'offset,' or 'listing_type.' It implies 'listing_type' selects a group and 'search' narrows, but this is insufficient for full parameter understanding.
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 purpose: browsing Apiosk listing groups and exploring one group at a time before narrowing with search. The verb 'browse' is specific, and the mention of 'one group at a time' distinguishes it from other tools like apiosk_search.
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 a workflow: first explore groups, then use search to narrow. It provides context on when to use the tool (before search) but does not explicitly name alternatives. Given the sibling tools include apiosk_search, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_fetch_paidADestructiveInspect
Pay 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false), external (openWorldHint=true), destructive (destructiveHint=true). Description adds context: pays from connected wallet, gateway enforces wallet spend limits, failure if price higher. No contradiction. Could mention refund policy or failure modes, but sufficient.
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?
Description is front-loaded with key information (purpose, usage conditions). Slightly long but every sentence is necessary. Could be more concise, but 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?
Given complexity (8 params, payment flow, external endpoint), description covers all aspects: what it does, prerequisites, required param, optional params, security (allowlisted headers), gateway limits, idempotency for safe retry. Output schema exists but return data is implied. 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 has 100% description coverage for all 8 parameters. Description adds value by emphasizing confirmed_price_usdc must match inspection, explaining idempotency key for safe retry, and noting headers are allowlisted server-side.
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 (pay and fetch), resource (external x402 endpoint), and scope (only for external results from apiosk_discover). It distinguishes from sibling apiosk_execute for catalog listings.
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 states when to use: for external results from apiosk_discover with executable_via='apiosk_fetch_paid'. Tells when not to use: for Apiosk catalog listings use apiosk_execute. Provides step-by-step prerequisite: call apiosk_inspect_x402, inform user of price, pass as confirmed_price_usdc. Warns about gateway refusal if live price higher.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_get_apiARead-onlyInspect
Fetch 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'. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no behavioral context beyond confirming a fetch operation. 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?
Single efficient sentence, no wasted words, front-loaded with the core action.
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 simple read tool with one parameter and an output schema, the description is complete enough; no additional context about errors or limitations is necessary.
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%, with the slug parameter already described. The description adds no further parameter details, so 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 verb 'fetch' and the resource 'full listing detail and agent metadata for a specific Apiosk API slug', distinguishing it from siblings like apiosk_help or apiosk_metadata.
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?
No guidance on when to use this tool versus alternatives or any prerequisites; it merely describes the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_helpARead-onlyInspect
Explain 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds specific topics (overview, setup, auth, payments, etc.) that reveal the tool's scope, going beyond annotation defaults.
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 that front-loads the purpose. It is slightly long (33 words) but efficient, covering multiple aspects without 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?
For a help tool with an output schema (likely covering return values), the description fully covers what the tool does and the available topics. It is complete for an agent to decide when to invoke it.
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% with an enum and a description for the 'topic' parameter. The main description reiterates and supplements the enum values (e.g., 'use discovery to learn which live sources...'), adding value above 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 explains 'what Apiosk MCP is, how to connect it, how auth and USDC/x402 payments work, and the recommended workflow'. It distinguishes itself from sibling tools (e.g., apiosk_discover, apiosk_execute) as the single help/explanation 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 implies usage for learning about the system but does not explicitly state when to use this tool vs alternatives like apiosk_discover or apiosk_execute. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_inspect_x402ARead-onlyIdempotentInspect
Read 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral details beyond annotations: makes one unauthenticated request, parses 402 offer, returns exact amount, and explicitly states 'Read-only; never spends' which aligns with readOnlyHint=true and destructiveHint=false.
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?
Three sentences, no wasted words, front-loaded with key action and purpose.
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 rich annotations and full schema, the description covers usage context, purpose, and behavioral traits. Minor gap: could explicitly state that it only works on x402 resources, but it is implied by the tool name and description.
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 clear descriptions for both parameters. The description does not add additional meaning to parameters beyond what is in the schema, so baseline of 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?
Clear verb ('Read'), resource ('x402 payment terms'), and scope ('from a URL'). Distinguishes from sibling tools by explicitly stating that apiosk_execute does not need this step.
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 states when to use: after apiosk_discover on a result's URL, before paying. Also says when not to use: not needed for apiosk_execute on catalog listings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_list_walletsARead-onlyIdempotentInspect
List 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 | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds necessary authentication context without contradicting 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?
Two concise, front-loaded sentences with no extraneous information. Every sentence is necessary.
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 parameterless list tool with an output schema, the description covers the action, scope, and authentication requirements completely.
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 exist; the description fully covers what the tool does (list wallets) and whom it targets (signed-in user). Schema coverage is 100%.
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 explicitly states it lists the signed-in user's managed Apiosk wallets, with a clear verb and resource. It distinguishes from sibling tools like create, delete, and update wallets.
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?
Specifies the authentication requirement for use, but does not explicitly mention when not to use or compare with alternatives. Still provides clear context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_payment_guideARead-onlyInspect
Explain 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating no side effects. The description adds valuable behavioral context: the guide is tailored to the current authentication, covers both USDC/x402 for buyers and publishing for providers. No contradictions 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 extremely concise: three sentences that cover purpose, content, and parameter usage with no wasted words. It is front-loaded with the primary action.
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 full annotation coverage, the description provides complete context: purpose, output contents, parameter guidance, and behavioral tailoring. 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 the schema already documents both parameters. The description briefly reinforces their usage (e.g., 'slug to scope buyer guidance') but does not add significant new meaning 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 tool's purpose: 'Explain how to pay through the Apiosk gateway.' It distinguishes itself from sibling tools (mostly operational wallet/token tools) by focusing on a guidance role. The specific mention of buyer and provider guides further clarifies the scope.
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 instructions on when to use optional parameters: 'Pass slug to scope buyer guidance to one listing, or role to pick a side.' It does not explicitly mention when not to use this tool or compare it to alternatives like apiosk_help, but the context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
apiosk_searchARead-onlyInspect
Search 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context by clarifying the tool is for catalog browsing and not for direct fulfillment, aligning with annotations and avoiding contradiction.
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. First sentence states purpose, second provides usage guidance. It is front-loaded and 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?
With an output schema present and high schema coverage, the description need not elaborate on return values. It provides the essential distinction from the sibling tool, though it could slightly expand on what 'capability, price, or category' entails.
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 the baseline is 3. The description does not add additional parameter-specific details beyond what the schema provides, but this is acceptable given full 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 clearly states the tool searches and browses the Apiosk catalog by capability, price, or category. It distinguishes itself from the sibling tool apiosk_discover by noting this is for browsing/filtering, not fulfilling live data requests.
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 advises when to use this tool (browsing/filtering) and when to prefer the sibling tool apiosk_discover (for live paid data requests). This provides clear context on usage and alternatives.
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!