audioknihy.cz Catalog
Server Details
Czech audiobook catalog MCP server. Search 12 000+ titles + compare prices across 5 partners.
- 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.1/5 across 9 of 9 tools scored. Lowest: 3.5/5.
Some tools overlap, notably 'get_audiobook' already includes a full offer table, making 'compare_all_offers' largely redundant. 'find_cheapest_offer' is a subset. Other tools are distinct but the overlap reduces clarity.
Names use snake_case but verbs are mixed: 'browse_', 'list_', 'search_', 'get_', 'compare_', 'find_'. No single pattern is followed, causing minor inconsistency.
9 tools is well-scoped for an audiobook catalog with browsing, search, details, and price comparison. Each tool serves a clear purpose without being excessive.
Covers most expected operations: browse, search, get details, compare prices. Minor gap: no direct 'get audiobooks by genre' but search_by_filters can achieve it. Overall, no critical missing operations.
Available Tools
9 toolsbrowse_genresBrowse GenresARead-onlyIdempotentInspect
List all 35 Czech audiobook genres with audiobook counts. Discovery entry point — agents enumerate genres before drilling into a specific one.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds the specific behavior of listing 35 genres with counts, which is consistent with annotations and provides useful detail.
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 key information: what it does (list genres with counts) and its role (discovery entry point). Every word earns its place, with zero 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 simple listing tool with no parameters and an existing output schema, the description provides all necessary context: the number of genres, the inclusion of counts, and its role in the workflow. No gaps remain.
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 no parameters, and the schema coverage is 100% (no parameters to describe). The description adds no parameter info, which is appropriate. Baseline score of 4 for zero-parameter tool.
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', the resource 'genres', and specifies that it includes audiobook counts, distinguishing it from sibling tools as a discovery entry point.
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 identifies this as a discovery entry point for agents to enumerate genres before drilling into a specific one, providing clear usage context. It does not explicitly state when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_all_offersCompare All OffersARead-onlyIdempotentInspect
Full price comparison table across every active retail partner for one audiobook. Returns price + format + last-seen timestamp per partner — agents can rank or filter.
| Name | Required | Description | Default |
|---|---|---|---|
| work_slug | Yes | Work slug (lowercase, hyphenated). Example: "to". | |
| author_slug | Yes | Author slug (lowercase, hyphenated). Example: "stephen-king". |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, describing safe behavior. The description adds context by specifying returned fields (price, format, timestamp) and the scope (one audiobook, all partners), enhancing transparency 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 sentences, front-loading the purpose and providing essential detail without redundancy. Every element earns its place.
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 params, output schema exists), the description covers purpose, scope, and output fields. It does not mention pagination or error cases, but these are minor given the 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 100% with descriptions and examples for both parameters. The description adds no new parameter-level details, so baseline score 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?
The description clearly states it returns a full price comparison table across all active retail partners for one audiobook, listing specific output fields (price, format, timestamp). This differentiates it from sibling tools like find_cheapest_offer (subset) and get_audiobook (book details).
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 comprehensive price comparison but does not explicitly state when to use this tool versus alternatives like find_cheapest_offer. No disclaimers about prerequisites or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_cheapest_offerFind Cheapest OfferARead-onlyIdempotentInspect
Lowest-price active offer for an audiobook across all affiliate partners. USP — only Czech site that compares audiobook prices across all major retail partners.
| Name | Required | Description | Default |
|---|---|---|---|
| work_slug | Yes | Work slug (lowercase, hyphenated). Example: "to". | |
| author_slug | Yes | Author slug (lowercase, hyphenated). Example: "stephen-king". |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint; the description adds no additional behavioral context beyond stating the tool's core function, so it does not increase transparency beyond what annotations offer.
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 with no wasted words; the purpose is front-loaded and efficiently communicated 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?
Given the presence of an output schema and the simple two-parameter query, the description adequately covers the tool's purpose; however, it could mention that the response includes details like price and partner, though output schema likely covers that.
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 examples for both parameters; the description does not add any additional meaning or context beyond the schema, so it meets the baseline for high 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?
Description clearly states it finds the lowest-price active offer for an audiobook across all affiliate partners, and highlights its unique selling point as the only Czech site comparing prices across major retail partners, effectively distinguishing it from sibling tools.
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 explicit guidance on when to use this tool versus alternatives like compare_all_offers; the description lacks usage context and does not mention scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audiobookGet Audiobook DetailARead-onlyIdempotentInspect
Full audiobook detail by author + work slug — title, description, cover, runtime, ISBN, genres, narrator, publisher, and the full table of active offers across retail partners.
| Name | Required | Description | Default |
|---|---|---|---|
| work_slug | Yes | Work slug (lowercase, hyphenated). Example: "to". Combined with author_slug forms the canonical work URL. | |
| author_slug | Yes | Author slug (lowercase, hyphenated). Example: "stephen-king". Discoverable via search_audiobooks results. |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is clearly safe and idempotent. The description adds value by specifying the returned fields but does not disclose any additional behavioral traits (e.g., rate limits, caching, auth requirements). The description does not contradict 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 that front-loads the core functionality and enumerates returned fields. It is concise and informative, without redundant phrasing. Minor improvement could be breaking into bullet points for clarity, but current form is 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?
Given the presence of an output schema (context signals indicate true) and annotations that clearly define safety, the description is sufficiently complete for a read-only detail endpoint. It lists all major return fields, though it omits potential error conditions or non-field data (e.g., response structure). Still adequate for most use cases.
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% (both parameters have descriptions with examples and constraints). The description mentions 'by author + work slug' but does not add new meaning beyond the schema. With full schema coverage, 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 returns 'full audiobook detail' and enumerates specific fields (title, description, cover, runtime, ISBN, genres, narrator, publisher, offers). The verb 'get' combined with the resource 'audiobook detail' and required author/work slug makes the purpose unambiguous and distinguishes it from siblings like get_author or search_audiobooks.
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 like search_audiobooks or compare_all_offers. There is no mention of prerequisites, fallbacks, or when not to use it. The description assumes the agent knows when to fetch details by slug, but without context, it may select this tool inappropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_authorGet Author ProfileARead-onlyIdempotentInspect
Author profile + their audiobook works. Returns biography, photo, country, and the full list of audiobook editions where this person is credited as author / co-author / editor.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Author slug (lowercase, hyphenated). Discoverable via search_audiobooks results. Example: "stephen-king". |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds valuable context by detailing the returned data (biography, photo, country, full list of editions with credit roles), which goes 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 concise, with one sentence followed by a list of return items. Minor redundancy ('Author profile + their audiobook works' then specifies fields) but still efficient and front-loaded.
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 lookup tool with one parameter and comprehensive annotations and output schema, the description covers the core purpose and return structure. It lacks details on pagination or filtering, but given the simplicity, it is largely 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?
The input schema provides thorough documentation for the single 'slug' parameter, including pattern, length constraints, description, and example. The tool description does not add any further parameter semantics, earning a baseline score of 3 due to 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 clearly states the tool returns an author profile and their audiobook works, specifying exact fields (biography, photo, country, audiobook editions) and credit roles. It effectively distinguishes from siblings like get_narrator and search_audiobooks.
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 fetching an author and their works, but does not provide explicit guidance on when to use this tool over other siblings like search_audiobooks or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_narratorGet Narrator ProfileARead-onlyIdempotentInspect
Narrator profile + audiobooks they have read. Czech audiobook listeners often choose by narrator (performance quality often matters more than the underlying text).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Narrator slug (lowercase, hyphenated). Example: "lukas-hlavica". Discoverable via search_audiobooks results or work detail offer.narrator references. |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description only needs to add context. It specifies that the tool returns both a profile and audiobooks, which is helpful 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?
Two sentences, no wasted words. The purpose is stated first, followed by relevant context. Every sentence earns its place.
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 has only one parameter, annotations, and an output schema, the description covers everything needed: what it returns, why it's useful, and the input format. It is complete for the complexity level.
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 schema already provides a detailed description, pattern, and example for the slug parameter. The description does not add any additional parameter semantics beyond what the schema offers.
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 returns a narrator profile and their audiobooks. It adds contextual insight about Czech listeners choosing by narrator, which differentiates it from sibling tools like get_author or get_audiobook.
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 focusing on narrator quality, but does not explicitly state when to use this tool versus alternatives like search_audiobooks or get_audiobook. No exclusions or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_partnersList Retail PartnersARead-onlyIdempotentInspect
List active retail partners with audiobook counts. Required for transparency / disclosure when an agent needs to explain HOW audioknihy.cz monetises recommendations (we are an affiliate aggregator, not a retailer).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it lists partners with audiobook counts and their purpose, but does not disclose additional behavioral traits like data freshness, rate limits, or recursion. With annotations covering safety, the additional context is helpful but minimal.
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, no filler. The first sentence states the action; the second provides necessary context. Every word earns its place.
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 an output schema, the description sufficiently covers the tool's purpose and motivation. It could be considered complete, though adding a note about the output format might further improve it, but not 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?
No parameters exist (0 params, 100% schema description coverage). Baseline for 0-parameter tools is 4. The description does not need to add parameter info, and it appropriately focuses on purpose.
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 'List active retail partners with audiobook counts' as a specific verb+resource action. It further explains the purpose for transparency/disclosure about monetisation, distinguishing it from all sibling tools which focus on content retrieval and offers.
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 identifies the context: 'when an agent needs to explain HOW audioknihy.cz monetises recommendations', and provides background about being an affiliate aggregator. It lacks explicit exclusions or alternatives, but the specific use case is clearly defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_audiobooksSearch AudiobooksARead-onlyIdempotentInspect
Full-text + fuzzy search across 12 367 Czech audiobooks (title, author, narrator). Use when an agent needs to resolve a free-form query into one or more audiobook records.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. 1–50, default 10. | |
| query | Yes | Free-form search query. Matches against audiobook title, author name, and narrator name. Czech diacritics are normalized (so "skola" finds "škola"). 1–200 characters. |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by noting Czech diacritics normalization and the fuzzy/full-text behavior. However, it doesn't specify result ordering or pagination beyond the limit parameter.
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 a single, well-structured sentence that leads with the core function, followed by a usage guideline. Every word contributes meaning; no repetition or 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 the tool's moderate complexity (2 parameters, output schema present), the description covers scope, diacritics normalization, and use case. Missing details like result ordering or handling of empty results, but output schema likely addresses return structure.
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?
Input schema covers 100% of parameters with descriptions. Description enhances these by stating search is 'full-text + fuzzy' and across a known set of 12,367 records, which contextualizes the query field's scope and behavior.
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 clearly states the tool performs full-text and fuzzy search across 12,367 Czech audiobooks by title, author, or narrator. It explicitly distinguishes from sibling tools like search_by_filters and get_audiobook by emphasizing free-form query resolution.
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 explicitly says 'Use when an agent needs to resolve a free-form query into one or more audiobook records.' This provides clear context for when to invoke. It does not explicitly list when not to use, but the sibling names (e.g., get_audiobook, search_by_filters) imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_by_filtersSearch by FiltersARead-onlyIdempotentInspect
Multi-facet search of audiobooks: combine genre, narrator, max price, year range. Use when an agent has structured constraints rather than a free-form query. V1 supports genre + narrator + price_max + year filters; partner filter coming in V2.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. 1–50, default 20. | |
| year_max | No | Latest publication year (inclusive). V1 accepts but skips this filter. | |
| year_min | No | Earliest publication year (inclusive). V1 accepts but skips this filter. | |
| genre_slug | No | Genre slug to anchor the search. Discoverable via browse_genres. Example: "detektivky". | |
| partner_slug | No | Reserved for V2 — partner-side filtering is not yet implemented and will throw if set. | |
| narrator_slug | No | Narrator slug to anchor the search. Example: "lukas-hlavica". | |
| price_max_czk | No | Maximum price in CZK applied as a post-filter on each result row. |
Output Schema
| Name | Required | Description |
|---|---|---|
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds extra transparency: year_min/year_max are accepted but skipped in V1, and partner_slug is not implemented and will throw. 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 two sentences, front-loads the purpose, and every sentence adds value (filters, usage context, versioning). 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 the tool has an output schema (not shown but present), the description doesn't need to explain return values. It covers V1/V2 status, filter semantics, and usage context. For a multi-facet search with versioning, it is 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 coverage is 100%, baseline 3. The description adds valuable context: year filters are 'accepted but skipped' in V1, partner_slug is 'not yet implemented and will throw', and price_max_czk is a 'post-filter'. This goes beyond the schema's own parameter 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 clearly states the tool performs 'Multi-facet search of audiobooks' with specific filters (genre, narrator, max price, year range), distinguishing it from free-text search via 'search_audiobooks' and browsing via 'browse_genres'.
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 says 'Use when an agent has structured constraints rather than a free-form query', and notes that 'partner_slug' is reserved for V2 and will throw if used, providing clear when-to-use and when-not-to-use guidance.
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!