Costa Rica local business directory — verified businesses, jobs, events, specials. Read-only.
Scored across 6 tools
Four resource-specific discovery tools (find_jobs, search_businesses, get_events, get_specials) plus one detail tool (get_business) are easy to tell apart. The main overlap is semantic_search, which spans all content types and could be chosen instead of the targeted tools, though its snippet-style output is described distinctly.
All names are snake_case verb_noun and form a readable family. Minor deviation: get_events and get_specials actually return lists, so 'list_' would be more consistent with find_jobs/search_businesses, and get_business is the only true single-entity fetch.
Six tools is well-scoped for a local business data API, covering discovery across four content types plus one detail lookup and one cross-content semantic query. Every tool earns its place with no redundant entries.
Only businesses have a detail fetch (get_business by slug); there is no get_job, get_event, or get_special to retrieve full records for those entity types, forcing agents to rely on list results or semantic snippets. Core discovery is covered, but the lifecycle is asymmetric across domains.
Search for job postings in Costa Rica. Returns title, employer, type (full/part/contract), salary, city, and URL. WhatsApp apply link requires a keyed connection.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name | |
| limit | No | ||
| industry | No | Industry ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the returned fields and a meaningful prerequisite—'WhatsApp apply link requires a keyed connection'—which signals an auth-dependent behavior not visible in the schema. The 'Search' verb also implicitly indicates a read-only operation, though pagination and rate limits are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: the primary action and scope are front-loaded, return fields are compactly listed, and the connection caveat is appended cleanly. 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?
With no output schema or annotations, the description usefully names the key returned fields, geographic scope, and a special condition about the WhatsApp apply link. It stops short of explaining parameter combinations or response envelopes, but for a simple search tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions for city and industry are terse, and the description adds only modest value: it clarifies the geographic scope (Costa Rica) and hints at output-related fields, but does not explain parameter formats or how limit interacts with results. With 67% schema coverage, the description is adequate but not compensatory.
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 a specific verb ('Search') and resource ('job postings in Costa Rica'), clearly distinguishing this tool from sibling tools focused on businesses, events, specials, or general semantic search. Listing the returned fields further confirms it is a jobs-specific 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?
No explicit guidance is given on when to use this tool versus the sibling search tools, nor are exclusions or alternatives mentioned. The intended use is inferable from the scope, but the description never tells an agent how to route between find_jobs and search_businesses or semantic_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public details of a specific business by its slug. Returns name, about, hours, tier, rating, and citation URL. Only Blue-tier-and-above businesses carry member ratings — free-tier businesses always report rating 0. WhatsApp/phone/address require a keyed connection.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The business slug from the URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses that ratings are 0 for free-tier businesses and that WhatsApp/phone/address fields require a keyed connection. It stops short of describing failure behavior for invalid slugs or any rate limiting.
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?
Four short sentences, front-loaded with the purpose before the return payload and the two caveats. Telegraphic but every sentence carries distinct information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations exist, so the description must cover return shape and behavior itself, and it does: it lists returned fields, explains the rating tier edge case, and flags the keyed-connection prerequisite for private fields. Enough for an agent to call this correctly and interpret the response.
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?
Only one parameter with 100% schema description coverage, so the schema already fully documents 'slug'. The description repeats the lookup-by-slug framing but adds no format or sourcing detail beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Get public details of a specific business by its slug') and enumerates the returned fields. It implicitly separates itself from search_businesses by emphasizing single-record lookup by slug, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: you need a slug, which the schema says comes from the URL. There is no explicit 'use this when you already have a slug, use search_businesses when you don't', and no guidance on error cases such as an unknown slug.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List upcoming events in Costa Rica. Returns title, date, venue, city, organizer, and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It usefully indicates this is a read-only listing and enumerates the returned fields, but it does not disclose ordering, filtering behavior, pagination, or data freshness. This is adequate but leaves gaps.
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. The core purpose is front-loaded, and the return-field list is useful because no output schema is provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters, the description gives a clear purpose and return fields. However, it omits parameter behavior and any usage guidance, and since there is no output schema, the description must carry more completeness weight than it does.
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 provides no property descriptions (0% coverage), and the description does not mention the 'city' or 'limit' parameters. Their names are somewhat self-explanatory, but the description adds no explicit meaning about how filtering or limiting behaves.
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 ('List'), the resource ('upcoming events'), and the geographic scope ('in Costa Rica'). This is enough to distinguish get_events from sibling tools like find_jobs and get_business.
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 given about when to choose get_events over the siblings, nor are there any exclusions or alternative tools mentioned. The intended use is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active deals and offers in Costa Rica. Returns title, discount, business, city, expiry, and URL. WhatsApp requires a keyed connection.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions that 'WhatsApp requires a keyed connection,' which is vague and incomplete. It does not disclose read-only behavior, authentication requirements beyond that hint, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Efficient with no fluff, but slightly under-specified in 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 list tool with two parameters, the description should clarify parameter usage and any special connection requirements. It does not explain how 'city' or 'limit' behave, and the WhatsApp mention is cryptic. The output fields are listed, but the tool remains incomplete for reliable 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%, so the description must compensate for the 'city' and 'limit' parameters. It never explains their meaning or effect on results. The description only lists output fields, giving no insight into how parameters control filtering or pagination.
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 a clear verb ('List') and resource ('active deals and offers in Costa Rica'), and explicitly lists return fields. It does not differentiate from siblings, but the domain (deals/offers) is distinct enough from jobs, business, events, and search that an agent can infer its purpose.
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 siblings like find_jobs or get_events. The description provides no context about scenarios that warrant choosing this tool, nor any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for businesses in Costa Rica by keyword, city, or industry. Returns business name, city, industry, hours, tier, and a citation-ready URL on azul.cr. Rated businesses (Blue tier and above with member ratings) rank first in the results; free-tier businesses carry no ratings. Contact details (WhatsApp/phone) require a keyed connection.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City name (e.g., "San José", "Escazú", "Jacó") | |
| limit | No | Max results (default 10, max 50) | |
| query | No | Search query (e.g., "restaurante", "mecánico", "farmacia") | |
| industry | No | Industry ID (e.g., "food", "tech", "auto", "health", "beauty", "sports", "home") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden well: it discloses the returned fields, the ranking policy (Blue-tier-and-above rated businesses sort first, free-tier businesses carry no ratings), and an authorization constraint for contact data. It does not mention pagination behavior or whether results are exhaustive, but the substantive behavioral traits are covered.
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?
Four compact sentences, each carrying distinct information: purpose, return shape, ranking/tier semantics, and access requirement. Purpose is front-loaded and there is no filler, though the tier/ranking sentence is dense enough to need a second read.
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, and the description compensates by enumerating return fields and explaining the ranking order an agent must interpret. With zero annotations, an explicit read-only/safety statement and any pagination note would have closed the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented with examples. The description restates the three meaningful filters (query, city, industry) but adds no syntax, matching, or combination semantics, and never mentions the limit parameter — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb (search) plus resource (businesses) and adds geography (Costa Rica) and the searchable facets (keyword, city, industry). It reads clearly against get_business (single-record fetch) and semantic_search, but never explicitly states the boundary, so sibling differentiation is inferred rather than declared.
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 when-to-use guidance is given relative to the siblings — nothing tells the agent when to prefer this over semantic_search or when to follow up with get_business for full detail. The only constraint offered is an access precondition (contact details require a keyed connection), which is not routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-powered semantic search across all Azul CR content (businesses, jobs, events, specials). Understands natural language queries like "kid-friendly outdoor activity near the beach" or "dentista que hable inglés en Liberia". Uses bge-m3 vector embeddings for meaning-based matching, fused with keyword search. Returns content snippets with entity type and similarity.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by entity type | |
| limit | No | ||
| query | Yes | Natural language query (Spanish or English, CR voseo supported) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the use of bge-m3 embeddings, fusion with keyword search, and return format (snippets with entity type and similarity). However, it does not explicitly state that it is a read-only operation, nor does it mention rate limits, pagination, or error behavior. It adds useful technical context but is not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and immediately providing concrete examples. The technical detail about embeddings is relevant but could be trimmed; overall it is efficient with no 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?
Given no annotations and no output schema, the description covers the core purpose, language support, technical approach, and return format. It lacks details on limit behavior, empty-result handling, and does not explicitly confirm read-only nature. It is adequate but has gaps that could affect an agent's confidence in edge cases.
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 67% (query and type have descriptions, limit does not). The description adds value by giving example queries and clarifying the type filter scope. However, the limit parameter is not explained anywhere, and the description does not compensate for that missing 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 it is an AI-powered semantic search across all Azul CR content types (businesses, jobs, events, specials), with explicit examples of natural language queries. This distinguishes it from sibling tools like find_jobs or get_business which are specific getters, 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 provides clear context for when to use it (semantic, natural language queries, multi-language support with CR voseo) and implies it is for cross-content search. However, it does not explicitly state when NOT to use it or name alternatives, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
find_jobsget_businessget_eventsget_specialssearch_businessessemantic_searchFind Costa Rica services, providers, classes and events; check availability and prepare bookings.
Search and discover local businesses. 30+ categories with verified contact info, hours, and reviews.
Search and discover local community listings, classifieds, services and events.
Free, read-only: local deals, events, shops and open houses near you. US and Hua Hin, Thailand.
Add one secure layer between your agents and this server.