Skip to main content
Glama

Search Wedding Vendors

search_vendors
Read-onlyIdempotent

Searches published wedding vendors by category, location and price range. Results include business details and listing links, with totals and pagination; summary omits descriptions and images. Each result states whether its content was generated by Aisle from public information or is managed by the vendor, where its rating comes from, whether its category was chosen by the vendor or assigned by Aisle’s search, and the domain of its website. A price band is reported, and matched by the price filter, only when the vendor supplied it. Results can be filtered by minimum Google rating and review count, and ordered by name, rating or review count. When a location holds fewer than five matching vendors, the result lists nearby locations within 150km that hold more, with counts and distances. A location search also gives each vendor’s distance from the middle of that location’s listings, since the listed city is the place searched rather than the vendor’s own town. Vendors in the same category and location that share a website or phone number are named on each other’s results as possible duplicates. This search does not check live availability or make bookings.

Input Schema

NameRequiredDescriptionDefault
sortNoResult order: name (default), rating (highest first, ties broken by review count) or reviews (most reviewed first).
limitNoResults per page, from 1 to 50 (default 50).
offsetNoNumber of results to skip; nextOffset from the previous page continues the result set.
summaryNoReturn compact comparison fields without descriptions and images (default false).
categoryNoVendor category filter, fuzzy-matched. One of: photographer, videographer, florist, caterer, dj, band, planner, coordinator, hair_makeup, cake_bakery, officiant, rentals_decor, stationery, transportation.
locationNoLocation slug filter (e.g. "austin-tx", "london-uk")
min_ratingNoOnly vendors with at least this Google rating, out of 5. Unrated vendors are left out.
min_reviewsNoOnly vendors with at least this many Google reviews.
price_rangeNoPrice range filter: $ (budget) to $$$$ (luxury). Matches only listings whose vendor gave a band; generated listings have none.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / min_rating
      Added value: +{
      +  "description": "Only vendors with at least this Google rating, out of 5. Unrated vendors are left out.",
      +  "maximum": 5,
      +  "minimum": 0,
      +  "type": "number"
      +}
    • addedInput schema / properties / min_reviews
      Added value: +{
      +  "description": "Only vendors with at least this many Google reviews.",
      +  "maximum": 9007199254740991,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "Result order: name (default), rating (highest first, ties broken by review count) or reviews (most reviewed first).",
      +  "enum": [
      +    "name",
      +    "rating",
      +    "reviews"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / price_range / description
      Previous value: -"Price range filter: $ (budget) to $$$$ (luxury)"New value: +"Price range filter: $ (budget) to $$$$ (luxury). Matches only listings whose vendor gave a band; generated listings have none."
  3. Changed3 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Results per page, from 1 to 50 (default 50).",
      +  "maximum": 50,
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "description": "Number of results to skip; nextOffset from the previous page continues the result set.",
      +  "maximum": 100000,
      +  "minimum": 0,
      +  "type": "integer"
      +}
    • addedInput schema / properties / summary
      Added value: +{
      +  "description": "Return compact comparison fields without descriptions and images (default false).",
      +  "type": "boolean"
      +}
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnly/idempotent annotations already covering safety, the description adds substantial value: result field composition, summary mode behavior, Aisle-generated vs vendor-managed content attribution, rating provenance, price band conditional semantics, nearby-location fallback at <5 results within 150km, distance-from-corpus-center semantics, and duplicate detection via shared website/phone. This is unusually rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core purpose and filters, then layers behavioral details. At ~9 sentences it is longer than typical, but nearly every sentence conveys distinct non-obvious behavior. Slightly dense but justified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description carries the return-value burden and does so thoroughly: field contents, summary mode, attribution fields, price band reporting, nearby-location fallback, distance semantics, and duplicate flagging. An agent has enough to interpret results without further structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

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 9 parameters including enums and defaults. The description re-states some semantics (price band conditional matching, min_rating filtering) but adds little beyond what the schema provides; baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (searches published wedding vendors) with scope modifiers (by category, location, price range). Clearly distinguished from siblings like search_venues and get_vendor_details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly places itself as the discovery tool versus get_vendor_details (siblings exist for detail retrieval), and the final sentence 'does not check live availability or make bookings' sets a negative boundary. However, it never explicitly names an alternative tool or states when to prefer it over search_venues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources