Review business details, scheduling staff, locations, services and appointment schedules.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 9 tools
Each tool maps to a clearly distinct resource (appointment, business, location, service, staff) and action (get vs list). No two tools overlap in purpose, and the resource-specific IDs in descriptions further reduce misselection.
All names follow a consistent timetap_<verb>_<noun> snake_case pattern. The get/list distinction is applied predictably across resources.
Nine tools is well-scoped for the read-oriented surface. Each resource has a clear read operation, and the count avoids unnecessary bulk.
The surface is read-only: there are no tools to create, reschedule, cancel, or update appointments, nor to check availability or manage clients. For a scheduling platform this misses core lifecycle operations that agents would commonly need.
Read one appointment by its numeric calendarId. Selected scheduling fields only; clients, notes, form answers, private URLs and other unselected fields are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered; the description earns credit by disclosing that the response is a partial projection, naming exactly which fields are omitted (clients, notes, form answers, private URLs). It does not describe behavior on a nonexistent id, which is the remaining gap.
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 tight sentences, no filler, with the retrieval scope front-loaded and the field-omission caveat immediately after. Every clause conveys information an agent cannot get from the 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?
For a one-parameter, annotated read-only tool with no output schema, the description covers the essentials including the shape limitation of the return value. Only the id-ambiguity and not-found behavior keep it from being fully 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 description coverage is 0%, so the description must carry the full load. It adds that the value is numeric and calls it a calendarId, but the schema parameter is named `id` and the description never resolves whether that is the appointment id or a calendar id, leaving the single required parameter under-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?
States a specific verb and resource ("Read one appointment") and scopes it to a single record, which separates it from the plural timetap_list_appointments sibling. The identifier phrase "numeric calendarId" is slightly ambiguous against the schema's bare `id`, so the purpose is clear but the key naming creates a small wrinkle.
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: "Read one appointment" suggests single-record retrieval versus the list sibling, but the description never explicitly says when to use this instead of timetap_list_appointments or what to do if the id is unknown. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the authenticated business ID, name and selected scheduling settings. Excludes billing tokens and payment configuration.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true is already declared in annotations, and "Read" is consistent with it, so no contradiction. The description adds one genuinely useful behavioral detail — that billing tokens and payment configuration are deliberately excluded, which signals a redacted/partial payload — but it does not address scope/permission failures or whether "selected" settings depend on account configuration.
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, zero waste: the positive content is front-loaded and the exclusion follows. Every clause carries information an agent would otherwise have to guess at.
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, the description must carry the return contract, and it partly does by naming ID, name, and settings plus the exclusions. But "selected scheduling settings" is undefined — an agent cannot know which fields to expect or how to detect missing ones — which is a meaningful gap for the only documentation of 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?
The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool applies. The scope word "authenticated" usefully clarifies that the target business is derived from the credential rather than supplied by the caller.
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 ("Read") and a specific resource ("the authenticated business"), and enumerates what comes back: ID, name, and selected scheduling settings. The resource is clearly distinct from the appointment/location/service/staff resources covered by every sibling tool, so an agent can route here without opening a schema.
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 by the phrase "authenticated business" — the agent can infer this is the tool for resolving the current account context before calling the entity-specific siblings, but no when-to-use or when-not-to-use condition is stated and no alternative is named. The exclusion clause concerns returned content, not invocation guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one scheduling location by its numeric locationId. Selected scheduling fields only; clients, notes, form answers, private URLs and other unselected fields are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes the safety profile, so the description's job is to add beyond that — and it does, disclosing that this is a partial projection (clients, notes, form answers, private URLs omitted). That is meaningful behavioral context an agent can't get from the schema, though it doesn't cover error behavior for an invalid ID.
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 waste, with the identification mechanism front-loaded and the field-projection caveat immediately after. Every clause carries information.
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, the description usefully characterizes the return payload by naming what is included and, more concretely, what is omitted. Complete enough to call correctly; a note on behavior when the ID doesn't exist would close 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 0% and the schema only names the field "id", but the description clarifies it is a numeric locationId, resolving the ambiguity about which entity's ID is expected. It doesn't add format or lookup semantics beyond that, but for a single required param that clarification is the key gap filled.
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 ("Read one scheduling location by its numeric locationId"), and the word "one" implicitly distinguishes it from timetap_list_locations. It doesn't name that sibling explicitly, so the differentiation is inferred rather than stated.
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?
"by its numeric locationId" implies the precondition that you already have an ID, which is useful usage context. There is no explicit when-to-use / when-not guidance pointing to timetap_list_locations for discovery or to the appointment/service/staff getters, so the agent must infer the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one service by its numeric reasonId. Selected scheduling fields only; clients, notes, form answers, private URLs and other unselected fields are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safety, and the description adds useful behavioral context by disclosing that only selected scheduling fields are returned and that clients, notes, form answers, private URLs and other unselected fields are omitted. It does not cover error behavior or authentication, but the omitted-field disclosure is meaningful 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?
Two short sentences, front-loaded with the primary action and followed by the important data-omission caveat. 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?
For a simple read-by-ID tool with no output schema, the description gives enough context to invoke it correctly and warns that the result is partial. A fuller list of returned fields would improve completeness, but nothing critical for invocation is missing.
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 single `id` parameter. It clarifies that the ID is a numeric `reasonId`, which helps, but does not explain the source of that ID or resolve the naming difference between `id` and `reasonId`.
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: 'Read one service by its numeric reasonId.' The singular 'one service' clearly distinguishes it from the sibling `timetap_list_services` without requiring the agent to open either schema.
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 implied by 'Read one service by its numeric reasonId,' but the description does not explicitly say when to use this tool versus `timetap_list_services` or how to obtain the ID. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one scheduling staff member by its numeric professionalId. Selected scheduling fields only; clients, notes, form answers, private URLs and other unselected fields are omitted.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds genuine non-obvious behavior: this is a projected read that omits clients, notes, form answers and private URLs, which tells the agent not to expect contact or notes data here and to look elsewhere for it.
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, zero filler, with the lookup key and the field-projection caveat both front-loaded. Every clause carries information the schema does not.
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?
There is no output schema, and the description says which fields are omitted but not which fields are actually returned, which leaves the response shape partly unknown. For a trivial one-parameter read with readOnly annotations, that is a modest gap rather than a blocking one.
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% — the schema only names the field "id" as an integer — so the description must compensate, and it does by identifying the value as the numeric professionalId. It stops short of giving format examples or stating that the id must be positive, so it is not fully exhaustive.
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 ("Read one scheduling staff member") plus the lookup key (numeric professionalId), which cleanly separates it from the sibling timetap_list_staff. An agent can pick this over the list variant without opening either schema.
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 implied by "Read one ... by its numeric professionalId" — the single-record counterpart to list_staff — but the description never explicitly says when to prefer this over timetap_list_staff or timetap_get_appointment, nor what to do if the id is unknown. No exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page from GET /appointmentList/reportWithCount using an ordered YYYY-MM-DD date range (up to 93 days). Client records/contact, subject/notes, forms/custom fields, payment and appointment management links are omitted. PERSONAL time-off is excluded. Local wall-clock numbers are TimeTap HHmm values, not decimal hours; UTC epoch fields are milliseconds. Count is the vendor total; request the next page until exhausted.
| Name | Required | Description | Default |
|---|---|---|---|
| endDate | Yes | ||
| pageSize | No | ||
| startDate | Yes | ||
| pageNumber | No | ||
| statusList | No | ||
| staffIdList | No | ||
| reasonIdList | No | ||
| locationIdList | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safe read behavior, but the description adds substantial operational context: omitted fields (client records, notes, payment links), exclusion of PERSONAL time-off, TimeTap HHmm formatting caveats, millisecond epochs, and vendor-total pagination semantics. This is rich behavioral disclosure 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 dense but front-loaded paragraph with no filler. Every sentence adds operational value, from endpoint and date range to omitted data, exclusions, formatting, and pagination.
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 an 8-parameter listing tool with no output schema and only a readOnly annotation, the description covers pagination, exclusions, and some data-format caveats. It is still incomplete because it does not explain the filtering parameters or pageSize/pageNumber, which an agent needs to invoke the tool precisely.
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 carry parameter meaning. It explains startDate/endDate format and the 93-day limit and touches on pagination, but it leaves pageSize, pageNumber, statusList enum values, staffIdList, reasonIdList, and locationIdList largely undocumented.
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: 'Read one page from GET /appointmentList/reportWithCount' for an appointment date range. It clearly implies listing rather than fetching a single appointment, though it does not name the sibling timetap_get_appointment as the alternative.
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?
It gives useful usage constraints, including an ordered YYYY-MM-DD range up to 93 days and the instruction to request the next page until exhausted. However, it does not explicitly say when to use this tool versus timetap_get_appointment or the other list/get tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of scheduling locations. Continue pageNumber while the returned page is full; vendor provides no total on this route. Excludes private scheduling links, embed codes, email and tax IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| staffId | No | ||
| working | No | ||
| pageSize | No | ||
| pageNumber | No | ||
| locationGroupId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already declares this a safe read, so the description correctly spends its words on non-obvious behavior: no total count is available, so termination must be inferred from a full page, and certain sensitive fields (private scheduling links, embed codes, email, tax IDs) are omitted from results. That is genuinely useful context the annotations cannot convey.
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?
Three tight sentences, front-loaded with the action and pagination rule, with zero filler. The trailing exclusion clause is slightly terse but 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?
Pagination termination and field exclusions are well covered, but with five fully undocumented parameters and no output schema, an agent still lacks the filter semantics needed to call this correctly for anything other than unfiltered listing.
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 five parameters are present, yet the description only touches pageNumber implicitly through the pagination advice. It says nothing about what staffId, working, or locationGroupId filter, so the agent is left guessing at the meaning and interaction of the three substantive filters.
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+resource ('Read one page of scheduling locations') and the 'one page' phrasing distinguishes it from the singular sibling timetap_get_location. It stops short of naming any sibling explicitly, so an agent must infer the list-vs-get split.
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?
Gives real pagination guidance ('Continue pageNumber while the returned page is full; vendor provides no total on this route'), which tells the agent when to keep calling. It offers no guidance on when to choose this over timetap_get_location or the other list_* siblings, nor on when filters should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET /services. Read service/reason IDs, names, duration and pricing; private PERSONAL reasons are excluded via includePersonal=0. Vendor route is unpaginated, bounded to 5,000 rows/2 MiB. Results reflect the credential's permissions and scheduling filters.
| Name | Required | Description | Default |
|---|---|---|---|
| staffId | No | ||
| inactive | No | ||
| locationId | No | ||
| classesOnly | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint already covers the safety profile, and the description adds genuinely useful behavior beyond annotations: the endpoint is unpaginated and bounded to 5,000 rows/2 MiB, results are filtered by credential permissions and scheduling filters, and personal reasons are excluded. This is substantive operational context an agent cannot get from the schema.
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?
Three dense sentences, front-loaded with the route and payload contents, with limits and permission behavior following. No filler, though the includePersonal mention is wasted text on a nonexistent parameter.
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 description helpfully enumerates return fields, compensating for the absence of an output schema. However, with four fully undocumented parameters and no output schema, the definition leaves the agent guessing how to filter results, which is a real gap for a listing 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 description coverage is 0% and none of the four actual parameters (staffId, inactive, locationId, classesOnly) are explained. Worse, the description references an 'includePersonal=0' parameter that does not exist in the schema, which is misleading rather than compensating for the coverage 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?
States a specific verb and resource ('Read service/reason IDs, names, duration and pricing' for GET /services), making it clear this is a bulk listing of services. It is distinguishable from the singular timetap_get_service sibling by the plural listing nature, though it never explicitly names that sibling.
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 context is implied through scoping notes ('private PERSONAL reasons are excluded', 'Results reflect the credential's permissions and scheduling filters'), but there is no explicit guidance on when to call this versus timetap_get_service or how the filters (staffId, locationId, classesOnly) should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET /staff. Read staff IDs, names and scheduling flags. No contact details, user logins or profiles. Vendor route is unpaginated, bounded here to 5,000 rows/2 MiB. locationId values are sent comma-separated as documented.
| Name | Required | Description | Default |
|---|---|---|---|
| locationId | No | ||
| acceptAppointments | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses the returned fields, explicitly excludes sensitive fields, and warns that the vendor route is unpaginated but bounded to 5,000 rows or 2 MiB. It also notes the comma-separated locationId behavior.
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 short and front-loaded: the route, return fields, exclusions and bounds are all stated without filler. Every sentence adds useful context.
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 listing tool with no output schema and only a readOnlyHint annotation, the description sufficiently covers return scope, exclusions and result-size bounds. The missing explanation of acceptAppointments keeps it from being fully 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 description coverage is 0%, so the description must compensate. It explains that locationId values are sent comma-separated, which adds meaning, but acceptAppointments is left undocumented.
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: it reads staff IDs, names and scheduling flags. It is clearly a list operation, but it does not explicitly differentiate itself from the sibling timetap_get_staff.
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 gives scope by excluding contact details, logins and profiles, but it does not say when to use this tool instead of timetap_get_staff or other sibling tools. No alternatives or preconditions are named.
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.
timetap_get_appointmenttimetap_get_businesstimetap_get_locationtimetap_get_servicetimetap_get_stafftimetap_list_appointmentstimetap_list_locationstimetap_list_servicestimetap_list_staffReview appointments, customers and staff, and manage Bookafy bookings.
Review Cliento locations, staff, resources, services, products and stock.
Appointments, clients, sales and reviews for salons and spas.
Bookings, clients, reviews and reports for beauty businesses.
Add one secure layer between your agents and this server.