Atithi Driver Booking MCP Server

by SATISHUD

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource and action, such as driver registration/verification/updates, booking lifecycle, and queries. The workflow tools (get_next_driver, update_driver_response, timeout_driver_attempt) are clearly sequenced and separated.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case, e.g., verify_driver, create_booking, get_booking_status. There are no mixed conventions or vague verbs.
Tool Count4/5
With 20 tools, the server is slightly above the typical 3-15 range, but each tool is necessary for the driver booking domain, covering driver management, booking workflow, and queries. The count is well-scoped for its purpose.
Completeness5/5
The tool set covers the full lifecycle: driver registration/verification/updates, booking creation, driver assignment, response handling, completion/cancellation, and a rich set of queries. No major gaps that would block core workflows.
Average 3.8/5 across 20 of 20 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not state side effects, validation behavior, error handling, or whether it overwrites the existing location. The phrase 'current real-time location' hints at a live update but lacks depth.
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?
A single, front-loaded sentence with no filler or redundant phrasing. It efficiently conveys the core action, making it easy to parse. The brevity is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and a terse description, the tool's complete behavior is not sufficiently explained. It does not mention return values, prerequisites, side effects, or edge cases. Though the tool is simple, the description leaves significant gaps for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, describing both driver_id and location_id adequately ('Driver ID', 'New location ID from Locations table'). The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') and resource ('driver's current real-time location'), clearly distinguishing it from sibling tools like update_driver_availability and update_driver_details. It precisely identifies the action and the object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, lacks prerequisites (e.g., driver must exist, driver must be active), and does not mention any exclusions or alternative tools. It simply states the action without any context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits on its own. It does mention that this is an admin action, implying permission requirements, but it does not describe side effects such as whether the decision is final, what happens to the driver record, or any notifications. This is a significant gap for a mutation tool.
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 a single sentence that is concise and front-loaded with 'Admin:' to set context. It efficiently communicates the tool's core function without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a state-changing admin operation with no annotations or output schema, yet the description is minimal. It does not explain the lifecycle of a driver registration, whether the action is reversible, or what the outcome looks like. The description is insufficient for an agent to fully understand the operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters with clear descriptions (driver_id and decision with enum). The description does not add new meaning beyond the schema; it merely paraphrases the decision values. Given 100% schema coverage, the baseline for this dimension is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to approve or reject a pending driver registration. It uses a specific verb ('approve or reject') and identifies the resource ('pending driver registration'), which distinguishes it from sibling tools like update_driver_details or register_driver.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives. The description only says 'Admin: Approve or reject a pending driver registration' but does not mention prerequisites, such as the driver must be in a pending state, nor does it point to alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The verb 'Get' implies a safe read operation, but the description does not explicitly confirm there are no side effects, does not mention required permissions, error handling, or what happens if the booking ID is invalid. This lack of explicit behavioral context is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is appropriately concise and front-loaded with the core action ('Get the current status and full details'). It earns its place by including the useful detail about driver info. It is not overly verbose, though it could benefit from additional context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with a single parameter, the description provides a reasonable amount of context (what the tool returns). However, it lacks guidance on when to use it relative to sibling tools, does not describe return format, and does not cover error cases. The tool is simple enough that a score of 3 is fair, but not higher due to these omissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in the schema), and the tool description does not directly explain the 'booking_id' parameter. While it is implicitly understood that the booking_id identifies the booking of interest, the description adds little beyond the schema's bare 'string' type, leaving the agent to infer the parameter's role and any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get the current status and full details of a booking, including assigned driver info.' This uses a specific verb ('Get') and a specific resource ('booking'), distinguishing it from sibling tools like create_booking, cancel_booking, or get_driver_details.
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 implies the tool is used when you need booking status or details, but it does not explicitly state when to use it versus alternatives, nor does it provide exclusion criteria or mention related tools. The context is clear enough for a simple lookup, but guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the core action but does not mention whether results are sorted, paginated, or include all driver fields. It also does not clarify what 'available' means or if any implicit filters apply, and no side effects or permissions are mentioned.
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 a single sentence of nine words. It starts with the primary action and resource, then adds the optional filter. There is no wasted wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with one optional parameter and no output schema, the description is minimally adequate but lacks detail on result ordering, pagination, response shape, or clarity on what 'available' means. Given the rich sibling set, it could benefit from a brief behavioral note (e.g., 'Returns all active verified drivers' or 'Read-only operation').
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the optional location_id parameter with 100% coverage. The description paraphrases the schema ('filter by current location') without adding additional detail such as expected format, matching semantics, or how location nesting works. It meets the baseline of 3, as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and identifies the resource as 'currently available Verified drivers', which clearly distinguishes it from siblings like get_driver_details (retrieves a single driver) or get_next_driver (selects one for booking). The optional location filter adds additional scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_next_driver, get_driver_details, or get_hotel_preferred_drivers. The description does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of explaining side effects. It only says 'Register', which implies creation, but does not disclose what happens on duplicate phone/email/license, whether the operation is idempotent, or what response is returned. This is a significant gap for a mutation tool.
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 a single, front-loaded sentence with no superfluous content. It clearly communicates the core purpose without wasting tokens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 required parameters, no output schema, no annotations), the description is too sparse. It does not explain what 'register' entails—such as success/failure behavior, unique constraints, or workflow implications—leaving the agent with insufficient context for a write operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents all 9 parameters. The description adds no additional meaning beyond grouping them into 'driver and vehicle', so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Register' with the resource 'a new driver and their vehicle' in the 'Atithi system'. This distinguishes it from sibling tools like verify_driver and update_driver_details, which imply different actions on existing drivers.
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 implies use for adding new drivers, but does not explicitly state when to use this tool versus alternatives such as update_driver_details. No prerequisites, exclusions, or alternative tool recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must communicate the tool's behavior. It indicates a read operation via 'Get' and specifies what is returned, but does not disclose side effects, permissions, or output structure. Given the tool's likely read-only nature, the lack of additional behavioral notes is acceptable but not exemplary.
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 a single concise sentence that is front-loaded with the action and object. Every word adds meaning, and there is no redundancy or filler.
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?
For a simple getter with one parameter and no output schema, the description covers the main purpose and return categories. However, it lacks any mention of the input parameter or potential edge cases, though these are relatively obvious from the tool name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema exposes a single required driver_id property with no description, and the description does not mention this parameter at all. With 0% schema coverage and no parameter explanation in the description, the agent receives no guidance on how to supply the driver identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'driver details' and enumerates the data categories (profile, vehicle info, performance score), making the tool's function unambiguous. It clearly differentiates from sibling tools like update_driver_details or verify_driver by focusing on retrieval of comprehensive data.
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 implies usage when a complete driver profile is needed but provides no explicit guidance on when to choose this over alternative tools like verify_driver or get_next_driver. No when-not conditions or alternative references are given, leaving the context to be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds ordering by attempt number and indicates the full history, but it does not mention return format, whether failed attempts are included, or any pagination behavior.
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 a single, well-structured sentence that front-loads the core function and includes the key ordering detail. No unnecessary words or repetition.
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 low complexity (one parameter, no output schema), the description is mostly complete for a simple retrieval tool. However, it could benefit from a brief note on what the returned history contains, such as attempt statuses or timestamps.
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?
The schema has one required parameter, booking_id, and the description links it clearly by saying 'for a booking'. Even though schema coverage is 0%, the sole parameter is self-explanatory and the description reinforces its purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full call attempt history for a booking, with a specific verb ('Get') and resource ('call attempt history'). It is distinct from sibling tools like timeout_driver_attempt, which imply individual attempt actions, by emphasizing 'full history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to alternatives such as timeout_driver_attempt or get_next_driver. The description only states what the tool does, not when it should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does reveal a key behavior: partial updates (only provided fields change). However, it does not disclose return behavior, validation, permissions, or side effects. This is a meaningful disclosure but leaves significant behavioral context unstated.
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 a single sentence, front-loaded with the action, and contains no filler or redundant schema repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple update tool: purpose and partial update behavior are clear, and the schema covers all parameters. However, without annotations or an output schema, the return format and post-update behavior remain undisclosed, and with 9 parameters, slightly more contextual detail would improve completeness.
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 baseline is 3. The description adds value by clarifying that only desired change fields need to be provided, which enhances understanding of the optional parameters without repeating each schema description.
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 'Update a driver's personal or vehicle details' clearly identifies the action and resource, and the scope ('personal or vehicle details') distinguishes it from sibling tools like update_driver_availability and update_driver_location. It is specific and not a tautology, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Only provide fields you want to change' provides clear usage guidance for partial updates, implying this tool is for modifying existing driver details and that only changed fields need be supplied. It gives context but does not explicitly list when-not-to-use or alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It discloses that the tool returns all preferred drivers and that the results are sorted by driver score, making the read operation and ordering transparent. It does not detail return format or empty-list behavior, but these are minor for a straightforward read.
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 a single, concise sentence that fully conveys the purpose and sorting criteria. No wasted words or repetition.
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?
For a tool with one parameter and no output schema, the description captures the essential behavior (retrieving all preferred drivers) and ordering. It does not mention potential empty results or response shape, but these are not critical for the tool's basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines hotel_id as a required string with no description (0% coverage). The tool description mentions 'for a hotel' but does not explicitly explain that hotel_id is the hotel identifier or any expected format. The description should compensate more for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get all preferred drivers'), a resource ('for a hotel'), and an additional qualifier ('sorted by driver score'). This distinguishes it from sibling tools like add_preferred_driver, remove_preferred_driver, and list_available_drivers.
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 implies when to use the tool (when you need the list of preferred drivers for a given hotel) but does not explicitly mention alternatives or exclusion cases. It lacks guidance on how it differs from get_next_driver or list_available_drivers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It communicates that the tool creates a booking, returns a booking_id, and that driver search is a separate step, but it does not disclose side effects, prerequisites, or error conditions expected of a mutating operation.
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 concise sentences: the first states the action and key parameters, the second gives a clear follow-up. No wasted words and the core purpose is front-loaded.
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 richly detailed schema and the description covering the essential return value and next workflow step, the tool is reasonably well understood. However, the absence of annotations and minimal discussion of side effects leaves some contextual gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all parameters. The description mentions only passenger_count and estimated_fare, which are already detailed in the schema, adding no additional semantic value beyond what the structured data provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' with the resource 'guest ride booking', clearly stating the core function. It also mentions key parameters and the return value, and the follow-up instruction 'Then call get_next_driver()' distinguishes it from sibling tools like complete_booking and cancel_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit next step after creation, indicating when this tool should be used in the workflow. However, it does not mention any alternative tools or conditions under which this tool should not be used, focusing only on the sequence after creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It correctly implies a read-only operation ('Get') and suggests that 'available' is a key qualifier, but it does not disclose any additional behavioral context such as whether the result list is paginated, whether it includes both pickup and drop in a single list, or any potential limitations. For a simple list tool, this is adequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without redundant words. It is appropriately sized for the tool's simplicity.
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?
For a simple tool with one optional parameter and no output schema, the description adequately explains the tool's purpose and filtering capability. However, since there is no output schema, the description could slightly elaborate on what the returned locations look like (e.g., names, codes), but the current wording is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a clear description and enum for 'location_type', so the description's mention of 'filter by location type' adds minimal value beyond the schema. The baseline of 3 is appropriate because the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'all available pickup/drop locations,' making the tool's function unambiguous. It is clearly distinct from all sibling tools, which focus on drivers, bookings, and fares, none of which relate to location listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the primary use case: retrieving pickup/drop locations, and mentions the optional location_type filter. Since no sibling tools overlap functionally, there is no need for explicit alternatives or exclusions. The 'optionally' phrasing conveys that filtering is not required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses an authorization requirement (caller must be a Hotel Manager) but does not mention side effects, error behavior, or whether the driver must currently be on the list. This adds some value but lacks depth.
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?
Two sentences, front-loaded with the action and resource, followed by the authorization requirement. No redundancy or filler words.
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?
For a simple 3-parameter tool with no output schema, the description covers purpose and authorization. It omits potential details like return value or precondition on driver_id, but remains adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds minimal extra meaning beyond reinforcing that caller_user_id belongs to the Hotel Manager. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses the specific verb 'Remove' and names the resource 'driver from a hotel's preferred driver list', which distinguishes it from siblings like add_preferred_driver and get_hotel_preferred_drivers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use (removing a driver from a hotel's preferred driver list) and states a prerequisite (caller must be a Hotel Manager for that hotel). It doesn't explicitly exclude alternatives but the purpose is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states that it logs 'No Response' and returns a next_action, which is useful. However, it does not mention any side effects beyond logging (e.g., whether driver availability changes, attempt count increments, or if any permissions are needed). This is a moderate disclosure, but gaps remain.
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 concise sentences, immediately stating the action and its automatic side effect. It is front-loaded with the core purpose and wastes no words.
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 moderate complexity (3 parameters, no output schema), the description covers the action, the automatic log, and the return value (next_action). It is sufficiently complete for an agent to understand what the tool does and what it returns. It does not elaborate on edge cases or the full response structure, but the key context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already fully describes each parameter. The description does not add extra meaning to the parameters beyond what the schema provides, fitting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Record a 30-second timeout or dropped voice call for a driver.' It uses a specific verb ('Record') with a concrete resource (driver call timeout), and the automatic logging of 'No Response' plus the returned next_action distinguishes it from siblings like update_driver_response and get_next_driver.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool: when a 30-second timeout or dropped voice call occurs. It does not explicitly mention alternatives or when not to use it, but the condition is clear. The mention of returning next_action: GET_NEXT_DRIVER provides context on how it fits into the workflow. Lacks explicit exclusions, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states that 'All existing entries are replaced,' which is a critical destructive/replacement behavior. It does not mention permissions, response format, or error conditions, but the core side effect is clearly communicated.
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 short sentences, front-loaded with the primary action and followed by a clarifying detail. Every word earns its place, with no redundancy or filler.
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?
For this relatively simple tool with fully documented parameters and no output schema, the description sufficiently conveys the tool's purpose and key destructive effect. It could slightly improve by adding usage guidance, but given the low complexity and high schema coverage, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the key semantic that the schedule array constitutes the entire new schedule, but it does not provide additional per-parameter details beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Replace a driver's entire weekly schedule.' The second sentence reinforces the full-replacement semantics, distinguishing it from related sibling tools like update_driver_details or update_driver_location.
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 implies the use case of updating a driver's complete weekly availability, but it does not explicitly state when to use this tool versus alternatives. It does not mention exclusions or provide alternative tool names, though the 'entire weekly schedule' wording helps signal that partial updates are not supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds the key authorization constraint (Hotel Manager) and implies the driver must already be verified. However, it does not disclose side effects, idempotency, or error conditions that would be relevant for a mutation operation.
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 one concise sentence, front-loaded with the core action and resource, and includes the essential authorization requirement. There is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main action, resource, and authorization, which is adequate for a simple add operation. However, it lacks context on behavior for edge cases (e.g., driver already on list) and potential side effects, which are not covered by annotations or an output schema.
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 baseline is 3. The description adds meaning by specifying that the driver must be 'Verified,' which augments the driver_id parameter description and informs correct usage. This extra semantic justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a Verified driver to a hotel's preferred driver list.' It uses a specific verb ('Add') and identifies the resource (preferred driver list), which effectively distinguishes it from sibling tools like remove_preferred_driver and get_hotel_preferred_drivers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by stating 'Caller must be a Hotel Manager for that hotel,' which defines the required role and permission. However, it does not explicitly discuss alternatives or when-not-to-use scenarios, though the tool name and purpose make its use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals key side effects: freeing the driver and awarding +10 score. It does not mention irreversibility or prerequisites, but the disclosed effects go beyond the basic schema and help the agent understand consequences.
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 a single, front-loaded sentence with no filler. It efficiently states the action, condition, and consequences in a clear order. Every word earns its place, making it an excellent example of concise writing.
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?
The tool is simple (one parameter, no output schema), and the description covers the action, trigger, and effects. While it could mention whether the booking must be in a specific status, the provided context is sufficient for an agent to use it correctly. The description is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description 'Booking ID to complete' is simple but adequate. The tool description does not add further nuance about the parameter, but since the schema is clear and the tool only has one parameter, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Mark a booking as completed' when the guest reaches the destination. This specific verb+resource distinguishes it from sibling tools like cancel_booking or create_booking, and the additional effects (frees driver, awards score) further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: use this when the guest reaches the destination. It does not explicitly exclude alternative scenarios like cancellations, but the trigger condition is explicit enough to guide the agent. Sibling tools like cancel_booking handle other lifecycle events, so the context is sufficiently differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool calculates and presents an estimated fare, and the phrase 'before calling create_booking()' implies this tool does not itself create a booking. However, it does not detail return structure or potential side effects, leaving some ambiguity.
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 action ('Calculate...'), and every word adds value. It succinctly captures the inputs, output, and workflow without redundancy.
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?
The description is adequate for a fare estimation tool: it covers purpose, key inputs, output (fare in INR), and workflow. However, it lacks explicit return value fields or error conditions, which would be helpful given there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 5 parameters, so the schema already documents each parameter. The description adds only 'INR' and 'distance' as output context, which does not significantly enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates distance and estimated fare in INR based on specific inputs, which is a distinct function among the sibling tools. It also explicitly references create_booking(), differentiating it as a pre-booking estimation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow guidance by instructing to present the fare to the guest for confirmation before calling create_booking(). It does not explicitly mention alternatives or when not to use it, but the integration with create_booking() establishes a clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the algorithm (search Preferred then Global Pool), the capacity matching constraint, and the return payload (driver & full vehicle contact info). It does not explicitly state whether the operation has side effects, but the 'Get' verb implies read-only, and the description adds meaningful behavioral details.
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 long, front-loaded with the primary action, and every sentence adds value. It efficiently conveys the search order, the capacity matching, and the return information without fluff.
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?
For a single-parameter tool with no output schema, the description covers the essential context: purpose, search order, constraints, and return contents. It is complete enough for an agent to decide to call the tool and to understand what outcome to expect. A slight gap is that 'next best' is not fully defined beyond pool order and capacity, but the overall context is solid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully documents the single parameter 'booking_id' with a clear description. The tool description adds marginal value beyond this, just reiterating that a booking is involved. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the next best available driver for a booking, specifying the resource and action. It distinguishes itself from siblings like list_available_drivers or get_driver_details by focusing on booking-driven driver selection with a defined search order (Preferred then Global Pool).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool: when a driver needs to be allocated to a booking. It explains the search order and capacity matching, giving enough context. However, it does not explicitly mention when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the key side effect (driver score update) and the return value with possible enumeration values. It also clarifies that this is a record operation on a call response. It does not delve into failure modes or idempotency, but the disclosed behavior is directly relevant.
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?
Two sentences, no filler, relevant information front-loaded. Every word earns its place.
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?
The tool has a simple purpose, 6 required parameters, and no output schema. The description explains the return value sufficiently ('next_action' with enumerated values). It doesn't cover edge cases like duplicate responses, but for a straightforward record tool, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all 6 parameters with descriptions and enums (100% coverage). The description adds no parameter-level detail beyond what the schema provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Record') and resource ('a driver's response to a booking call'), and also notes the side effect (updates driver score) and return value (next_action). It distinguishes itself from sibling tools like update_driver_details or timeout_driver_attempt by focusing on recording responses to calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when a driver responds to a booking call, and the return value guides next steps (RIDE_STARTED or GET_NEXT_DRIVER). However, it does not explicitly mention when not to use it or compare to alternatives like timeout_driver_attempt, despite the sibling tool existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals a significant side effect (a -20 score penalty when Driver cancels) and a special case for the cancelled_by field. This goes beyond just saying 'cancel' and gives agents essential context about consequences.
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?
Two sentences, front-loaded with the primary action, and each sentence provides necessary information. There is no redundancy or fluff.
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?
For a simple 2-parameter tool with no output schema, the description covers the core action, a key side effect, and a conditional parameter value. It's missing potential details like what happens after cancellation (e.g., booking status change), but the essentials are present.
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?
Although the schema already documents both parameters, the description adds meaning beyond the enum by explaining the score penalty for 'Driver' and the special 'No Driver Available' value. This helps agents choose the correct cancelled_by value for different scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Cancel a booking' – a specific verb+resource that immediately identifies the tool's function. It also distinguishes from sibling tools like create_booking, complete_booking, and get_booking_status by focusing on cancellation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific usage condition ('If no driver was found, set cancelled_by to...') that guides correct invocation. It doesn't explicitly name alternatives or exclusions, but the tool has no direct sibling that also cancels, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![atithi-driver-booking-mcp MCP server](https://glama.ai/mcp/servers/SATISHUD/atithi-driver-booking-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SATISHUD/atithi-driver-booking-mcp)

Score Badge

Copy to your README.md:

[![atithi-driver-booking-mcp MCP server](https://glama.ai/mcp/servers/SATISHUD/atithi-driver-booking-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SATISHUD/atithi-driver-booking-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/SATISHUD/atithi-driver-booking-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server