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.3/5 across 9 of 9 tools scored. Lowest: 3.4/5.
Each tool has a clearly distinct purpose, with no overlap. Compare_all_offers and find_cheapest_offer are differentiated by scope, and the two search tools serve different query types.
All tool names use a consistent verb_noun pattern in lower_snake_case, with verbs like browse, compare, find, get, list, and search. Even search_by_filters follows the pattern.
With 9 tools, the set is well-scoped for a catalog server, covering discovery, details, price comparison, and partner info without unnecessary tools.
The tools cover major catalog needs—browsing, searching, details, price comparison, and partner listing. Minor gaps like missing direct purchase links or reviews are acceptable for a catalog query API.
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 indicate readOnly and idempotent. The description adds that it returns a fixed list of 35 genres with counts, providing behavior 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, front-loaded with the action and result, then usage context. Every word 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 no parameters, full annotation coverage, and an output schema (present but not shown), the description is complete for agent decision-making.
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, so the description doesn't need to add param info. Baseline 4 for zero parameters.
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 lists all 35 Czech audiobook genres with counts, and positions it as a discovery entry point, distinguishing it from sibling tools like 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?
It says 'Discovery entry point — agents enumerate genres before drilling into a specific one,' which implies when to use, but does not explicitly state when not to use or mention alternatives, though context is clear.
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 OffersBRead-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 indicate read‑only, non‑destructive, idempotent behavior. The description adds specific output fields and suggests post‑processing, but does not disclose additional traits like auth requirements or rate limits. 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?
Two sentences: first states purpose and output, second suggests usage. No filler, front‑loaded, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given good annotations, complete input schema, and existing output schema, the description covers the core functionality well. It mentions the scope ('every active retail partner') and output fields. Missing some usage guidance but otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema provides full descriptions for both parameters (work_slug and author_slug). The description adds no additional parameter context beyond what the schema already 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?
Description clearly states it provides a full price comparison table across all active retail partners for one audiobook, specifying output fields (price, format, timestamp). It implicitly differentiates from the sibling 'find_cheapest_offer' by emphasizing 'full comparison,' but does not explicitly name alternatives.
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. The description does not mention when not to use it or suggest better tools for specific needs (e.g., find_cheapest_offer for a single best price).
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 declare readOnlyHint, idempotentHint, and destructiveHint. The description adds that it checks active offers across all partners, but does not provide additional behavioral details such as rate limits or authentication needs.
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 two sentences: the first defines the core function, the second states the unique selling point. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and simple input schema, the description is mostly complete. It could mention that the tool returns a single cheapest offer, but the output schema likely covers the return format.
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 and examples for both parameters. The description does not add further parameter meaning beyond what the schema provides, 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 tool finds the lowest-price active offer for an audiobook across all affiliate partners. It distinguishes itself from siblings like compare_all_offers and search_audiobooks by emphasizing the USP as the only Czech site that compares prices.
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 seeking the cheapest offer but does not explicitly state when to use this tool versus alternatives like compare_all_offers. There is no guidance on prerequisites or exclusions.
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 and idempotentHint=true, so the description adds value by detailing the returned fields (including 'full table of active offers'). It does not contradict annotations and provides useful behavioral context about output content.
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, front-loaded with the main purpose, then lists the returned fields. No wasted words, ideal for quick parsing.
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 low complexity (two-param lookup with output schema), the description is complete. It covers what the tool returns, including offers. Annotations handle safety, output schema handles structure, so description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters (work_slug, author_slug). The description mentions 'by author + work slug' but adds no detail beyond the schema. Baseline 3 per rules 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 by author and work slug, listing specific fields (title, description, cover, runtime, ISBN, genres, narrator, publisher, offers). It distinguishes from siblings like search_audiobooks (searching) and compare_all_offers (comparing).
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 implicitly indicates use when you have author and work slugs, but does not explicitly state when not to use or mention alternatives like search_audiobooks for finding slugs. The clarity of purpose compensates slightly, but guidance is minimal.
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 indicate readOnlyHint, idempotentHint, and destructiveHint, so the description's value is in adding what data is returned (biography, photo, country, editions). This provides behavioral context beyond annotations 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 a single, well-structured sentence that front-loads the purpose and lists key outputs without unnecessary words. It efficiently conveys the tool's function.
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, the description need not detail return format but still lists key fields. It covers the essential context for an author profile tool, though it could mention potential data size (e.g., all editions).
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 details the slug parameter. The description adds value by noting slug is discoverable via 'search_audiobooks' and provides an example, which helps with parameter understanding beyond schema 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 tool retrieves an author profile along with their audiobook works, listing specific fields (biography, photo, country, editions). It distinguishes from siblings like 'get_audiobook' and 'get_narrator' by focusing on author info and associated editions.
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 context by stating the slug is discoverable via 'search_audiobooks', suggesting a workflow. However, it does not explicitly state when to use this tool over alternatives or 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_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 readOnly and idempotent. The description adds that it returns both profile and associated audiobooks, providing behavioral context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. First sentence states primary function, second adds relevant user 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 output schema availability, annotations, and simple single-parameter input, the description is complete. It covers the tool's purpose and return set adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers slug parameter fully, and description adds value by explaining how to discover the slug via search_audiobooks or work detail references.
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 retrieves a narrator profile and associated audiobooks, distinguishing 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 use for narrator-based browsing ('Czech audiobook listeners often choose by narrator') but does not explicitly state when to use this over search_audiobooks or other alternatives.
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 the specific output (audiobook counts) and the business reason, which goes beyond annotations. No contradictions; however, no further behavioral details are needed.
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, each serving a distinct purpose: first states action and output, second gives context. No filler; front-loaded with core 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 no parameters and an output schema that likely documents return structure, the description fully explains the tool's purpose and when to use it. 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?
The tool has zero parameters, and schema coverage is 100%. According to guidelines, baseline is 4 for 0 params. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'list', the resource 'active retail partners', and what is included (audiobook counts). It also provides business context, clearly distinguishing this tool from siblings like browse_genres 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?
The description explicitly states when to use: 'Required for transparency / disclosure when an agent needs to explain HOW audioknihy.cz monetises recommendations'. This provides a clear usage context and implies alternatives that do not provide this information.
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 indicate read-only, idempotent, and non-destructive behavior. The description adds value by disclosing fuzzy search capability and Czech diacritic normalization, which are behavioral traits not captured in annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence defining the tool's core functionality and corpus, and the second specifying the appropriate usage context. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (not shown) and comprehensive annotations, the description covers the essential aspects: search scope, fuzzy matching, diacritization normalization, and usage scenario. It is complete enough for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed descriptions for 'query' and 'limit'. The tool description adds the nuance of 'full-text + fuzzy' search, which is not explicitly stated in the schema descriptions, providing extra context for the agent.
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 full-text and fuzzy search across audiobooks by title, author, and narrator. It specifies the corpus size (12,367 Czech audiobooks) and differentiates from sibling tools like browse_genres and search_by_filters, which handle genre browsing and structured filtering respectively.
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 to use this tool when an agent needs to resolve a free-form query into audiobook records. While it does not list specific alternatives by name, the sibling tools context and the focus on free-form queries provide sufficient guidance for when to choose this tool over others.
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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds critical behavioral nuances: year_min and year_max are accepted but skipped in V1, and partner_slug throws if set. This goes beyond what annotations alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and each sentence adds distinct value. 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 output schema exists, the description does not need to explain return values. It covers purpose, usage guidelines, behavioral quirks (V1/V2 differences), and enough context for a 7-parameter tool. The mention of future V2 completion adds foresight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining that year filters are skipped and partner_slug is reserved for V2, which is not obvious from the schema. However, it does not elaborate on all parameters beyond what the schema already says.
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 the tool is for 'multi-facet search of audiobooks' and lists specific filters (genre, narrator, max price, year range). It clearly distinguishes itself from the sibling 'search_audiobooks' by contrasting structured constraints vs free-form query.
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 when an agent has structured constraints rather than a free-form query.' It also warns that partner_slug will throw in V1 and year filters are accepted but skipped, helping the agent avoid misuse.
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!