find-companyFind a company by its slug and return its public profile: services, opening hours, and booking configuration. Use this first to obtain the company_id needed by the other tools.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | The company slug, as found in its booking page URL. | |
| business_type | No | Optional business type filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already establishes the safe read-only nature. The description adds that it returns a public profile with services, opening hours, and booking configuration, but does not disclose other behavioral traits such as auth requirements or rate limits. This is useful context but not rich.
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 focused sentences, front-loaded with the main action and return value, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple lookup with no output schema, but the description covers the primary return fields and the key purpose of obtaining company_id. The optional business_type parameter is not mentioned in the description, but it is fully documented in the schema, so overall completeness is 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?
Schema description coverage is 100%, with slug described as 'The company slug, as found in its booking page URL' and business_type as an optional filter. The description repeats the slug lookup but adds no new parameter semantics 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 states a specific verb and resource ('Find a company by its slug') and explicitly lists the returned content (services, opening hours, booking configuration). It also differentiates from sibling tools by noting it provides the company_id needed by the other tools.
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 'Use this first to obtain the company_id needed by the other tools', giving clear context that it is a prerequisite lookup. It does not list explicit when-not-to-use cases, but the sibling tool names make the boundary obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clear, distinct role: find-company for lookup, list-available-slots for availability, create-booking for reservations, get-booking-info for retrieval, and cancel-booking for cancellation. No overlapping purposes.
All tool names follow a consistent verb-noun pattern with lowercase hyphenated style (cancel-booking, create-booking, find-company, get-booking-info, list-available-slots). Perfectly predictable.
Five tools are well-scoped for a booking system, covering the essential guest-facing operations without unnecessary additions. The count feels appropriate and focused.
The core booking lifecycle (create, read, cancel) is covered, along with prerequisites like company lookup and slot listing. An update/modify booking operation is missing, which is a minor gap but not critical for the primary use case.