SeaWeb
Server Details
Agent-native search + booking rail: SF hotels, attractions, restaurants. Honest labeled results.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.9/5 across 25 of 25 tools scored. Lowest: 2.2/5.
Most tools have clearly distinct purposes, with vertical-specific variants (e.g., search_restaurants vs search_salons) and overlapping but differentiated functions (get_entity vs get_restaurant). Some potential ambiguity between filter and search tools, but descriptions sufficiently distinguish them.
All tools use consistent snake_case naming with a verb_noun pattern for the majority (e.g., cancel_booking, get_restaurant, list_sources). A few single-word verbs (search, recall) are exceptions but fit the pattern and are not jarring.
25 tools is on the higher side but appropriate for the broad domain covering multiple verticals (restaurants, salons), booking, search, comparison, feedback, and user memory. Each tool serves a distinct purpose, and the count does not feel excessive.
The tool set covers core workflows: search, filter, details, booking, user preferences, and feedback. Minor gaps exist, such as no listing of all bookings or ability to update a booking, but these are not critical. Overall, the surface is well-scoped for the intended use.
Available Tools
25 toolscancel_bookingADestructiveIdempotentInspect
Cancel a booking you created (allowed while requested or confirmed). Terminal bookings return their state unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and idempotentHint=true. Description adds value by noting that terminal bookings return unchanged state, which clarifies behavior. No mention of authorization or side effects beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundant words. Action and constraints are front-loaded. 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 tool with one required parameter, the description covers the main action and key constraint (booking state). No output schema needed. Missing minor nuance like what constitutes a 'terminal booking'.
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 has 0% description coverage, so description must compensate. However, description does not add any meaning to the only parameter (booking_id) beyond what is already obvious from the name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'cancel', the resource 'booking', and specific conditions ('while requested or confirmed'). It implicitly distinguishes from sibling tools like 'request_booking' or 'get_booking_status'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies when cancellation is allowed ('requested or confirmed') and notes terminal bookings behavior. No explicit exclusions or alternatives given, but the context is sufficient for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_availabilityCRead-onlyIdempotentInspect
Best-effort availability v1, real hours, stub slots.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| party_size | No | ||
| restaurant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive nature. The description adds context like 'Best-effort' and 'stub slots', which slightly enhances understanding of behavior, but 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?
The description is extremely concise (one short sentence), but it lacks substance. While brevity is good, it sacrifices clarity and completeness.
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 absence of output schema and parameter descriptions, the description should explain return values and usage. It does not, making it incomplete for an agent to use 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?
With 0% schema coverage and no description of parameters in the tool description, the agent receives no information about what date, party_size, or restaurant_id represent or their 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 'Best-effort availability v1, real hours, stub slots' is vague and does not clearly state what the tool does. It hints at availability checking but lacks specifics such as what it returns or the required inputs beyond the name.
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?
No guidance is provided on when to use this tool versus siblings like search_restaurants or request_booking. The description fails to clarify the unique role of check_availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_searchARead-onlyIdempotentInspect
A/B ranking comparison, run AFTER a normal search session when the human wants to judge result quality. Ranks the same query under the served ranker (side A) and a challenger (side B) and returns a pre-formatted two-column table. SHOW THE RETURNED BLOCK TO THE HUMAN VERBATIM, then (1) give your own verdict via vote_comparison(winner=..., judged_by="agent", query=..., track_b=...) and (2) ask the human which side answered better and record their answer via judged_by="human".
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | ||
| track_b | No | A | |
| location | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds that it returns a pre-formatted two-column table and instructs on verbatim display, which adds behavioral 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 a single paragraph that front-loads the purpose but includes procedural instructions. It is concise and every sentence adds value, though the instructions could be separated for clarity.
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 complexity (A/B comparison with follow-up actions), the description covers when to use, what it does, and what to do after. Output schema exists, so return values need not be detailed. However, it could clarify the default side A and the meaning of 'track_b' default. Overall it is sufficiently complete for an 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?
Schema description coverage is 0%, so the description must compensate for parameter meanings. While it mentions 'intent', 'track_b', and 'location' in context, it does not clearly explain what each parameter represents or how to use them (e.g., 'track_b' default is 'A' but description says side B is the challenger, causing confusion). This leaves significant ambiguity.
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/B ranking comparison after a normal search session, contrasting with search and other tools. It specifies the verb 'compare' and the resource 'search variants', and distinguishes it from siblings by the post-search context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to run AFTER a normal search session when judging result quality, and provides a step-by-step workflow including showing the result, voting via vote_comparison, and asking the human. This is a model of when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
filter_restaurantsBRead-onlyIdempotentInspect
Structured /grep filter on registry or subset of prior search hits.
| Name | Required | Description | Default |
|---|---|---|---|
| dietary | No | ||
| price_range | No | ||
| neighborhood | No | ||
| open_tonight | No | ||
| publisher_id | No | ||
| restaurant_ids | No | ||
| accepts_reservations | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety and idempotency are clear. The description adds only the 'structured /grep filter' metaphor, which does not disclose additional behavioral traits beyond what annotations provide. It fails to add value in this dimension.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the core purpose. It is front-loaded with essential meaning, though it could benefit from slightly more detail without becoming verbose.
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 7 parameters and no parameter descriptions, the description is insufficient for an agent to correctly select and invoke the tool. The output schema exists but is not shown; however, the description does not discuss return values or provide filtering syntax. A more complete description is needed for a filter tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameters are documented in the schema. The description provides no explanation of any of the 7 parameters (e.g., dietary, price_range, neighborhood). It does not compensate for the lack of schema descriptions, leaving the agent without guidance on parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Structured /grep filter on registry or subset of prior search hits' clearly identifies the tool as a filtering mechanism, using the analogy of grep, and specifies it operates on a registry or previous search results. This distinguishes it from sibling tools like search_restaurants (initial search) and filter_salons (different vertical).
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 filtering after a search or on a known set, but it does not explicitly state when to use this tool versus alternatives like search_restaurants or other filter tools. No exclusions or explicit context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
filter_salonsARead-onlyIdempotentInspect
Structured /grep filter over salons (registry or a subset of prior search_salons hits via salon_ids). Salon-only vertical.
| Name | Required | Description | Default |
|---|---|---|---|
| salon_ids | No | ||
| price_range | No | ||
| neighborhood | No | ||
| open_tonight | No | ||
| publisher_id | No | ||
| accepts_reservations | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true, covering safety and idempotency. The description adds that it is a 'structured /grep filter' and operates on registry or prior results, providing useful behavioral context 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 two sentences, efficient and front-loaded. Every phrase adds value: defines the tool, scope, and usage context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters with no descriptions and an output schema not elaborated, the description is too sparse. It does not fully equip an agent to correctly invoke the tool, especially missing parameter guidance. It provides the big picture but lacks operational detail.
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?
With 0% schema description coverage for 6 parameters, the description does not explain the meaning or usage of any parameter. It mentions salon_ids in passing but offers no details on price_range, neighborhood, open_tonight, etc. This is a significant gap.
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 is a structured grep filter over salons, specifying it can operate on the full registry or a subset from prior search_salons results, and that it is salon-only vertical. This distinguishes it from siblings like filter_restaurants or search_salons.
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 implicitly provides usage context by mentioning it works on registry or prior search results, but does not explicitly state when to use over alternatives or when not to use it. It implies post-filtering after search, which is helpful but could be more explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_booking_statusARead-onlyIdempotentInspect
Current status of a booking you created: requested | confirmed | declined | cancelled_by_user | cancelled_by_partner | expired. Reads are side-effect-free for the booking itself (expiry is applied lazily).
| Name | Required | Description | Default |
|---|---|---|---|
| booking_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds behavioral nuance by stating that reads are side-effect-free except for lazy expiry, which goes beyond annotations and warns of a subtle side effect. 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 concise sentences with no filler. First sentence enumerates possible statuses, second clarifies side effects. Every word 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 read tool with one parameter and no output schema, the description covers return values, side-effect behavior, and ownership scope. It lacks details on error handling (e.g., missing booking_id) and output format, but overall is substantially 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?
With 0% schema description coverage, the description must compensate. It mentions 'booking you created' implying ownership, but provides no details about the booking_id parameter's format, validation, or semantics. The parameter name is self-explanatory, but the description adds minimal value.
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 current status of a booking, listing all possible enum values. The verb 'get' and the resource 'booking status' are unambiguous, and it distinguishes from sibling tools like cancel_booking by focusing on read-only status retrieval.
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 notes that reads are side-effect-free and expiry is lazy, hinting at safe usage, but it does not explicitly guide when to use this tool versus alternatives like cancel_booking or request_booking. The context of sibling tools helps, but the description itself lacks direct usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_detailsARead-onlyIdempotentInspect
Detail slice (menu / service list) for one entity, the vertical-agnostic counterpart of get_menu/get_services.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds value by clarifying the tool returns a 'detail slice (menu/service list)' and is vertical-agnostic, which enriches understanding 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 single, front-loaded sentence that efficiently conveys purpose and differentiation. No redundancies or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single parameter, the description covers purpose and sibling differentiation but lacks details on the return structure or what a 'detail slice' contains. Adequate for a simple tool but could be more 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?
The schema has one required parameter (entity_id) with 0% description coverage. The description does not clarify what entity_id represents or its format, failing to compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves a 'detail slice (menu/service list) for one entity' and identifies itself as the vertical-agnostic counterpart of get_menu/get_services. This clearly indicates the tool's purpose and differentiates it from siblings, though 'detail slice' 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 implies usage for general entity details without menu/service specificity, contrasting with get_menu/get_services. However, it does not explicitly state when to use or avoid this tool, nor mention alternatives beyond those two.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_entityARead-onlyIdempotentInspect
Full schema.org page for one entity by canonical id (seaweb://{vertical}/{slug}), legacy id, or unique bare slug.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only, idempotent, and non-destructive. The description adds that it returns a full schema.org page, providing useful behavioral context 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?
One sentence contains all key information: purpose, resource, and input details. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with strong annotations, the description covers the return type (schema.org page) and input format. It could mention behavior for missing entities, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description explains that the single parameter entity_id accepts three types of IDs, adding significant meaning beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a full schema.org page for one entity using multiple ID formats (canonical, legacy, bare slug), which is specific and distinguishes it from sibling tools like get_restaurant.
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 have one of the specified ID types, but does not explicitly tell when to use this tool versus alternatives like get_restaurant or get_salon.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_hoursCRead-onlyIdempotentInspect
Return opening hours for a restaurant.
| Name | Required | Description | Default |
|---|---|---|---|
| restaurant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds no further behavioral context (e.g., time range, return format). With annotations present, additional transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence. It is concise but overly brief, missing critical details. It earns its place but lacks structure.
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?
No output schema and minimal schema coverage. The description does not clarify what the return value looks like (e.g., daily hours, special hours). Incomplete for a tool with these complexities.
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 0%, so the description should explain the parameter. It does not mention 'restaurant_id' or its purpose beyond the schema. The name is descriptive but no added meaning.
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 returns opening hours for a restaurant, which is a specific verb-resource combination. It implicitly distinguishes from siblings like 'check_availability' or 'get_menu', but does not explicitly differentiate.
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?
No guidance on when to use this tool versus alternatives such as 'get_restaurant' (which might include hours) or 'check_availability'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_restaurantBRead-onlyIdempotentInspect
Return full schema.org Restaurant page (E2-A /get slice).
| Name | Required | Description | Default |
|---|---|---|---|
| restaurant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds little beyond mentioning it returns a 'full' page, which is already implied. No contradiction.
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?
Single sentence, front-loaded with key information. However, the jargon 'E2-A /get slice' may confuse some agents, slightly reducing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single parameter, the description omits what fields are included in the 'full page' and how to obtain the ID. For a tool with many siblings, more context is needed.
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 has 0% description coverage, and the description provides no explanation of the restaurant_id parameter. The mention of 'E2-A /get slice' is jargon and does not clarify semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a 'full schema.org Restaurant page', specifying the verb (Return) and resource (Restaurant page). This distinguishes it from siblings like get_menu or get_salon.
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?
No guidance on when to use this tool versus alternatives such as get_details or get_entity. The description simply states what it does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_salonBRead-onlyIdempotentInspect
Return the full schema.org page for a salon (profile + meta).
| Name | Required | Description | Default |
|---|---|---|---|
| salon_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds that it returns a full schema.org page, but does not disclose additional behavioral details like authorization, rate limits, or response structure. With annotations, a score of 3 is appropriate.
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 sentence with no fluff. It is concise but could benefit from more structure or additional context. It earns a 4 because it is efficient without being overly minimal.
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 low complexity (one required parameter, no output schema), the description is adequate but not complete. It explains the output conceptually but lacks details on the return format or how to interpret 'meta'. With sibling tools that are similar, more context would help the agent differentiate.
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 0%, meaning the single parameter 'salon_id' has no description in the schema. The description does not add any meaning to the parameter—no explanation of format, source, or how to obtain it. The parameter name is self-explanatory, but the description fails to compensate for the lack of 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 returns the full schema.org page for a salon, including profile and meta. It uses a specific verb and resource, and distinguishes from siblings like get_restaurant, get_details, and get_entity.
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?
No guidance on when to use this tool versus alternatives such as get_details or get_entity. No prerequisites or exclusions mentioned. The description implicitly indicates it is for retrieving a specific salon's data but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_servicesARead-onlyIdempotentInspect
Return a salon's service menu (schema.org Menu shape: sections of priced services). Salon counterpart to get_menu.
| Name | Required | Description | Default |
|---|---|---|---|
| salon_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint, indicating safe, idempotent reads. The description adds value by specifying the return shape (schema.org Menu shape with sections of priced services), which enriches understanding 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 extremely concise (two sentences), front-loads the purpose, and includes a useful sibling comparison with zero wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description provides the return shape (sections of priced services) and contextualizes with sibling. It is mostly complete but could detail the output structure (e.g., array of sections) for 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 description coverage is 0%, and the description does not explain the salon_id parameter's meaning, format, or examples. While the parameter name is self-explanatory, the description should compensate for the schema gap but fails to do so.
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 a salon's service menu using a specific verb ('Return') and resource ('salon's service menu'). It distinguishes itself from the sibling tool 'get_menu' by explicitly calling itself the 'Salon counterpart to get_menu', which is precise 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 use when needing a salon's service menu, with clear contextualization as the counterpart to get_menu (for restaurants). However, it does not explicitly state when not to use it or provide exclusions, such as for restaurants, though context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_site_skillBRead-onlyIdempotentInspect
Compact action pack for ONE entity, everything an agent needs to act there without re-reading full pages: key facts, closure status, the publisher's agent_instructions (how to book, quirks), and YOUR OWN past actions with this entity. Think of it as the site's skill + your cookie for it, in one small object.
| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent behavior. The description adds specific behavioral context (e.g., includes agent instructions and past actions) that goes beyond annotations, without contradiction.
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 relatively brief but uses metaphorical language ('cookie', 'skill') that reduces clarity. It could be more direct and 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 simple schema and provided annotations, the description covers the return contents. However, it omits error conditions, performance notes, or prerequisites, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the entity_id parameter's meaning, format, or constraints. The description relies entirely on the schema, which lacks documentation.
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 a compact summary for a specific entity, including key facts, closure status, agent instructions, and past actions. It distinguishes from siblings by emphasizing it avoids re-reading full pages.
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 when needing a concise summary, but does not explicitly contrast with sibling tools like get_entity or get_details, nor provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_sourcesARead-onlyIdempotentInspect
List indexed publishers with entity counts and coverage.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds the specific output details (entity counts and coverage), providing useful context beyond the structured metadata.
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?
Single sentence of 7 words, front-loads the verb and resource, no filler. Every word 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?
With no parameters, strong annotations, and an output schema present (assumed to document return structure), the description covers the essential purpose completely.
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?
No parameters exist in the schema, so the description cannot add parameter-specific meaning. It appropriately focuses on the tool's purpose without needing param details.
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 (list), the resource (indexed publishers), and what is returned (entity counts and coverage). It is specific and distinguishes from sibling tools which deal with bookings, restaurants, etc.
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?
No explicit guidance on when to use this vs alternatives. While siblings are mostly unrelated, the lack of any usage context or exclusions makes it minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_verticalsARead-onlyIdempotentInspect
List configured verticals with entity counts and searchability.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. Description adds value by specifying output characteristics ('entity counts and searchability'), complementing annotations without contradiction.
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?
Single sentence, no wasted words. Front-loaded with essential information about action and result.
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 zero parameters and an output schema, the description fully covers what the tool does and returns. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description need not add parameter info. Schema coverage is 100% trivially. The description focuses on output, which 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?
Description clearly states the verb 'list' and resource 'configured verticals' with specific results ('entity counts and searchability'), distinguishing it from sibling tools which focus on bookings, searches, and other operations.
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?
No explicit when-to-use or alternatives are provided. However, the tool's purpose is self-evident as a read-only listing of verticals, and no conflicting siblings exist. Adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_outcomeAInspect
Record what actually happened with an entity so future sessions know: outcome one of booked | visited | called | failed | abandoned | other, with an optional short note ("booked via OpenTable for 4"). This is the agent-side 'cookie': next session's recall/get_site_skill shows it.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | ||
| outcome | Yes | ||
| entity_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a write operation (readOnlyHint=false). The description adds behavioral context: it is an agent-side 'cookie' that persists across sessions and can be retrieved by recall/get_site_skill. This goes 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 with no redundancy. The core action is stated first, followed by the outcome enum and an example. 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?
Given no output schema and 0% schema coverage, the description covers the tool's purpose, outcome values, note format, and persistence. It could mention that logging is not idempotent (but annotations already hint at that). Considered appropriate for a simple logging tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description lists valid outcome values ('booked | visited | called | failed | abandoned | other') and provides a note example, adding meaning beyond the bare schema fields. However, entity_id is not explained.
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 'Record what actually happened with an entity' – a specific verb and resource. It distinguishes from sibling tools like recall, remember, and get_site_skill which are for retrieval, while this one is for recording outcomes.
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 an action to log results, but it does not explicitly state when to use this tool versus alternatives like remember for arbitrary notes or check_availability for queries. No exclusion or when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recallARead-onlyIdempotentInspect
Read YOUR agent profile: remembered preferences, recent searches, recent per-entity actions, and top entities. Call at task start to reuse what past sessions learned (e.g. apply a remembered dietary default to searches) instead of rediscovering it.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context about what is returned (preferences, recent searches, per-entity actions, top entities). No contradictions. The added value justifies a 4, not 5, because annotations already 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 sentences, front-loaded with purpose, no wasted words. Every sentence adds value: first states what it does, second provides usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so description must explain return values. It does so by listing categories (preferences, recent searches, etc.). However, it does not specify possible formats or empty states. Still, for a recall tool, this is adequate. Score 4 because it's mostly complete but could be slightly more detailed.
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?
Tool has zero parameters; schema coverage is 100%. No need for parameter details. The description adds no parameter info but clearly explains return value. Baseline for 0 params is 4, and the description meets that.
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 reads the agent's profile (remembered preferences, recent searches, actions, top entities). The verb 'read' and resource 'agent profile' are specific, and it distinguishes from sibling tools like 'remember' (write).
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 'Call at task start to reuse what past sessions learned... instead of rediscovering it.' Provides clear when-to-use and rationale, with implicit when-not-to-use (e.g., not during task execution).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rememberAIdempotentInspect
Save a durable preference on YOUR agent profile (account-level memory that survives new sessions and API-key rotation). Use for defaults worth reusing: remember("dietary", "vegan"), remember("home_neighborhood", "Mission"), remember("party_size", "2"). Never store passwords, session cookies, or other credentials here, SeaWeb rejects that class of data by policy and it is not needed: profile memory is for preferences and outcomes, not login state.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | ||
| value | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral traits beyond annotations: durability across sessions, API-key rotation, and rejection of credential data by policy. No contradiction with annotations (idempotentHint: true is consistent).
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?
Concise 4-sentence description: purpose first, then examples, then security warning. No redundancy, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple key-value storage tool: covers purpose, usage, security, and examples. No output schema needed; sibling tools like 'recall' and 'log_outcome' are complementary.
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?
Despite 0% schema description coverage, the description compensates with concrete examples (e.g., remember('dietary', 'vegan')) that clarify key-value semantics. Slight deduction for not explicitly stating parameter types beyond examples.
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?
Description clearly states 'Save a durable preference on YOUR agent profile' with explicit examples and distinguishes from sibling tools like 'recall' by emphasizing persistence across sessions and API-key rotation.
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 when-to-use ('defaults worth reusing') and when-not-to-use ('Never store passwords, session cookies, or other credentials') with reasoning, making it easy for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
request_bookingAInspect
Request a booking for any bookable entity (restaurants, travel stays, ...).
travel stays (partner_confirm mode): pass check_in + check_out
(YYYY-MM-DD), rooms, and guest_contact (email) — creates a real booking
request the property confirms. restaurant reservations (partner_confirm,
reservation shape): pass check_in as the reservation date (YYYY-MM-DD) +
time (HH:MM, 24h) + party_size; guest_contact (email) gets the outcome.
Both: poll get_booking_status(booking_id). Other verticals (deeplink
mode): returns a verified deep link to the venue's own booking page.| Name | Required | Description | Default |
|---|---|---|---|
| time | No | ||
| rooms | No | ||
| check_in | No | ||
| check_out | No | ||
| diner_name | No | ||
| party_size | Yes | ||
| diner_phone | No | ||
| guest_contact | No | ||
| restaurant_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, openWorldHint=true) already indicate write capability and dynamic behavior. The description adds critical behavioral traits: for travel stays, it creates a real booking request that the property confirms; for restaurants, the outcome is sent via email; for others, it returns a verified deep link. It also mentions the need to poll get_booking_status, which is not evident from annotations. No contradictions found.
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 well-structured, front-loading the general purpose followed by mode-specific details. It is relatively concise with minimal redundancy (e.g., repeated polling note is acceptable for clarity). Every sentence adds value, though a slight trim could be made. Overall efficient and readable.
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 complexity (9 parameters, multiple modes, no output schema), the description covers the main workflow and outcomes but lacks details on return format for non-deeplink modes and error handling. It references polling get_booking_status but does not specify what the tool itself returns (e.g., a booking ID). The description is functional but could be more complete for an agent to handle all scenarios.
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?
With 0% schema description coverage, the description must compensate. It explains key parameters for each mode (check_in, check_out, rooms, party_size, time, guest_contact) and their formats (YYYY-MM-DD, HH:MM). However, several parameters like diner_name, diner_phone, and restaurant_id are not explained in the description, leaving partial information for the agent. The coverage is good for primary use cases but incomplete for all 9 parameters.
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 is for requesting bookings for any bookable entity (restaurants, travel stays, etc.), with specific verbs and resource differentiation from sibling tools like cancel_booking and check_availability. It distinguishes between modes (partner_confirm, deeplink) and provides concrete examples, making the purpose 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 explicitly details when to use this tool for different verticals: travel stays (pass check_in, check_out, rooms, guest_contact), restaurant reservations (pass check_in with time, party_size, guest_contact), and other verticals (deeplink mode). It also advises to poll get_booking_status for follow-up, providing clear context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyIdempotentInspect
Search any SeaWeb vertical by natural-language intent.
vertical: one of list_verticals() (e.g. "restaurants"). intent: free
text. location: neighborhood filter; empty = all SF. goal:
discover|book. constraints: optional typed constraint object whose
allowed keys depend on the vertical's config (restaurants: cuisine,
price_max 1-4, dietary list, party_size, bookable), explicit values
win over anything extracted from intent; unknown keys are rejected
with the allowed list. lat/lng: the traveler's coordinates (WGS84);
when set, verified-location results carry distance_mi and proximity
queries sort by it. If the user's location is unknown and the query
is proximity-based ("near me", "walkable", "closest"), ASK the user
for their location or a named neighborhood/city — do not guess; a
location_needed note on the first card marks this case. Use recall()
for the account's stored preferences (e.g. home_neighborhood) when
available. Returns ranked entity cards with canonical
seaweb://{vertical}/{slug} ids.| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | ||
| lng | No | ||
| goal | No | ||
| intent | Yes | ||
| location | No | ||
| vertical | Yes | ||
| constraints | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnly, non-destructive, idempotent behavior. The description adds critical behavioral details: constraints validation (unknown keys rejected), proximity sorting when lat/lng set, location_needed note, and recall integration. 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?
The description is fairly long but well-structured, front-loading the main purpose. Given the complexity (7 parameters, 0% schema coverage), the length is justified. A minor reduction in detail on secondary behaviors could improve conciseness.
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 complex search tool with 7 parameters, the description covers all aspects: vertical selection, intent, location, goal, constraints validation, lat/lng usage, proximity handling, recall integration, and return format. Output schema exists, so return values are already documented.
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 0%, but the description fully compensates. Each parameter is explained: vertical from list_verticals(), intent as free text, location as neighborhood filter, constraints as typed object with vertical-dependent keys (e.g., restaurants: cuisine, price_max, dietary, party_size, bookable), and lat/lng as WGS84 coordinates with behavioral implications.
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 any SeaWeb vertical by natural-language intent, specifying return format (ranked entity cards with canonical seaweb://{vertical}/{slug} ids). This distinguishes it from vertical-specific siblings like search_restaurants and search_salons.
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?
Explicit guidance is provided: how to use vertical, intent, location, goal, constraints; when to ask for user location for proximity-based queries; and to use recall() for stored preferences. Alternatives are clear from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_restaurantsARead-onlyIdempotentInspect
Search restaurants by natural-language intent. location: neighborhood filter (e.g. "Mission", "Marina"); empty (default) = no filter, all SF. goal: discover|book (optional).
Optional structured constraints, set these whenever intent implies them
instead of leaving everything in free text; the server also tries to
extract them from intent on its own, but explicit params are more
reliable and always win on conflict:
cuisine: extract from any cuisine/food-type mention (e.g. "italian food",
"thai place", "sushi"), pass the cuisine word itself, e.g. "italian".
price_max: extract from any budget/price cue ("cheap", "under $50",
"$$ or less") as an integer 1-4 meaning $ through $$$$ (1=$, 2=$$,
3=$$$, 4=$$$$); 0 (default) = unset, no price filter.
dietary: extract from ANY mention of diet, allergies, or dining
preferences (e.g. "my wife is vegetarian" -> ["vegetarian"], "gluten
allergy" -> ["gluten-free"]). Bare and "-options"-suffixed forms both
match (e.g. "vegan" matches a restaurant tagged "vegan-options"), so
either is fine, prefer values from this set: vegan, vegan-options,
vegetarian, vegetarian-options, gluten-free-options, dairy-free-options,
organic, plant-based-milk, fair-trade. This is a HARD filter, every
listed value must be satisfiable by a returned restaurant, never
relaxed.
party_size: extract from any group-size mention ("for 6", "party of 4",
"just the two of us" -> 2). 0 (default) = unset.
bookable: True only when the caller specifically needs a restaurant with
a live booking link (e.g. "somewhere I can book right now"). False
(default) means UNFILTERED, it does NOT mean "must not be bookable";
there is no way to require a non-bookable restaurant through this
param.| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| intent | Yes | ||
| cuisine | No | ||
| dietary | No | ||
| bookable | No | ||
| location | No | ||
| price_max | No | ||
| party_size | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the server extracts parameters from intent, explicit params override, and clarifies bookable=True/False semantics (False is unfiltered, not exclusion). 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?
The description is fairly long but well-organized with parameter-specific sections. It front-loads the core purpose and then details each parameter. While some redundancy exists (e.g., repeated 'unset' notes), every sentence serves a 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 parameter count (8), output schema existence, and annotation richness, the description covers how to use each parameter and their interactions. Minor gaps: no mention of error handling, result limits, or pagination, but overall sufficient for effective tool invocation.
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 0%. The description compensates thoroughly: it explains all 8 parameters with extraction rules, allowed values (e.g., price_max 1-4, dietary set), default behaviors, and nuance (e.g., bookable=False means unfiltered). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Search restaurants by natural-language intent,' identifying the verb (search), resource (restaurants), and method (intent). It differentiates from sibling tools like 'search_salons' and 'filter_restaurants' by focusing on intent-based search and mentioning location and goal parameters.
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 advises setting structured parameters 'whenever intent implies them' for reliability, and notes that the server also extracts from intent but explicit params win. However, it does not explicitly state when to use this tool vs. siblings like 'filter_restaurants' or 'check_availability'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_salonsARead-onlyIdempotentInspect
Search hair salons, barbershops and beauty salons by natural-language intent (e.g. "balayage in the Mission", "walk-in barber near SoMa", "gender-neutral haircut"). Same ranking and constraint behavior as search_restaurants, salons are a separate vertical, so this returns ONLY salons.
location: neighborhood filter (e.g. "Mission District", "SoMa", "The
Castro"); empty (default) = all SF.
goal: discover|book (optional).
cuisine: reused as the SERVICE-TYPE slot, pass a service word to filter
(e.g. "color", "balayage", "haircut", "perm", "beard trim").
price_max: budget cue as int 1-4 ($ through $$$$); 0 = unset.
dietary: unused for salons (no dietary tags); leave empty.
party_size: group-size mention ("for 2"); 0 = unset.
bookable: True only when the caller needs a live booking link.| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| intent | Yes | ||
| cuisine | No | ||
| dietary | No | ||
| bookable | No | ||
| location | No | ||
| price_max | No | ||
| party_size | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses ranking/constraint behavior identical to search_restaurants and details parameter behavior (e.g., cuisine slot reused, dietary unused). Annotations already provide readOnlyHint and idempotentHint; description adds value with behavioral context but omits pagination or response 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?
Well-structured with a general overview followed by parameter details. Slightly verbose but organized; front-loaded with core purpose. Could be more concise by moving some parameter details to schema.
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?
Complete for a multi-parameter search tool with no schema descriptions. Covers all parameters, highlights constraints (dietary unused, cuisine reinterpreted), and references sibling behavior. Output schema exists separately, so return values are not needed.
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 has 0% description coverage, so description fully compensates by explaining all 8 parameters, including special behavior (cuisine as service-type, dietary unused, bookable only for live booking). Provides examples for intent and location.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches hair salons, barbershops, and beauty salons by natural-language intent with specific examples. Distinguishes from sibling search_restaurants by noting salons are a separate vertical and returns only salons.
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?
Explains when to use (salon search) and references sibling search_restaurants for comparison. Mentions constraints like dietary unused and bookable condition, but does not explicitly list when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_feedbackAInspect
Rate a search result you actually used. Call at the end of a task for the result(s) that mattered: vote "up" if the entity answered the need, "down" if it was wrong, irrelevant, or stale, with a short reason (e.g. "menu was current", "permanently closed"). Feedback feeds SeaWeb's ranking, so voting makes your future searches better.
| Name | Required | Description | Default |
|---|---|---|---|
| vote | Yes | ||
| reason | No | ||
| entity_id | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that feedback feeds SeaWeb's ranking, implying a side effect on search results. It also provides behavioral context (call at end of task, short reason). Annotations already show it is a write operation (readOnlyHint false) and not destructive, so the description adds useful context about the ranking impact.
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, front-loaded with the core action and usage timing, with no wasted words. Every sentence adds value: purpose, when, how, why.
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 feedback submission tool with no output schema, the description covers all critical aspects: what, when, how to vote, and the reason for feedback. No missing information.
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 explains the purpose of entity_id (the result used), vote (up/down with criteria), and reason (short justification). Since schema coverage is 0%, the description effectively defines the allowed vote values as 'up' and 'down', and clarifies the reason field's use, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is for rating a search result that was actually used, with specific verbs 'rate' and 'vote', and resource 'search result'. It distinguishes from siblings like vote_comparison by focusing on end-of-task feedback for a single entity.
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 to call at the end of a task for the result(s) that mattered, and explains when to vote up/down with examples. It motivates usage by noting it improves future searches, but does not mention alternatives like vote_comparison or explicitly exclude other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
vote_comparisonAInspect
Record an A/B verdict after compare_search. winner: "A", "B", or "tie". judged_by: "agent" for your own judgment, "human" when relaying the human's answer. Pass the same query and track_b the comparison used.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | ||
| reason | No | ||
| winner | Yes | ||
| track_b | No | A | |
| judged_by | No | human |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate mutation (readOnlyHint=false). Description explains parameter values (winner, judged_by) but doesn't disclose side effects, authorization needs, or idempotency 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?
Two concise sentences with front-loaded purpose. No filler words. 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?
Covers most parameters and usage context. Missing reason parameter explanation. No output schema, but description implies no return value needed.
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 0%, so description carries the burden. It explains winner, judged_by, query, and track_b. Missing reason parameter 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 'Record an A/B verdict after compare_search', specifying the verb (record) and resource (verdict). It distinguishes from sibling compare_search by mentioning 'after compare_search'.
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 clear context: use after compare_search and pass the same query and track_b. Does not explicitly exclude when not to use, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!