Search Mediawork's directory of post-production and distribution vendors, plus FAQ and plans.
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.2/5 across 10 of 10 tools scored.
Each tool targets a distinct resource or action: fetch is for generic IDs from search, while get_blog_post and get_facility use slugs from their specific list tools. search and the dedicated search_facilities/search_faq are clearly scoped by domain, and list_places/list_services are separate reference lookups. No two tools appear to do the same thing.
All tool names use a verb-first pattern with consistent conventions: get_ for single resources, list_ for collections, search_ for filtered discovery, and fetch as a generic retrieve. Singular nouns for get_* and plural for list_* reinforce the pattern, making the name predictable and readable.
With 10 tools, the set is well-scoped for a media directory API covering facilities, blog, FAQ, references, and plans. Each tool earns its place without redundancy or unnecessary breadth, fitting comfortably within the ideal 3-15 range.
The surface covers the full read-only lifecycle of its domain: search_facilities for listing with filters, get_facility for detail, list_blog_posts/get_blog_post for blog, search_faq for FAQ, list_places/list_services for reference data, and get_plans for subscriptions. The generic search/fetch pair ties everything together with no identifiable gaps.
fetchFetch a Mediawork recordAInspectRetrieve the full contents of one record by the id returned from search.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | An id from a search result |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining the tool's behavior. 'Retrieve' and 'full contents' convey that it is a non-destructive read of a single record, but it does not disclose response format, error behavior, or any access requirements. Adequate for a simple fetch, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every element serves to clarify the tool's purpose and key prerequisite.
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 (one parameter, no output schema), the description sufficiently explains what the tool does and how to invoke it. It could mention what the response looks like, but 'full contents' provides a reasonable high-level expectation.
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 already provides 100% coverage for the only parameter 'id', describing it as 'An id from a search result'. The description reinforces this connection but adds no additional semantics beyond what the schema states.
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 action ('Retrieve'), the resource ('one record'), and the source of the identifier ('id returned from search'). It distinguishes itself from list/search siblings by specifying that it returns full contents of a single record.
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 provides clear context for when to use this tool: after a search, when you have a specific id and want complete record contents. It does not explicitly contrast with sibling get_* tools, but the 'id from search' instruction implies the intended workflow.
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 postAInspectThe 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose that only published posts are returned and that the output is markdown, which is useful. However, it omits any behavior around missing slugs, locale handling, or whether other metadata is included. It is minimally transparent but not rich.
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, brief phrase that gets straight to the point with no wasted words. It is front-loaded and appropriately sized for a simple read operation, though it is a fragment and could be a full sentence.
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 low-complexity tool with full schema coverage and no output schema, the description explains the core return value ('full body... as markdown') and the scope ('one published'). It does not discuss errors or edge cases, but the tool is simple enough that this is adequate. Slightly more detail on error behavior would be needed for a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds nothing about the parameters beyond what the schema already provides; it does not explain the slug semantics or locale defaults, but the schema already does. The description earns no extra credit.
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 title 'Read a blog post' provides the verb, and the description specifies the exact resource: 'the full body of one published blog post, as markdown.' It clearly differentiates from siblings like list_blog_posts by indicating a single post, and from generic fetch by specifying the format and published status.
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?
Usage is implied: if you need one post's content, use this tool. The slug parameter description in the schema ('From a list_blog_posts result') hints at a two-step flow, but the description itself does not explicitly state when to use this vs list_blog_posts or search, nor does it mention exclusions.
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 profileAInspectThe 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the profile is 'public' (suggesting no auth) and lists what content is included, but does not mention error behavior, locale effects, or response format details. This is adequate but not rich.
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, begins with the core function, and includes a targeted usage note. There is no redundancy or filler; every word contributes 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?
The description explains what the tool returns (content areas) and where the parameters come from, which is sufficient for a simple three-parameter read tool without an output schema. It lacks error handling notes but is otherwise 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?
Schema description coverage is 100%; the description adds no extra meaning beyond what the schema already states. The phrase 'pair returned by search_facilities' lightly reinforces the parameter descriptions but does not provide new syntax or constraints.
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 public profile for a single vendor, enumerating the specific content areas (services, creatives, production types, rooms, addresses). This distinguishes it from sibling search/list tools by focusing on a single facility's detailed profile.
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 that the companySlug and facilitySlug pair should come from search_facilities, giving concrete usage context. However, it does not explicitly contrast with alternatives like `fetch` or `search_facilities`, though the pair-reference implies a follow-up flow.
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 pricingAInspectMediawork'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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states that the tool returns plan details and prices, and that passing currency returns just one currency. It does not explicitly confirm read-only behavior or side effects, but for a get operation this is somewhat implied. It could add more context about response behavior or defaults, but it is adequately transparent for a simple read.
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, two sentences long, and front-loaded with the main purpose. Every sentence provides useful information without fluff 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?
For a simple read-only tool with full schema coverage and no output schema, the description is largely complete. It explains the return content (plans, inclusions, prices) and the currency filtering behavior. It does not mention the locale parameter, but the schema covers that. The overall complexity is low, so the 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?
The input schema already fully describes both parameters (locale and currency) with 100% coverage, giving a baseline of 3. The description adds meaningful behavior: passing currency filters the output to a single currency, which is not mentioned in the schema. This extra semantic clarity justifies a score above baseline.
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 subscription plans and pricing, specifying the resource (subscription plans) and the action (get). It is easily distinguished from sibling tools like list_services or get_facility, which focus on other domains.
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 gives context that this is for Mediawork's subscription plans and mentions the currency parameter for filtering, but it does not explicitly state when to use this tool over alternatives or provide exclusion criteria. The usage is implied rather than explicitly guided.
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 postsAInspectPublished 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the disclosure burden. It reveals that the list only contains published posts, sorts newest first, and implies returned entries carry slugs rather than full content, which is useful behavioral context.
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 redundant wording; front-loads the purpose and immediately follows with cross-reference to the companion tool.
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 one optional parameter and no output schema, the description gives the essential behavior, ordering, and a pointer to the full-content tool. It is sufficient for an agent to select and invoke 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 only parameter, locale, is fully described in the schema (100% coverage), so the description does not need to repeat it. It adds no additional parameter meaning, hence a baseline score of 3.
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 the tool lists published posts from the Mediawork blog, newest first, with a clear verb and resource. It distinguishes itself from sibling get_blog_post by implying it returns available slugs for full reads.
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 instructs to use get_blog_post with a returned slug to read a post in full, providing a clear follow-up action and distinguishing when to use each tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_placesList directory placesAInspectCities, 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. |
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 discloses the key filter (places with at least one vendor) and the inclusion of counts, which is useful behavioral context beyond the 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?
The description is two sentences with no filler. The first sentence defines the output, and the second provides a practical usage pointer. Both sentences are essential 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 one optional parameter and no output schema, the description adequately explains what is returned and how to use the result. It could mention locale effects, but those are already covered in the schema.
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 fully documents the single optional `locale` parameter, including allowed values and default. The description adds no parameter-specific information, so it remains at the schema-coverage baseline.
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 identifies the tool as listing cities, states, and countries that have at least one vendor, with vendor counts. This distinguishes it from sibling search tools by defining the specific resource and output.
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 tells the user to use the resulting place slug as the `place` argument to search_facilities, which implies when this tool is appropriate. However, it does not explicitly contrast it with other list tools or 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.
list_servicesList service categoriesAInspectThe 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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the key integration behavior (pass uuid to search_facilities) and implies a read-only list operation. It does not explicitly state return format, but for a simple list this is sufficient and not misleading.
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 key purpose, followed by a usage tip. Every sentence earns its place, with 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 it is a simple list with one optional parameter and no output schema, the description adequately explains the return concept (each has a uuid) and the primary use case. No major gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the locale parameter, but the schema already documents it fully. With 100% schema coverage, baseline is 3, and the description adds no extra parameter 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 it lists service categories (Editorial, Sound Post, Visual Effects) and differentiates from search_facilities by explaining how the uuid feeds into it. The verb 'list' and resource 'service categories' are specific and 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?
Explicitly advises calling this first when a question is about a kind of work, and explains how to pass the service uuid to search_facilities, giving a concrete alternative/next step. This is strong when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchSearch MediaworkAInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the return format ({id, title, url}) and the relationship to `fetch`, which is valuable behavioral context. However, it does not mention potential pagination, rate limits, or indexing freshness, which would make it more 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 sentences, front-loaded with the core function and return shape, then providing workflow guidance. Every sentence earns its place with no filler.
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 single-parameter search tool with no output schema, the description explains what is searched, the return format, how to retrieve full records, and when to prefer other tools. This covers all essential aspects needed for correct invocation and follow-up.
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 already documents the only parameter (`query`) 100%, so the baseline is 3. The description adds meaning by enumerating what the query can match (directory listings, FAQ, blog posts), giving the agent a better sense of the search scope beyond 'What to search for'.
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 across all content types (vendor directory listings, FAQ entries, blog posts) and returns a uniform record structure. It distinguishes itself from sibling tools by explicitly positioning dedicated search tools as richer alternatives, making its scope clear.
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 provides explicit guidance on when to use this tool vs. alternatives: use dedicated tools when available for richer results, and use `fetch` to read a full record by id. This exceeds basic context by naming the alternative tools and the workflow.
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 directoryAInspectSearch 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination behavior, the `resolvedPlace` response field, and the fact that a `query` naming a place is treated as a place. It could mention rate limits or auth, but for a simple search it is adequate.
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, front-loaded with purpose, each sentence provides a distinct piece of operational guidance. No filler 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 no output schema, the description compensates by mentioning key return fields (`resolvedPlace`, `hasMore`, `nextOffset`). It covers filtering and pagination, leaving little ambiguity for usage.
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 already documents all 5 parameters with descriptions, so baseline is 3. The description adds relational nuance between `place` and `query`, and explains pagination parameters in context. This extra semantic guidance raises it above baseline.
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 function: searching publicly listed post-production facilities, distribution vendors, and creative companies. The verb 'search' plus the resource scope distinguishes it from generic search and other sibling tools like get_facility or list_services.
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 explicit guidance on filtering mechanisms (free text, place slug, service UUID) and advises to prefer `place` over `query` for location-based searches. Also explains pagination with `hasMore` and `nextOffset`. It doesn't explicitly compare to sibling search tools but gives enough contextual cues.
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 FAQAInspectMediawork'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. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that results are grouped by category, that queries match both questions and answers, and that omitting the query returns all questions. This adds value beyond the input schema, though it does not detail matching logic or response structure.
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 purpose, and every phrase adds value: 'grouped by category', the query behavior, and the no-query fallback. 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 simple FAQ search tool with two optional parameters and no output schema, the description covers the main use cases (with and without query) and clarifies the resource scope. It could be slightly more complete by noting that it should be used instead of generic search for FAQ questions, but current description 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 coverage is 100% (both 'query' and 'locale' have descriptions), so baseline is 3. The description adds marginal context by explaining the no-query behavior for 'query', but does not provide additional meaning for 'locale' beyond the schema's language code and default.
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 Mediawork's FAQ, with specific behavior for queries (returns matching questions and answers) and without (returns all questions). This distinguishes it from generic sibling tools like 'search' by naming the specific resource (FAQ) and adding contextual detail about grouping.
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 conveys clear context: it is for searching Mediawork's published FAQ, and it explicitly describes the no-query behavior, which helps the agent decide when to use it (e.g., to browse all questions). However, it does not explicitly exclude alternatives like the generic 'search' tool or 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.
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!
Sign in to create a connector for this server.