Mediawork
Server Details
Search Mediawork's directory of post-production and distribution vendors, plus FAQ and plans.
- 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 10 of 10 tools scored.
Most tools target distinct actions, but 'fetch' overlaps with 'get_blog_post' and 'get_facility' since both retrieve full records. However, descriptions clarify that 'fetch' is generic for any search result, while specific getters are for blog posts and facilities.
Names follow verb_noun pattern mostly, but 'fetch' is a bare verb while others use 'get_', 'list_', 'search_'. Also 'get_plans' could be 'list_plans'. The inconsistency reduces predictability.
10 tools is appropriate for the server's purpose of providing access to vendor directory, blog, FAQ, and subscription plans. Not too many or too few.
The tool set covers all obvious operations for a public directory and content platform: search, list, and read for facilities, blog posts, FAQ, and plans. No significant gaps.
Available Tools
10 toolsfetchFetch a Mediawork recordAInspect
Retrieve the full contents of one record by the id returned from search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id from a search result |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It correctly indicates a read operation, but does not disclose potential errors, rate limits, or that the tool is read-only. The behavior is straightforward, so a basic level of transparency is achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that contains all necessary information with no redundant words. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description provides complete context: what the tool does, what input is needed, and where that input comes from. No additional information is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, and the description adds value by specifying that the id comes from a search result, clarifying the parameter's origin beyond the schema's 'An id from a search result'.
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 'retrieve', the resource 'full contents of one record', and the source of the identifier ('id returned from search'). It distinguishes from sibling 'get_*' tools by being generic, but does not explicitly note which tool to use for specific record types.
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 the tool should be used after a search to get full contents, providing a basic usage context. However, it does not mention when not to use it (e.g., for specific record types where siblings like get_blog_post exist) or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_blog_postRead a blog postAInspect
The full body of one published blog post, as markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | From a list_blog_posts result | |
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose behavioral traits like error handling or authentication, though the read nature is implicit.
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?
A single, front-loaded sentence with no extraneous 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?
For a simple read tool without output schema, the description is mostly adequate but could clarify return details and error states.
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 value by specifying slug source and locale options/default beyond the schema types.
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 the full body of one published blog post as markdown, differentiating it from list_blog_posts and other 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?
The description implies usage after list_blog_posts via the slug parameter note, but lacks explicit when-to-use guidance or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_facilityGet a vendor profileAInspect
The full public profile for one vendor: services offered, creatives on the team and what each of them does, production types, rooms and spaces, and addresses. Takes the companySlug and facilitySlug pair returned by search_facilities.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. | |
| companySlug | Yes | From a search_facilities result | |
| facilitySlug | Yes | From a search_facilities result |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lists what is returned but does not disclose whether it is read-only, idempotent, or requires authentication. Adequate for a simple get operation.
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 fluff, front-loaded with core purpose. 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?
Fairly complete for a get profile tool without output schema; describes key return fields. Could add more detail but sufficient given 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% and already describes each parameter. The description adds minimal value beyond restating that slugs come from `search_facilities`.
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 the full public profile for one vendor, listing specific content (services, creatives, etc.). It distinguishes itself from sibling tools like search_facilities, which returns slugs.
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 mentions that it takes the `companySlug` and `facilitySlug` pair returned by `search_facilities`, guiding the agent to use it after a search. Missing explicit when-not-to-use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_plansGet subscription plans and pricingAInspect
Mediawork's subscription plans: what each includes, and its prices. Prices are published in several currencies — pass currency to return just one.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. | |
| currency | No | ISO currency code, e.g. USD, GBP, EUR |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the data returned (plans, inclusions, prices) and currency filtering, but does not mention whether the data is cached, how recent it is, or any potential rate limits. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, each serving a clear purpose: stating what the tool provides and explaining currency filtering. No fluff or 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 only 2 parameters, no output schema, and no annotations, the description sufficiently explains the tool's purpose and key usage. It covers the main behavioral aspect (currency filtering) missing only minor details like the `locale` parameter being optional and defaulting to English.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of the `currency` parameter and that passing it returns just one currency. The `locale` parameter is not mentioned in the description, but its meaning is clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns subscription plans and their prices, with specific mention of multi-currency support. This is a specific verb+resource combination that distinguishes it from sibling tools like search or fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on using the optional `currency` parameter to filter results. While it doesn't explicitly list when not to use this tool, the purpose is obvious enough for an AI agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_blog_postsList blog postsAInspect
Published posts from the Mediawork blog, newest first. Use get_blog_post with a returned slug to read one in full.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions the ordering and that posts are published, but does not cover pagination, limits, or authentication requirements.
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 first sentence states purpose and order, the second provides actionable guidance.
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 list tool with no output schema or annotations, the description is mostly complete. It covers purpose, ordering, and next step. Lacks mention of pagination or result count.
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 no extra meaning beyond the locale parameter's language code list. Baseline score as schema does the heavy lifting.
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 published posts from the Mediawork blog, ordered newest first, and distinguishes itself from get_blog_post for reading individual posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using get_blog_post with a returned slug for full post reading, providing clear context on when to use this tool vs the sibling. Lacks explicit exclusions but the sibling list complements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_placesList directory placesAInspect
Cities, states and countries that have at least one vendor listed, with a count of how many. Use a place slug as the place argument to search_facilities.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that results filter to places with vendors and includes counts, but does not mention safety (read-only), rate limits, pagination, or empty results. This is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the first sentence stating the core purpose and the second providing a usage hint. No wasted words, and the key information is 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?
Given the tool's simplicity (1 optional parameter, no output schema), the description adequately covers what it returns (places with counts) and the relationship to search_facilities. However, the exact response structure (e.g., fields) is not hinted, which would enhance completeness.
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 schema description coverage is 100% for the locale parameter, which is fully documented in the schema. The description adds no additional meaning beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists cities, states, and countries with at least one vendor and includes a count. It distinguishes itself from siblings like search_facilities by specifying that its output (slugs) serves as input for that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to use the returned slug as the 'place' argument for search_facilities, providing a clear use case. However, it does not compare against other list tools (e.g., list_blog_posts) or state when not to use it, but the resource type is distinct.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_servicesList service categoriesAInspect
The service categories vendors on Mediawork offer, such as Editorial, Sound Post or Visual Effects. Each has a uuid — pass it as service to search_facilities to filter the directory to vendors offering that service. Call this first when a question is about a kind of work.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It reveals that the tool returns UUIDs for categories and that these are used as parameters for another tool. However, it does not mention side effects, permissions, or any other behavioral aspects beyond listing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no superfluous words. It front-loads the purpose and efficiently adds usage guidance and output implications.
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 output schema or annotations, the description sufficiently explains the tool's role, output structure (UUIDs), and integration with search_facilities. It lacks details on return fields besides UUID but is adequate 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?
Schema description coverage is 100% (one optional parameter 'locale' with description). The tool description adds no additional meaning beyond what is already in the schema, so baseline score of 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 it lists service categories offered by vendors, and distinguishes itself by explaining the UUID usage for filtering with search_facilities. It is specific and differentiates from sibling tools like search and list_blog_posts.
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 'Call this first when a question is about a kind of work,' providing a clear usage context. It also explains how to use the output (pass UUID to search_facilities) but does not mention when not to use or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch MediaworkAInspect
Search everything Mediawork publishes — vendor directory listings, FAQ entries and blog posts — and return matching records as {id, title, url}. Pass an id to fetch to read one in full. If your client supports them, the dedicated tools (search_facilities, search_faq, …) give richer, filterable results.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | What to search for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return format and content coverage. No annotations provided, so description carries burden. Lacks details on pagination or result limits, but for a simple search it is mostly transparent.
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 that front-load the purpose and then provide usage guidance. No unnecessary 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?
For a tool with one parameter and no output schema, the description covers purpose, return format, and relationship to sibling tools. Minimal 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 single 'query' parameter is described in schema as 'What to search for'. Description adds value by clarifying what content is searched and the structure of results, slightly enhancing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches across multiple content types (vendor directory, FAQ, blog) and returns records with id, title, url. It distinguishes from sibling search tools by mentioning dedicated 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?
Explicitly tells when to use this tool (broad search) vs fetch (to read full record) and vs dedicated search tools (for richer filtering). Provides clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_facilitiesSearch the vendor directoryAInspect
Search publicly listed post-production facilities, distribution vendors and creative companies. Filter by free text, by place slug (from list_places) and by service uuid (from list_services). To find vendors somewhere, prefer place; a query naming a place is treated as one anyway, and the response reports it as resolvedPlace. Results are paginated; when hasMore is true, call again with the returned nextOffset.
| Name | Required | Description | Default |
|---|---|---|---|
| place | No | A place slug from list_places | |
| query | No | Free text matched against facility and company names, or a place name | |
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. | |
| offset | No | Result offset for pagination | |
| service | No | A service uuid from list_services |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses read-only search nature, pagination with hasMore and nextOffset, and that query can resolve to a place. Lacks mention of auth or rate limits, but sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences cover purpose, filters, usage advice, and pagination. No filler; every sentence earns its place. Front-loaded with the main verb and resource.
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 search behavior, filter parameters, pagination, and response fields (resolvedPlace, hasMore, nextOffset). Missing output schema but description partially compensates. Adequate for agent use.
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 already describes all 5 parameters (100% coverage). Description adds context on how place and service values are sourced (from list_places/list_services) and the interaction between place and query.
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 verb 'search' and resource 'publicly listed post-production facilities, distribution vendors and creative companies'. Distinguishes from siblings like list_places and list_services which return filter options.
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 guidance on preferring 'place' over 'query' for location filtering and explains pagination behavior. Does not explicitly state when not to use this tool, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_faqSearch the Mediawork FAQAInspect
Mediawork's published FAQ, grouped by category. With a query, returns matching questions and their answers; without one, returns every question so you can pick which to search for.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Matched against both questions and answers | |
| locale | No | Two-letter language code (en, fr, es, pt, it, de, nl, pl, th, hi, ko, ja). Defaults to English. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by disclosing that without a query it returns every question, and that results are grouped by category. It doesn't cover pagination or response structure, but is sufficient for a simple search tool.
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, no redundancy. The purpose is front-loaded and every clause 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 output schema and simple inputs (2 params, none required), the description is complete enough. It explains all aspects of usage and behavior, though missing response format details.
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 already describes both parameters. The description adds that query is optional and matches against both questions and answers, and that locale defaults to English. This provides meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the Mediawork FAQ, grouping by category, and explains behavior with and without a query. It distinguishes itself from sibling tools like search and search_facilities by specifying the resource (FAQ).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use with a query to find specific Q&As, or without to browse all questions. It doesn't explicitly mention when not to use or compare to siblings, but the usage is well implied.
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!