CoreLoop Business Network

check_business_availability

Read-only

One business's opening hours, whether it is open right now, and when it next opens. Phase 1 returns published hours, not bookable slots.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`business`	Yes	Which business to ask: its CoreLoop slug, or the `business_id` returned by search_businesses. `business_id` is an opaque, stable, public routing identifier — safe to store and re-use across sessions, unchanged by a rename or a slug change, and carrying no sensitive information. Pass back exactly the value search_businesses gave you: do not parse it, do not infer meaning from its format, and do not construct one.
`location_id`	No	Which location's hours to return (id from get_info locations[]). Defaults to the primary location.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`locale`	No
`business`	No
`timezone`	No
`always_open`	No
`data_source`	No
`is_open_now`	No
`location_id`	No
`last_updated`	No
`next_open_at`	No
`location_label`	No
`operating_hours`	No

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedAug 19, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The annotation readOnlyHint=true already signals a safe read operation. The description adds that it returns published hours not bookable slots, which is a useful limitation, but does not disclose other behaviors like network effects, rate limits, or what happens if the business is not found. 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.

Conciseness5/5

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

The description is two sentences, front-loaded with the core purpose, and adds the Phase 1 distinction. Zero waste.

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

Completeness4/5

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

Given the tool has an output schema and rich parameter descriptions, the description is sufficient for basic use. The 'Phase 1' note clarifies scope. Slightly missing is explicit guidance on when this tool is preferred over competitors, but overall adequate.

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

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are extensively described. The description adds the distinction between published hours and bookable slots, but the schema already covers all parameter semantics including the business_id opaque routing id. The description's 'Phase 1' note adds context but is not necessary for parameter usage.

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

Purpose4/5

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

The description clearly states the tool returns a business's opening hours, current open status, and next opening time. It also distinguishes from 'bookable slots' and implicitly from siblings like search_businesses, though it doesn't explicitly differentiate from get_business_info which might also touch hours.

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

Usage Guidelines3/5

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

The description gives a hint about context ('Phase 1 returns published hours, not bookable slots'), but does not explicitly state when to use this vs. get_business_info or other sibling tools. Usage context is implied for checking availability, but no clear alternatives or exclusions are provided.

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

All CoreLoop Business Network tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0

Disambiguation5/5

Each tool targets a distinct aspect of a business: availability hours, service comparison, agent endpoint metadata, full profile, service catalogue, directory search, and sending inquiries. No two tools overlap in purpose; boundaries are clear.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, with most retrieval tools sharing the get_business_ prefix (get_business_info, get_business_services, get_business_agent) and clear verbs for actions (search, check, compare, send). The pattern is predictable and unambiguous.

Tool Count5/5

Seven tools is well within the ideal 3-15 range and aptly covers the core operations of a business directory: search, view details, services, availability, compare, and inquire. Each tool earns its place with no redundancy.

Completeness5/5

The set covers the full user journey from searching the directory, retrieving business profiles and service details, checking availability, comparing offers, and initiating contact. It also includes agent metadata for programmatic integration. No obvious missing operations for the stated purpose.

Resources

Need Help?