Search Hungarian wedding vendors and venues, check a date, estimate a budget, get the checklist.
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.5/5 across 7 of 8 tools scored. Lowest: 3.8/5.
There is notable overlap between 'search' and 'search_vendors', and between 'fetch' and 'get_vendor'. While the descriptions attempt to differentiate them, an agent could easily select the wrong tool initially.
Naming is mostly readable with underscore separators, but patterns vary: verb_noun ('check_availability', 'estimate_budget', 'list_categories_and_regions'), bare verbs ('fetch', 'search'), and noun-only ('wedding_checklist'). Not chaotic, but not fully consistent.
Eight tools is well-scoped for a wedding vendor directory with planning support. Each tool has a clear role and the count is appropriate for the domain.
The set covers the core workflow of searching, viewing details, checking availability, estimating budget, and accessing a wedding checklist. Minor redundancy (fetch vs get_vendor) and lack of any comparison or booking tools are small gaps, but most user needs are addressed.
check_availabilityCheck a vendor's availability on a dateAWhether one vendor (by id from search_vendors) is free, tentatively held, or booked on a given date — ONLY for vendors who chose to publish their availability. Most have not; then the answer is "unknown", which means "ask them", never "busy". Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | YYYY-MM-DD | |
| locale | No | Language for labels and copy. Use "hu" when the user writes Hungarian. | en |
| vendor_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds important non-obvious semantics: availability statuses (free, tentatively held, booked, unknown), the publishing limitation, and the critical rule that unknown means ask, not busy. No contradiction with the annotations is present.
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 short sentences with the core behavior front-loaded. Every clause earns its place: the status query, the publication caveat, the unknown interpretation, and the read-only note. There is no wasted or irrelevant text.
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 3 parameters, no output schema, and annotations covering safety, the description is sufficiently complete: it names the possible statuses, explains the unknown case, and provides the prerequisite relationship to search_vendors. A response-shape enumeration is not necessary because the meaningful result vocabulary is already disclosed.
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 adds meaning to vendor_id by tying it to 'id from search_vendors,' which is not in the schema's raw type/format fields. It also reinforces that date is the target date. Locale is the only parameter not mentioned in prose, but the schema already documents its default and language behavior, so the description does not need to repeat it.
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 names the exact query: 'Whether one vendor ... is free, tentatively held, or booked on a given date.' It also distinguishes the tool from sibling tools by specifying that the vendor id comes from search_vendors, making the resource and scope 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 gives clear context: the tool is only meaningful for vendors who publish availability, and it explains how to interpret "unknown" (ask them, never busy). It implicitly tells the caller to use it after search_vendors, but it does not explicitly name alternative tools or say when not to use it beyond the publishing caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_budgetEstimate a Hungarian wedding budgetAA dated, sourced cost estimate for a wedding in Hungary (benchmark set hu-2026.1, as of 2026-08) from guest count, price tier, region and ceremony type — the same engine as latido.wedding/kalkulator. Returns a low/anchor/high total in HUF, the per-line breakdown, the marginal cost of one more guest, and the expected cash-gift income (Hungarian custom: gifts are cash). Use for "mennyibe kerül egy esküvő" questions. Estimates, not quotes; prices are in HUF.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Wedding date, if known — a weekday civil ceremony at the registry office is free. | |
| tier | No | low = budget, mid = typical, high = premium. | mid |
| guests | Yes | Number of guests (adults + children). | |
| locale | No | Language for labels and copy. Use "hu" when the user writes Hungarian. | en |
| region | No | budapest | videk (countryside) | unknown. | unknown |
| ceremony | No | civil | church (civil AND church) | abroad | undecided. | undecided |
| contingency_pct | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already marking this as read-only and idempotent, the description adds valuable context: the estimate is 'estimated, not quotes,' it relies on a specific benchmark ('set hu-2026.1, as of 2026-08'), it includes the custom that cash is expected gifts in Hungary, and it returns a low/anchor/high, marginal cost, and income. This transparency is 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?
Every sentence in the description earns its place, and the most central information (what inputs are, what is returned) is front-loaded. It is compact yet information-dense, avoiding 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?
Although there is no output schema, the description thoroughly explains the return payload: total in HUF, per-line breakdown, marginal cost, expected cash-gift income. It also covers the Hungarian customs, benchmark currency, and the 'estimate not quote' limitation, making the tool self-contained.
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 86%, with detailed descriptions for almost every parameter. The description adds only contextual flavor (guest count, price tier, region, ceremony type, 'same engine as...') without a new semantic insight beyond what the schema already provides. This maintains the baseline for schema-heavy parameter support.
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 opens with a specific verb and resource: 'a dated, sourced cost estimate for a wedding in Hungary,' then clarifies the benchmark set and exact inputs (guest count, tier, region, ceremony type). It differentiates itself from the sibling tools by emphasizing cost estimation and return values, while even naming its underlying engine latido.wedding/kalkulator.
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 trigger: 'Use for "mennyibe kerül egy esküvő" questions.' It does not mention alternative tools or exclusive when-not-to-use scenarios, but the sibling tools are distinct enough (search, availability, checklist) that this is clear context rather than a confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fetchFetch a Latido result (deep research)AFull public storefront document for one result id from search. For a structured answer prefer get_vendor.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A result id from search. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description only adds that it returns a document, which is minimal extra behavioral insight 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 extremely concise, consisting of two sentences: the first states the main function, and the second gives a clear alternative. It is well-structured 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 fetch operation, the description provides enough context: what the tool does and a pointer to an alternative for structured data. It lacks explicit details about the document format, but given the absence of an output schema, this is acceptable.
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 a description for the 'id' parameter ('A result id from search'), and the tool description repeats this information without adding new meaning. Per rubric, baseline is 3 due to 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 that the tool fetches a full public storefront document for a given result id from search, and distinguishes it from get_vendor for structured answers. However, 'full public storefront document' is slightly vague.
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 a clear usage guideline by recommending get_vendor for structured answers, implying this tool is for unstructured or full document retrieval. It also ties usage to search results via the id parameter description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_vendorGet a vendor's public profileAFull public storefront of one vendor or venue from Latido by id (from search_vendors): categories, where they work, price band, capacity, packages with prices, FAQ, links, published reviews and their own description. Use it after a search to answer detailed questions or to compare shortlisted vendors. Read-only; never returns contact details beyond the public links — the storefront URL is where a couple gets in touch.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for labels and copy. Use "hu" when the user writes Hungarian. | en |
| vendor_id | Yes | The vendor id returned by search_vendors. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds valuable behavioral context: 'never returns contact details beyond the public links' and explains the storefront URL is the contact path, a privacy boundary not visible in 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?
Three tightly packed sentences: the first lists the contents, the second gives usage guidance, and the third states a key limitation. No filler or redundant content.
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 get-by-id profile tool with only two parameters and no output schema, the description fully covers what is returned, when to use it, and a critical limitation. It is complete enough for an agent to invoke and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline 3 credit. The description adds slight extra meaning by clarifying the vendor_id can refer to 'one vendor or venue' and reinforcing that the id comes from search_vendors, though this largely duplicates the schema's own description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the full public storefront of one vendor or venue by id, listing specific content fields like categories, price band, capacity, packages, FAQ, and reviews. It also distinguishes itself from search_vendors by explicitly sourcing the id from that search tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It says to 'Use it after a search to answer detailed questions or to compare shortlisted vendors,' giving explicit when-to-use context. It also warns that contact details are never returned and points to the storefront URL for contact, but it does not explicitly name other sibling tools as alternatives for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_categories_and_regionsList vendor categories, styles and regionsAThe vocabulary search_vendors understands: the 11 top-level groups with their subcategory keys and labels, the wedding-style keys, and the Hungarian counties with their region ids. Call it once when you need to map what a user said ("vőfély", "pajta", "Balaton") onto a group/category/style value — do not guess keys.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | Language for labels and copy. Use "hu" when the user writes Hungarian. | en |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent, and closed-world. The description adds value by explaining the vocabulary scope and the need to call it once, which is complementary. It doesn't contradict annotations and adds behavioral context about its purpose in the search pipeline.
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: the first defines the tool's output comprehensively, the second gives usage guidance. No wasted words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter, no output schema, and rich annotations, the description sufficiently explains the tool's purpose and usage. It doesn't detail the exact structure of the output (e.g., fields like `group` or `category`), but since no output schema is provided, a bit more about return format could be helpful, but it's not critical for a vocabulary list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `locale` is fully described in the schema (enum, default, description). The description reinforces that Hungarian should be used when the user writes Hungarian, which adds a usage nuance not fully captured in the schema's generic description, but the schema already handles most of it.
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 vendor categories, styles, and regions as the vocabulary for search_vendors. It specifies the content (11 top-level groups, subcategory keys/labels, wedding-style keys, Hungarian counties with region ids), which distinguishes it from sibling tools like search_vendors and get_vendor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to call it once when mapping user speech onto keys and advises against guessing. It implies using it before search_vendors, and the alternative of guessing is discouraged, which is clear guidance 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.
searchSearch Latido (deep research)AFree-text search over Latido's public Hungarian wedding vendor directory. Returns result ids for fetch. For filtered search (category, place, budget, capacity, date) prefer search_vendors.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Free-text query — vendor name, category or place. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds the output semantics ('Returns result ids for fetch') and notes the directory is 'public', which offers useful context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core purpose, then provide the alternative. No filler or redundant wording; 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?
For a simple single-parameter search tool with thorough annotations and an output hint, the description is complete. It explains what the tool does, what it returns, and when to use a different tool. No additional context seems necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a well-described 'query' parameter (free-text query — vendor name, category or place). The description does not add meaningful additional parameter detail beyond restating that it's free-text search. This meets the baseline for full-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 performs a free-text search over a specific directory ('Latido's public Hungarian wedding vendor directory'), distinguishes it from the filtered search alternative ('search_vendors'), and specifies the output ('Returns result ids for fetch'). This is a specific verb+resource with clear 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?
Explicitly says 'For filtered search (category, place, budget, capacity, date) prefer search_vendors', providing a direct when-not-to-use instruction and naming the alternative. This makes usage guidelines crystal clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_vendorsSearch wedding vendors & venuesASearch Latido's public directory of Hungarian wedding vendors and venues (photographers, venues, DJs, florists, caterers, planners…). Use it whenever someone is looking for a supplier for a wedding in Hungary. Filter by category or top-level group, a place name (city, county or "Balaton"), maximum price in HUF, minimum seated capacity, a wedding style, or a date the vendor must be free on. Returns 10 results per page in the directory's own ranking; vendors who have not published a price/capacity/availability are kept (unknown is not a "no"). Each result has a public storefront URL — link to it. Does NOT search vendors who have not published a profile.
| Name | Required | Description | Default |
|---|---|---|---|
| area | No | Place name in Hungary — city, county or region ("Budapest", "Somogy", "Siófok"). Matches vendors based there OR travelling vendors who serve it. | |
| page | No | 1-based page, 10 results per page. | |
| group | No | Top-level category: venues, photo_video, music_entertainment, … Use this for "any venue" / "a photographer". | |
| query | No | Free-text match on the vendor name or tagline, e.g. "Makay" or "vintage". Leave empty to browse. | |
| style | No | Wedding style the vendor works in (boho, rustic, classic, modern, glamour, folk_hu…). One style per search. | |
| locale | No | Language for labels and copy. Use "hu" when the user writes Hungarian. | en |
| category | No | A specific subcategory, e.g. farm_barn, photographers, dj, vofely, cake. Narrower than `group`. | |
| available_on | No | Wedding date (YYYY-MM-DD). Drops vendors KNOWN to be booked that day; vendors who do not publish availability are kept. | |
| min_capacity | No | Minimum seated guests (venues). Venues with no stated capacity are still returned. | |
| max_price_huf | No | Budget ceiling in HUF. Vendors with no published price are still returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses meaningful behavioral details: results are ranked by the directory's own ordering, pagination is 10 per page, vendors with unknown price/capacity/availability are kept, and each result includes a public storefront URL that should be linked. It also states the boundary of the data source (only published profiles), which is valuable 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 but information-dense, with each sentence serving a purpose: scope, when-to-use, filters, result behavior, and exclusion. The use of an em-dash for the storefront URL instruction and a final exclamation-like negative statement keep it structured and scannable.
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 no output schema, the description explains the key return characteristics: 10 results per page in the directory's own ranking, presence of a storefront URL, and the handling of unpublished data. Combined with complete parameter documentation, this makes the tool's behavior and expected output sufficiently clear for an agent to invoke and use results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 10 parameters. The description adds value by summarizing the filters into a coherent sentence and by reinforcing the key semantic that 'unknown is not a no' for price, capacity, and availability — a nuance not fully explicit in individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search Latido's public directory of Hungarian wedding vendors and venues' and lists concrete examples (photographers, venues, DJs, florists). It distinguishes itself as a directory search tool and clarifies its scope, which differentiates it from siblings like get_vendor or 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 explicitly states when to use it: 'Use it whenever someone is looking for a supplier for a wedding in Hungary.' It also provides an exclusion — 'Does NOT search vendors who have not published a profile.' However, it does not name alternative sibling tools (e.g., get_vendor for specific vendor lookup), so it stops short of fully explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
wedding_checklistWedding planning checklist for HungaryALatido's planning checklist (Hungarian legal steps included: szándékbejelentés, documents, witnesses, name change), scheduled to a wedding date: every item with its phase, category and due date, compressed proportionally when the runway is shorter than 12 months. Filter by phase (start/book/shape/finish/week/after) and depth (essentials ≈27 · core ≈93 · everything ≈115). Use for "what should we be doing now" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| depth | No | core | |
| phase | No | Only this phase. | |
| locale | No | Language for labels and copy. Use "hu" when the user writes Hungarian. | en |
| ceremony | No | civil | church | abroad | undecided — gates the Hungarian paperwork items. | undecided |
| wedding_date | No | YYYY-MM-DD. Without it, items come in order but undated. | |
| planning_started | No | When planning began (YYYY-MM-DD); defaults to today. Sets how much the 12-month template is compressed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the dynamic behavior of compressing items proportionally when the planning runway is shorter than 12 months, and explains that items come undated without wedding_date. This adds context beyond the readOnly and idempotent annotations without contradicting 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 concise, front-loaded with the core purpose, then details scheduling and filtering. Every sentence adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's behavior, scheduling logic, and filtering options. It does not describe the output format, but since it's a checklist, the item fields are implied. The complexity is moderateлекс and the description sufficiently prepares the agent.
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 descriptions for most parameters, so baseline is 3. The description adds meaning for 'depth' (by giving item counts), explains how wedding_date and planning_started affect scheduling, and clarifies that ceremony gates legal items. This goes 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 identifies the tool as a wedding planning checklist with Hungarian legal steps, specifically Latido's checklist scheduled to a wedding date. It distinguishes it from sibling tools (search, vendors, budget) by explicitly stating its purpose: 'what should we be doing now' questions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use for 'what should we be doing now' questions and explains the filtering by phase and depth. It does not explicitly state when not to use it or mention alternatives, but the usage context is clear from the description and sibling distinction.
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!