Search local businesses and book, order, quote or message any of them from one connection.
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.1/5 across 18 of 18 tools scored. Lowest: 3.1/5.
Each tool has a clearly distinct purpose. The search tools are separated by target (things vs businesses) and input style (filters vs natural language), and the quote workflow is broken into distinct steps. No two tools appear to do the same thing.
All tool names follow the same verb_noun pattern in lowercase snake_case (e.g., accept_quote, search_market, list_products). The naming is predictable and consistent throughout.
With 18 tools, the server is on the heavier side of the ideal range, but each tool addresses a specific marketplace function such as search, quotes, appointments, or reviews. The count is justified by the breadth of the domain.
The toolset covers the core marketplace workflows: searching, getting details, requesting/comparing/accepting quotes, booking appointments, and managing demand. Minor gaps exist (e.g., no explicit want deletion or appointment cancellation), but the generic take_action tool may cover many of these, and the primary workflows are complete.
accept_quoteAccept one of the quotesAInspectChoose a business's quote. This creates a real order at that business and declines the others. If that business protects payments, the reply carries a payment link where the money is held by Agoria until the customer confirms they got the work — hand that link to the customer.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The business whose quote to accept | |
| briefToken | Yes | From request_quotes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations (which only indicate non-read-only, non-idempotent behavior) by disclosing the irreversible side effect of creating a real order and declining all other quotes. It also reveals the payment protection mechanism, including that money is held by Agoria until customer confirmation and that a payment link is returned, providing crucial 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?
The description is compact, using only two sentences to convey the purpose, side effects, and payment flow without redundancy. It front-loads the core action and then adds the necessary 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?
The description covers the critical behavioral aspects: real order creation, decline of others, and the payment link procedure, which are essential for correct tool invocation. Minor gaps exist regarding error conditions or explicit prerequisites, but these are partially inferred from the schema (briefToken from request_quotes).
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 descriptions cover both parameters (briefToken and slug) with 100% coverage, so the description is not required to add parameter details. The description does not elaborate further on the parameters themselves, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Choose a business's quote') and its consequence ('creates a real order... declines the others'), which distinguishes it from sibling tools like compare_quotes and request_quotes. The verb and resource 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?
The description provides context that this tool is for accepting a quote after comparing options, and it gives an actionable follow-up instruction ('hand that link to the customer'). However, it does not explicitly state when not to use it or mention alternative tools, though the context strongly implies using it after request_quotes/compare_quotes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ask_marketSearch everything for sale, in one sentenceASame index as search_market, but takes a plain sentence — 'three bedroom house under 800k in Geelong', 'automatic ute under 80,000km' — and works out the filters itself. Use it when you have the user's own words; use search_market when you already know the exact filters.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The user's request, in their words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that it uses the same index as search_market and handles filter inference automatically, providing useful behavioral context beyond the annotations. It doesn't discuss limitations like potential ambiguity in parsing, but annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, with examples embedded, no wasted words. The purpose is front-loaded in the title and first sentence. The description is well-structured and easy to scan.
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 read-only tool with good annotations, the description fully covers purpose, usage, and relationship to alternatives. No output schema is needed for this simple search-style tool, and the description is complete enough for an agent to invoke it 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 'question' is described in the schema, and the description provides concrete examples of valid sentences. This adds practical meaning beyond the schema's generic 'user's request, in their words', helping the agent understand format and intent.
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 same index as search_market but accepts a plain sentence and auto-infers filters. This distinguishes it from the sibling tool search_market, which requires exact filters. The verb 'search' and resource 'everything for sale' are specific.
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: 'Use it when you have the user's own words; use search_market when you already know the exact filters.' This gives clear when-to-use and alternative. It also provides example sentences to illustrate expected input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
book_appointmentBook an appointment at a businessAInspectBook an appointment at any business by slug. Confirm the slot with check_availability first.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| slug | Yes | Business slug | |
| startsAt | Yes | ISO datetime from check_availability | |
| serviceId | Yes | ||
| customerName | Yes | ||
| customerContact | Yes | Phone or email |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the annotations. It doesn't mention what happens after booking, error handling, side effects, or confirmation behavior. The annotations already indicate it's a write operation, but the description adds no operational 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?
The description is two sentences, front-loaded with the purpose and a concise prerequisite. 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?
For a booking tool with 6 parameters and no output schema, the description is too brief. It omits key information about required parameters like serviceId, what constitutes a successful booking, and return value, leaving the agent to rely on schema and inference.
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 only 50%, and the description does not compensate for undocumented parameters. It repeats the 'slug' and 'startsAt from check_availability' hints from the schema but provides no meaning for serviceId, customerName, or note, which are left unexplained.
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 books an appointment at any business by slug, using a specific verb and resource. It distinguishes from siblings like check_availability by directly referencing it and focusing on the booking action.
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 explicit guidance to confirm the slot with check_availability first, which is clear usage context. However, it does not mention when not to use the tool or explicitly name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_availabilityCheck availability at a businessACheck open appointment slots for a service at a business on a date (YYYY-MM-DD).
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| slug | Yes | Business slug | |
| serviceId | Yes | Service id from get_business |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as readOnly, idempotent, and non-destructive. The description adds no extra behavioral context such as whether it returns a list, handles no-slot cases, or whether it reserves anything. It is consistent with annotations but does not enrich them.
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 redundant words. It conveys the action, resource, and key constraints efficiently.
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 and lack of an output schema, the description covers the main scenario well. However, it does not explicitly state the return format (list of slots vs. boolean), which would be valuable in the absence of an output schema. Still, it is mostly adequate for an availability check.
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 covers all three parameters with descriptions (slug, serviceId, date format). The description does not add further parameter-level detail beyond the schema, such as where serviceId comes from or date format specifics. Therefore, the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' with a clear resource 'open appointment slots' and specifies the parameters (service, business, date). It clearly distinguishes this from sibling tools like 'book_appointment' by indicating it is a pre-booking availability check.
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 one needs to view open slots for a service at a business on a date, but it does not explicitly state when to use this over alternatives like 'book_appointment' or 'get_business'. No exclusions or prerequisites are mentioned, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_quotesCompare the quotes on a briefASee every business's answer to a brief side by side: price, what it covers, lead time, rating, whether the payment would be protected, and which is cheapest or soonest.
| Name | Required | Description | Default |
|---|---|---|---|
| briefToken | Yes | From request_quotes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by disclosing the comparison fields, the side-by-side presentation, and the 'cheapest or soonest' computation. No contradiction with annotations, and the behavioral context is helpful for a read-only 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?
The description is a single, information-dense sentence that front-loads the core purpose and enumerates relevant details. No fluff; every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and strong annotations, the description fully captures the tool's behavior and output. It explains what is compared and highlights the cheapest/soonest, making it complete for an agent to invoke.
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 the single parameter briefToken with 'From request_quotes,' which provides sufficient meaning. The description doesn't add parameter details, but given 100% schema coverage, 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 the tool's function: 'See every business's answer to a brief side by side' and enumerates specific comparison dimensions (price, coverage, lead time, rating, payment protection) and highlights 'cheapest or soonest.' This distinguishes it from siblings like request_quotes and accept_quote.
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 a brief has quotes but does not explicitly state when to use this tool vs. alternatives. The parameter description 'From request_quotes' provides a prerequisite hint, but the tool description itself lacks explicit usage guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_wantTell the network what you're looking forAInspectSave a standing search on the customer's behalf. They get told when matching supply appears, AND — anonymously, without their contact details — sellers who could satisfy it can see it and offer. Use this when search_market found nothing good: it converts a dead end into a request the market can answer.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| cadence | No | How often to tell them about new matches | |
| contact | Yes | The customer's email — never shown to sellers | |
| request | Yes | What they want, in their words |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true and readOnly=false; the description adds valuable behavioral detail by disclosing that sellers can anonymously see the request and offer, and that the requester is notified when matches appear. It goes beyond the structured flags, though it does not mention how to cancel or update the standing search.
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 the core action in the first sentence, behavioral detail in the second, and a use case in the third. It is front-loaded, free of filler, and every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does not specify the return value or error cases, but it supplies enough context for an agent to decide when and how to invoke it: the trigger condition, what is saved, privacy behavior, and expected outcome. Minor gaps around optional parameters and duplicate handling are acceptable given its clarity.
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 75% (3 of 4 parameters described), so the schema already explains cadence, contact, and request. The description reinforces the privacy of the contact email and hints at the standing-search purpose, but it does not clarify the optional name field or add meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly says 'Save a standing search on the customer's behalf,' naming the action and resource. It also distinguishes itself from search_market by stating it converts a dead-end search into a market request, making its purpose clear relative to siblings.
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 an explicit trigger condition: 'Use this when search_market found nothing good.' It clarifies the follow-up behavior (notifications and anonymous seller offers) but does not contrast with other sibling tools like ask_market or open_demand, so exclusions are not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_businessGet a business profileAGet full details for a business by slug: description, contact, hours, services, FAQs, and the actions its agent supports.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Business slug from search_businesses |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds value by listing the exact content returned, which goes beyond the annotation hints. No contradictions; the read-only hint aligns perfectly with 'Get full details'.
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 action and resource, then uses a colon to list contents. Every word earns its place; 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?
This is a simple read-only tool with one parameter and no output schema. The description provides sufficient context: what it does, how to identify the business (slug), and what it returns (field list). Sibling tools are clearly distinguishable, and the annotations fill in the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single slug parameter well-described as 'Business slug from search_businesses'. The description only repeats 'by slug' and adds no additional semantic value 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 uses the specific verb 'Get' with the resource 'business profile' and identifies the key parameter 'by slug'. It enumerates the included fields (description, contact, hours, services, FAQs, actions), which clearly distinguishes it from sibling tools like search_businesses or get_reviews.
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 phrase 'full details' and 'by slug' imply this is the comprehensive profile tool, and the schema's reference to search_businesses provides context. However, it does not explicitly name alternative tools or exclusions, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_itemGet one item for saleAEverything about a single item: full facets, photos, where it is, who is selling it and how well-proven they are, a price guide computed from comparable items on the network, and the adjacent services a buyer usually needs next (finance, inspection, conveyancing, transport).
| Name | Required | Description | Default |
|---|---|---|---|
| ref | Yes | Item ref from search_market, e.g. 'acme-motors/offering:stk991' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds value by detailing exactly what data is returned (facets, photos, location, seller credibility, price guide, adjacent services), which is important given the absence of an output 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 a single, compact sentence that front-loads the purpose and then enumerates content. It is slightly dense as a run-on, but every phrase contributes necessary information about what the tool returns, so it remains 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?
With no output schema, the description must convey the complete return value, and it does so by listing all major categories of item information. For a tool with one simple parameter, this is comprehensive and leaves no significant gaps for the agent's 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?
The input schema has 100% coverage with a clear description and example for the single 'ref' parameter. The tool description does not add extra parameter-specific details beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves comprehensive details for a single item, enumerating categories like facets, photos, location, seller info, price guide, and adjacent services. This distinguishes it from siblings like search_market (which lists items) and price_guide (which only provides a price guide). The verb 'get' plus resource 'single item' is 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?
The description implies usage when you already have a specific item ref, and the schema notes the ref comes from search_market, which establishes a clear workflow. It does not explicitly name alternatives or exclusions, but the single-item scope and reference to search_market provide adequate context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_reviewsGet reviews & rating for a businessAGet a business's aggregate rating and reviews by slug. Optionally filter to a product/service id.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Business slug | |
| targetId | No | Product/service id; omit for whole business |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only, idempotent, non-destructive, and open-world. The description adds the key scoping detail (by slug, optionally filtered by targetId), but does not disclose behaviors such as pagination limits or response structure. This provides some additional context but not rich behavioral detail beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact two-sentence statement that front-loads the verb and object. There is no redundant wording; both sentences provide necessary scope 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-only tool with two well-documented parameters and clear annotations, the description adequately conveys the purpose and return content (aggregate rating and reviews). It lacks output schema but the description directly states what is returned, making it complete for this complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both slug and targetId, with 100% coverage. The description's phrase 'Optionally filter to a product/service id' mirrors the schema's targetId description without adding new semantic meaning, so the 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 uses a specific verb ('Get') and identifies the resource ('a business's aggregate rating and reviews by slug'), clearly distinguishing it from sibling tools like get_business or get_item. The optional targetId filter is also stated, confirming the tool's scope.
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 retrieving reviews/ratings but does not explicitly state when to prefer this tool over alternatives such as get_business or get_item. There are no exclusions or alternative tool mentions, so guidance is limited to an implied use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_market_filtersList the item kinds and filters availableAWhat can be searched and filtered on. Call this when you are unsure which kind or which filters keys search_market will accept.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Narrow to specific kinds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds context by explaining that the tool returns available search/filter options, but does not elaborate on response format or other behavioral nuances. Given the annotations, this 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?
The description is two sentences, front-loaded with the core purpose, and contains zero wasted words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter, no output schema, and clear annotations. The description adequately explains what it does and when to call it, making it complete for its scope.
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%, and the parameter 'kind' is already described as 'Narrow to specific kinds.' The description adds no extra meaning beyond the schema, so the baseline 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 uses a specific verb ('list') and resource ('item kinds and filters available'), and explicitly ties it to search_market's accepted 'kind' and 'filters' keys. This distinguishes it from sibling tools and clearly communicates its function.
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: 'Call this when you are unsure which kind or which filters keys search_market will accept.' This clearly states when to use the tool, though it does not mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_productsList products at a businessAList the products a business sells by slug — price/sale, availability/stock, brand, SKU/GTIN, variants, specs, dimensions.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Business slug | |
| query | No | Optional keyword filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing the safe read-only nature. The description adds output scope (price, stock, brand, SKU/GTIN, variants, etc.) but no additional behavioral caveats like pagination, authentication, 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?
The description is a single, front-loaded sentence that states the action and resource immediately, then appends a compact list of returned data types. Every word earns its place; 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 enumerating the main product fields returned, making the tool's behavior reasonably clear. It could mention pagination or ordering, but for a simple read-only list tool with only 2 parameters, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—both slug and query are described in the input schema. The description reiterates 'by slug' and lists output fields but adds no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'products a business sells by slug' and enumerates the product fields returned (price/sale, stock, brand, etc.), making it clearly distinct from sibling tools like get_business, get_item, or search_market.
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 (retrieving a business's product catalog by slug) but provides no explicit when-to-use/when-not-to-use guidance or references to alternative tools. It is clear enough for basic selection but lacks differentiation from related listing/search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_demandWhat buyers are looking for and nobody is supplyingBOpen standing requests from real buyers, anonymised. Useful for a business deciding what to stock or list, and for understanding where the network has no supply at all.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | ||
| where | No | ||
| unmetOnly | No | Only requests nothing currently matches |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds that the requests are 'from real buyers' and 'anonymised', which is useful context. However, it does not disclose output behavior, pagination, or any side effects beyond what annotations cover, so it stays at the baseline for a well-annotated 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?
The description is two sentences and front-loads the core function: 'Open standing requests from real buyers, anonymised.' The second sentence adds practical use cases. It is concise and well-structured without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three parameters and no output schema, the description should explain how to use the tool effectively. It only gives a general purpose and use case, but does not clarify what the parameters are for or what the response contains. This is inadequate for a tool with this complexity, especially with low schema coverage.
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 only 33% (only unmetOnly has a description). The tool description does not mention 'kind', 'where', or 'unmetOnly' at all, so it fails to compensate for the low schema coverage. Users are left guessing what these parameters mean, especially 'kind' and 'where'.
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: to 'Open standing requests from real buyers, anonymised.' This is a specific verb-resource pairing that distinguishes it from siblings like search_market or ask_market. The title adds further context. While it does not explicitly name alternatives, the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context: 'Useful for a business deciding what to stock or list, and for understanding where the network has no supply at all.' This implies when to use the tool but does not explicitly state when not to use it or mention alternatives (e.g., search_market). The guidance is present but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
price_guideWhat is a fair price?AA price distribution for comparable items on the network — asking prices, and where the network settled the sale, what buyers actually paid. Widens the comparison and says so when the exact match is too thin to be meaningful.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | Item kind, e.g. 'vehicle' or 'listing' | |
| where | No | Restrict to a locality first; dropped automatically if too thin | |
| attributes | Yes | What is being priced, e.g. {"make":"Toyota","model":"HiLux","year":2021} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, read-only, idempotent operation. The description adds behavioral context by stating it 'widens the comparison' and will explicitly note when the exact match is too thin, which informs the agent about output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the tool's purpose, and contains no redundant filler. It conveys both the core function and an important behavioral nuance in a compact, well-organized manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 params, nested object, no output schema), the description sufficiently communicates the nature of the returned data and the auto-widening behavior. It could be more explicit about the response format, but it covers the essential 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?
All parameters are described in the schema (100% coverage), so the baseline is 3. The description does not add specific parameter semantics beyond the schema; the 'widens the comparison' phrase relates to overall behavior rather than parameter usage.
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 defines the tool as a price distribution for comparable items, including both asking prices and actual sale prices. The phrase 'Widens the comparison and says so when the exact match is too thin' distinguishes it from listing-search siblings and clarifies its role as a fair-price lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for price discovery ('What is a fair price?') and mentions widening comparisons, but it does not explicitly state when to use this tool over alternatives like search_market or compare_quotes, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_quotesGet quotes from several businesses at onceAInspectDescribe a job once and send it to the businesses that can price it. Each one answers with a real number, what it covers, and how long the price stands. Returns a briefToken — poll compare_quotes with it to see the prices as they land, then accept_quote to choose one. Use this instead of calling request_quote at each business separately.
| Name | Required | Description | Default |
|---|---|---|---|
| slugs | No | Specific businesses to ask. Omit to have Agoria match them. | |
| title | No | Short label for the job | |
| budget | No | ||
| details | Yes | What the customer needs, in plain language. The more specific, the better the quotes. | |
| category | No | Business category to target, e.g. 'Plumber' | |
| location | No | City or suburb | |
| neededBy | No | When it's needed | |
| customerName | No | ||
| customerContact | Yes | Email or phone — businesses quote back to this |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: it sends the job to businesses (external effect), returns a briefToken for async polling, and indicates the nature of responses (real number, coverage, validity). It does not contradict annotations (readOnlyHint=false, openWorldHint=true are consistent). It lacks some details like what triggers a match or failure behavior, but adds meaningful context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and contains no filler. It efficiently packs in purpose, workflow, and an alternative, making every sentence valuable.
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?
Despite having 9 parameters and no output schema, the description explains the return value (briefToken), how to use it (poll compare_quotes, then accept_quote), and the goal (get multiple quotes). It doesn't detail every parameter, but the schema covers that. The workflow guidance makes the tool's context complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 78%, which is high, so the schema already documents most parameters. The description does not elaborate individual parameters further, but implies that 'details' and 'customerContact' are central (since they are required) and mentions 'send it to the businesses' which relates to 'slugs'. Since the schema carries most semantic weight, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Describe a job once and send it to the businesses that can price it.' It also distinguishes from a likely sibling by saying 'Use this instead of calling request_quote at each business separately,' making the scope (multiple businesses at once) explicit.
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 this tool versus an alternative ('Use this instead of calling request_quote at each business separately') and provides workflow context: poll compare_quotes with the returned briefToken and then accept_quote. This gives clear guidance on the tool's role in a larger process.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_placeTurn a place name into a point and a radiusAResolve a suburb, postcode or city to coordinates and the radius that name implies. Use it to check a place exists before passing it to search_market.
| Name | Required | Description | Default |
|---|---|---|---|
| where | Yes | e.g. 'Fitzroy', '3065', 'Geelong VIC' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds behavioral context by explaining it checks place existence and returns a point/radius, which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence states the core function, and the second provides usage context, making it concise 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 one-parameter tool with no output schema, the description fully explains what it returns (coordinates and radius), when to use it, and its workflow role. It is complete given the tool's simplicity.
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 provides 100% coverage for the only parameter 'where' with examples ('Fitzroy', '3065', 'Geelong VIC'), so the description adds no additional parameter semantics. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a suburb, postcode, or city to coordinates and a radius. It distinguishes itself from siblings by positioning as a pre-check for search_market, making its unique role explicit.
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 when-to-use guidance: 'Use it to check a place exists before passing it to search_market.' However, it does not state when not to use it or mention alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_businessesSearch the business directoryAFind businesses on Agoria by free-text query, category, and/or city. Returns each business's slug plus the actions its agent can take, so you can act on it directly from this same connection.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| query | No | e.g. 'emergency plumber', 'gluten free pizza' | |
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the return format (slug plus actions) but does not disclose other behavioral traits like pagination 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, front-loaded with the action and resource, no redundant phrasing. Every sentence earns its place, efficiently conveying purpose, parameters, and return 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, the description adequately explains what is returned (slug plus actions) and its purpose. It could mention pagination or result size limits, but overall it is sufficient for a read-only search tool with three optional parameters.
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 only 33% (only query has an example). The description adds meaning by clarifying that query, category, and city are filters that can be combined ('and/or'), and that query is free-text. However, it does not elaborate on valid category or city formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Find' and clearly states the resource 'businesses on Agoria' with search criteria (query, category, city). It also specifies the return value (slug and actions), distinguishing it from sibling tools like get_business or search_market.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding businesses to take action on, but does not explicitly state when to use this tool over alternatives such as search_market or get_business. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_marketSearch everything for saleASearch individual items across every business on the network — property listings, vehicles, courses, products, services, events, plans — with typed filters, a price range and a radius around a place. Prefer this over search_businesses whenever the user is looking for a THING rather than a company. Returns items with prices, locations, photo counts and the seller's verification status.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Item kinds to include, e.g. ['listing'], ['vehicle'], ['course']. Call list_market_filters to see what exists. | |
| page | No | ||
| sort | No | ||
| limit | No | ||
| query | No | Free text, e.g. 'renovated terrace', 'diesel ute' | |
| where | No | A suburb, postcode, city or 'lat,lng' | |
| filters | No | Typed facet filters keyed by field id, e.g. {"beds":{"min":3},"make":"toyota"} | |
| maxPrice | No | ||
| minPrice | No | ||
| radiusKm | No | Radius around `where`. Defaults to the size of the place named. | |
| verifiedOnly | No | Only items from businesses whose details have been checked against an outside register |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond those: it searches across the entire network, returns prices, locations, photo counts, and seller verification status, and supports typed filters and radius. 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?
The description is three sentences, each earning its place: the first states scope and item types, the second provides usage guidance, the third summarizes return fields. No filler, no redundancy, 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?
For a search tool with 11 parameters, nested objects, and no output schema, the description is quite complete: it explains what is searched, when to use it, and what the results contain. It does not mention pagination or sort options, but those are documented in the schema. Annotations cover non-determinism. It could go slightly deeper, but overall makes the tool safely invocable.
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 55%, so the description carries some responsibility. It references 'typed filters, a price range and a radius around a place', which maps to filters, minPrice/maxPrice, and radiusKm, and it lists example item kinds for the 'kind' parameter. However, it does not explain all parameters (e.g., page, sort, limit) and repeats some info already in the schema. Decent but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and clearly identifies the resource ('individual items across every business on the network'), enumerating concrete item types (property listings, vehicles, courses, etc.). It also explicitly distinguishes itself from the sibling tool 'search_businesses' by noting the preference for items over companies.
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 an explicit usage directive: 'Prefer this over search_businesses whenever the user is looking for a THING rather than a company.' This provides clear when-to-use guidance and names an alternative. It does not explicitly state when not to use it, but the preferential language effectively covers the main exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
take_actionTake an action at a businessAInspectPerform any non-booking action a business supports (request_quote, place_order, send_message, pay_invoice, sign_document, subscribe, register…). Get valid action ids and their fields from get_business. Pass the action's fields as a JSON object. If the result is 'action_required', hand the user the next.url (payment/signing link) or re-call with fields.confirmToken to confirm.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Business slug | |
| action | Yes | Action id, e.g. 'request_quote' | |
| fields | Yes | The action's input fields as a JSON object (include confirmToken to complete a gated action) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by explaining the result flow: if the result is 'action_required', the user is given a next.url or a re-call with fields.confirmToken. It also mentions the dependency on get_business for action ids and fields. This provides useful behavioral context that annotations (readOnlyHint=false, openWorldHint=true) do not cover, though it doesn't address potential side effects or errors.
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 four sentences, each packed with essential information: scope, source for ids/fields, how to pass fields, and handling the action_required result. There is no fluff or repetition, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's generic nature (any action) and lack of output schema, the description adequately covers the main workflow: obtaining ids/fields, passing them, and handling the typical 'action_required' result. It doesn't enumerate all possible actions or error cases, but the examples and conditional handling provide sufficient context for an agent to use the tool effectively.
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 parameters are already documented. The description adds value by explaining where to get valid action ids and fields (from get_business) and clarifies the use of confirmToken for gated actions. This supplements the schema's basic parameter descriptions without redundancy.
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: 'Perform any non-booking action a business supports' with a concrete verb and resource. It lists examples (request_quote, place_order, etc.) and differentiates from siblings by explicitly excluding booking actions, which are covered by sibling tools like book_appointment and check_availability.
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 when to use the tool: 'any non-booking action' and points to get_business for valid action ids. It also gives conditional guidance for handling 'action_required' results. However, it doesn't explicitly name alternatives like book_appointment for booking actions, though the sibling list implies this.
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!