Czech audiobook catalog MCP server. Search 12 000+ titles + compare prices across 5 partners.
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.3/5 across 13 of 13 tools scored.
Most tools have distinct purposes, but `compare_all_offers` and `find_cheapest_offer` overlap in pricing queries. Descriptions clarify the difference (full table vs. cheapest only), so ambiguity is low. Similarly, `search_audiobooks` and `search_by_filters` are distinct in input style.
All tools follow a consistent verb_noun pattern in snake_case (e.g., `browse_genres`, `get_audiobook`, `search_by_filters`). No mixing of conventions or irregular naming.
13 tools cover browsing, searching, detailed info, price comparison, analytics, and profiles. The number is well-balanced for the catalog's scope—neither sparse nor excessive.
The tool set covers key workflows: discovery, search, details, price comparison, trends, rankings, and partner info. Minor gaps like user reviews or advanced filtering (e.g., partner filter in V2) are acceptable for a focused catalog.
browse_genresBrowse GenresAList 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 | |||
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds concrete details (exactly 35 genres, includes counts), which provides behavioral context beyond the 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?
Two sentences, efficiently front-loading the action and resource in the first sentence, with usage guidance in the second. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, an output schema (true), and annotations covering safety, the description is complete. It specifies the exact count (35) and that counts are included, which is sufficient for a simple list 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?
With zero parameters, the baseline score is 4. The description does not need to add parameter info, and it appropriately focuses on the tool's output.
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 ('List') and resource ('all 35 Czech audiobook genres with audiobook counts'), clearly distinguishing it from sibling tools like search_audiobooks or get_audiobook_rankings.
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 states it as a 'discovery entry point' and advises agents to 'enumerate genres before drilling into a specific one,' providing clear usage context. However, it does not mention when not to use it or list alternatives.
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 OffersAFull 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". |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds value by specifying the return data (price, format, last-seen timestamp) and scope (one audiobook, all partners). 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?
Two concise sentences with front-loaded purpose. No unnecessary words. 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?
Given the presence of an output schema and annotations, the description adequately covers the tool's behavior. It could mention pagination or data structure, but the output schema likely handles 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 coverage is 100% with descriptions for both parameters. The description adds context beyond the schema by stating the tool returns data per retail partner, which is not evident from the parameter descriptions alone.
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 ('compare', 'returns') and resource ('full price comparison table across every active retail partner for one audiobook'). It distinguishes itself from sibling tools like 'find_cheapest_offer' which likely returns only the cheapest price.
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 obtaining a comprehensive price comparison per partner, but does not explicitly state when to use this tool versus alternatives like 'find_cheapest_offer' or 'get_price_index'. No when-not or alternative tool names are mentioned.
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 OfferALowest-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". |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds context that it returns the cheapest active offer across partners, which is a behavioral trait beyond 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?
Two sentences: first states purpose, second provides unique value. No redundant text. 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 tool with only two parameters and an output schema, the description covers purpose and unique value completely. It does not need to explain return values as the output schema exists.
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 parameter descriptions (slugs with patterns and examples). The tool description adds no additional parameter info beyond the schema, so baseline 3 applies.
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: finding the lowest-price active offer for an audiobook across all affiliate partners. It also highlights a unique selling point (only Czech site that compares across all major retail partners), distinguishing it from sibling tools like compare_all_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 implies usage for finding the cheapest offer, but does not explicitly state when to use it versus alternatives like compare_all_offers or get_price_trend. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audiobookGet Audiobook DetailAFull 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. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds return-fields context (e.g., 'full table of active offers'), which is useful 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?
Single sentence clearly front-loads the purpose and enumerates returned fields with minimal waste. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output_schema present and annotations covering safety, the description sufficiently describes the tool's function and output for a simple read endpoint. No significant 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% with detailed descriptions for both parameters. Description only reinforces 'author + work slug' without adding new semantics beyond what schema provides.
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 'Full audiobook detail by author + work slug' and lists specific fields (title, description, cover, etc.), distinguishing it from siblings like search_audiobooks or compare_all_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?
Implies usage when both author_slug and work_slug are known, but does not explicitly state when not to use or mention alternatives. Context from sibling names helps fill gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_audiobook_rankingsAudiobook RankingsACatalog-wide audiobook rankings — cheapest, best-rated (databazeknih.cz, attributed), biggest price drops, or currently at price floor. Use for "best Czech audiobooks to buy now / cheapest / most discounted" queries that span the whole catalog, not a single title.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of ranked audiobooks. 1–50, default 10. | |
| ranking | Yes | Which catalog ranking to return: "cheapest" (lowest live price among genuinely reviewed audiobooks), "best-rated" (highest databazeknih.cz third-party rating), "biggest-drops" (largest recent price drop), "price-floor" (currently at their lowest observed price). Mirrors the four /zebricky pages. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and destructiveHint, so the description does not need to reiterate safety. However, it adds valuable behavioral context: 'best-rated' uses third-party rating from databazeknih.cz and is attributed, and 'cheapest' filters to genuinely reviewed audiobooks. This enriches understanding 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?
Two sentences: the first quickly defines the tool's function; the second provides usage guidance. No wasted words, front-loaded with 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?
With output schema present and annotations covering safety, the description covers the ranking types, catalog scope, and use cases adequately. It fully informs an agent for selecting this 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 description adds nuance to the 'ranking' parameter by explaining what each option means (e.g., 'lowest live price among genuinely reviewed audiobooks' for cheapest). This adds value beyond the schema 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 returns catalog-wide audiobook rankings for specific metrics (cheapest, best-rated, biggest drops, price floor). It explicitly distinguishes from sibling tools like get_audiobook or search_audiobooks by specifying the scope and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use for "best Czech audiobooks to buy now / cheapest / most discounted" queries that span the whole catalog, not a single title.' This tells the agent when to use this tool and implies 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.
get_authorGet Author ProfileAAuthor 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". |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. Description adds return content details but no additional behavioral traits beyond what annotations imply. No 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?
Two sentences, front-loaded with purpose, no wasted words. 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?
Output schema exists, so return values are covered. Description lists key return elements. For a simple, single-parameter, safe tool, this is fully adequate.
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 parameter 'slug'. Description does not add new parameter info beyond the schema's own description, so baseline 3 applies.
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 verb 'get' and resource 'author profile', lists specific returned fields (biography, photo, country, editions). Differentiates from siblings like get_narrator by specifying author/co-author/editor role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies when to use (when slug from search_audiobooks is available). Does not explicitly state when not to use, but the context is clear from the description and sibling differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_narratorGet Narrator ProfileANarrator 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. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the output includes both profile and audiobooks, though it does not disclose any additional behavioral traits like pagination or ordering.
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, concise and front-loaded with purpose. Every sentence adds value: the first states what the tool does, the second provides helpful context 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 tool has a single parameter with full schema coverage, annotations covering safety, and an existing output schema (so return values need not be detailed), the description is complete enough for an agent to correctly select and invoke the tool. The additional context about Czech listeners adds relevance.
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 100% coverage for the 'slug' parameter with a clear example and discovery method. The description does not add any new parameter-level meaning, so it meets 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 clearly states it returns 'Narrator profile + audiobooks they have read', which is a specific verb-resource combination. This distinguishes it from sibling tools like get_author (author profile) and get_audiobook (individual book), making the 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 usage through the Czech listener context, suggesting it's useful when exploring narrators. However, it lacks explicit guidance on when to use this tool versus alternatives like get_audiobook or search tools, and does not state 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.
get_price_indexAudiobook Price IndexACross-store price index for the whole Czech audiobook market: median/avg lowest price, average savings from comparing, which store is cheapest most often, and per-genre price stats. Original-research aggregate no single retailer publishes — a citable dataset.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| value | Yes |
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 safety profile is clear. The description adds context about the data being original research and citable, but does not disclose additional behavioral traits like rate limits or authentication requirements. It 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 two sentences long, with no redundant language. The first sentence front-loads the core purpose and key metrics, and the second sentence adds unique value about the data's origin and citable nature. 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 no parameters and an output schema is present, the description fully covers the purpose, scope (Czech market), and what the tool returns. Sibling tools are listed, providing context for differentiation. No additional information is needed.
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 schema description coverage is 100%. The description adds value by enumerating the output metrics (median/avg price, savings, cheapest store, per-genre stats), which helps the agent understand the result without needing the output schema. With zero parameters, the baseline is 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 provides a cross-store price index for the Czech audiobook market, listing specific metrics like median/avg lowest price and per-genre stats. It distinguishes itself from sibling tools like find_cheapest_offer and get_price_trend by emphasizing it is an original-research aggregate not available from any single retailer.
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 market-level price analysis and mentions the data is citable, suggesting research use. However, it does not explicitly state when to use this tool over alternatives like find_cheapest_offer or get_price_trend, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_trendPrice TrendAPrice history of an audiobook's currently-displayed cheapest offer: window min/max, current price, % drop, whether it is at its floor, and the raw points. Use to answer "is this a good price right now / has it dropped?". Returns null when there is no recorded history in the window.
| Name | Required | Description | Default |
|---|---|---|---|
| work_slug | Yes | Work slug (lowercase, hyphenated). Example: "netopyr". | |
| author_slug | Yes | Author slug (lowercase, hyphenated). Example: "jo-nesbo". | |
| window_days | No | Look-back window in days. 1–365, default 90. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it returns null when no history exists and that it pertains to the 'currently-displayed cheapest offer', providing additional behavioral 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?
The description is two sentences long, front-loads the core purpose, and every word adds value. It is extremely concise with no wasted language.
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 annotations, full schema coverage, and an output schema (not shown but indicated), the description sufficiently covers purpose, usage, and a key behavioral detail. It is complete for the tool's complexity.
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?
All three parameters are fully described in the schema (100% coverage). The description does not add substantial extra meaning beyond what the schema provides, such as formatting or constraints, so it meets 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 clearly states the tool returns price history of an audiobook's cheapest offer, listing specific metrics (min/max, current price, % drop, floor status, raw points). It uses specific verbs and resource, and the context of sibling tools shows it is distinct from 'get_price_index' and 'find_cheapest_offer'.
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 states when to use the tool: 'Use to answer "is this a good price right now / has it dropped?"' and mentions a return value condition ('Returns null when there is no recorded history'). It does not explicitly exclude alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_publisherGet Publisher ProfileAPublisher (nakladatelství) profile + their audiobooks. Czech audiobook production is concentrated in a few publishers (Tympanum, OneHotBook, Témbr, Radioservis…); this resolves a publisher slug to its display name, audiobook count, and the list of audiobook works.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Publisher slug (lowercase, hyphenated). Example: "tympanum". Discoverable via the /nakladatelstvi index page. | |
| limit | No | Maximum number of works to return. 1–50, default 50. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds domain context (concentration of Czech publishers) and confirms the return type. 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?
Two concise sentences with no wasted words. The first sentence states the purpose, the second provides important domain context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, parameter count is low, and annotations are complete, the description is fully sufficient for an agent to understand and use 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 coverage is 100% and both parameters (slug, limit) are well-described in the schema. The description does not add significant additional meaning beyond repeating the schema details.
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 resolves a publisher slug to display name, audiobook count, and list of works. It distinguishes from sibling tools like get_author and get_narrator by focusing specifically on publishers.
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 context about Czech audiobook publishers and states that the tool resolves a publisher slug. It does not explicitly say when not to use it or compare to alternatives, but the connection to sibling tools is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_partnersList Retail PartnersAList 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 | |||
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context about monetization disclosure beyond what annotations convey, without 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, front-loaded with the action, and every word adds value. No redundancy 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 zero parameters, comprehensive annotations, and an existing output schema, the description fully covers the tool's purpose and usage context. Nothing 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?
With zero parameters, schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline 4 is appropriate for a parameterless 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 states a specific verb ('List') and resource ('active retail partners with audiobook counts'), making the tool's purpose clear. It is clearly distinct from sibling tools like search_audiobooks or get_audiobook, which focus on different operations.
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 context: 'Required for transparency / disclosure when an agent needs to explain HOW audioknihy.cz monetises recommendations'. While it lacks explicit when-not guidance, the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_audiobooksSearch AudiobooksAFull-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. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the search is 'full-text + fuzzy', which is helpful but not deeply behavioral. 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?
Two sentences, front-loaded with the core function, no fluff. Every word serves a 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 the presence of an output schema and well-documented parameters, the description provides sufficient context for a search tool. It could optionally mention result format or pagination, but is adequate.
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 thoroughly. The description adds no additional parameter meaning beyond stating the search fields (title, author, narrator).
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 'Full-text + fuzzy search' and specifies the corpus: '12 367 Czech audiobooks (title, author, narrator)'. This clearly distinguishes it from sibling tools like browse_genres or search_by_filters, which have different scopes.
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?
Provides clear guidance: 'Use when an agent needs to resolve a free-form query into one or more audiobook records.' This implies when not to use (e.g., structured filters), and sibling tools are listed for context, though no explicit alternative is named.
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 FiltersAMulti-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. |
| Name | Required | Description |
|---|---|---|
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and idempotentHint=true, and description adds value by noting that year filters are skipped in V1 and partner filter throws, which is beyond what annotations provide.
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 short sentences, front-loaded with purpose and usage, no fluff. Every sentence provides essential 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?
Covers core filters, usage context, and version limitations. Output schema exists, so return values need not be described. Minor gap: year filter caveat not in description but schema fills 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 coverage is 100%, so baseline is 3. Description mentions filters generically (genre, narrator, max price, year range) but does not add substantial meaning beyond schema 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?
Description clearly states 'Multi-facet search of audiobooks' with specific verbs and resources, and distinguishes from sibling 'search_audiobooks' by contrasting structured constraints vs free-form queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when an agent has structured constraints rather than a free-form query,' providing clear context. Also mentions version limitations (V1/V2) for partner filter, but does not explicitly list all exclusions.
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!
