MCP Cliniko Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific resources (appointments, patients, invoices, test data) and actions, but there is some overlap between cleanup_test_data and cleanup_comprehensive_test_data, as well as generate_test_data and generate_comprehensive_test_data, which could cause confusion about which to use for test data management. The descriptions help clarify, but the boundaries are not perfectly clear.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_appointment, get_patient, list_invoices, and update_appointment. All tools use snake_case with clear, descriptive verbs, making the naming predictable and easy to understand across the entire set.
Tool Count3/5
With 27 tools, the count is on the high side for a typical MCP server, feeling somewhat heavy for the Cliniko domain. While it covers many aspects, it includes multiple test data and invoice-related tools that might be redundant or over-scoped, pushing it into the borderline range where efficiency could be impacted.
Completeness4/5
The tool set provides strong coverage for core Cliniko operations like CRUD on appointments and patients, listing resources, and handling invoices (though read-only). Minor gaps exist, such as no delete for invoice items or practitioners, and the invoice creation limitation is noted, but agents can work around these with the provided instructions and other tools.
Average 3.1/5 across 27 of 27 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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?
No annotations are provided, so the description carries full burden. It mentions 'list or search' but doesn't disclose behavioral traits like pagination behavior (implied by parameters but not stated), rate limits, authentication requirements, whether it returns active/inactive patients, or what happens when no parameters are provided. The description is minimal and leaves key behaviors unspecified.
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?
Extremely concise at just 4 words - 'List or search for patients'. It's front-loaded with the core functionality. However, this conciseness comes at the cost of completeness, making it somewhat under-specified rather than optimally efficient.
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 no annotations, no output schema, and a list/search tool with pagination parameters, the description is incomplete. It doesn't explain what the tool returns (patient objects? just IDs?), how pagination works, search capabilities beyond the 'q' parameter, or how it differs from related tools. For a tool with 3 parameters in a medical context, this is inadequate.
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 documents all three parameters with good descriptions. The description adds no additional parameter semantics beyond what's in the schema - it mentions 'search' which aligns with the 'q' parameter but provides no extra context about search syntax, ranking, or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List or search for patients' clearly states the verb ('list/search') and resource ('patients'), but it's vague about scope and doesn't distinguish from siblings like 'get_patient' or 'list_appointments'. It doesn't specify whether this returns all patients or has implicit filtering.
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 on when to use this tool versus alternatives like 'get_patient' (for single patient) or 'list_appointments' (for appointments). The description implies it can both list and search, but doesn't clarify when to use search versus list functionality or how it relates to sibling tools.
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 carries the full burden of behavioral disclosure. It states the action ('List all practitioners') but fails to describe key behaviors such as pagination handling, response format, error conditions, or any limitations (e.g., rate limits or authentication needs). This leaves significant gaps in understanding how the tool operates beyond its basic purpose.
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 extremely concise with just three words, making it front-loaded and easy to parse. However, this brevity borders on under-specification, as it omits necessary context and details that would enhance usability, slightly reducing its effectiveness despite the efficient structure.
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 and output schema, the description is incomplete for effective tool use. It does not explain what the tool returns, how results are structured, or any behavioral traits like pagination or error handling. For a list operation with two parameters and no structured output, more context is needed to ensure the agent can invoke it correctly and interpret results.
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, with parameters 'page' and 'per_page' clearly documented. The description does not add any semantic details beyond what the schema provides, such as default values or usage examples. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema adequately handles parameter documentation without additional input from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all practitioners' clearly states the verb ('List') and resource ('practitioners'), providing a basic understanding of the tool's function. However, it lacks specificity about what constitutes a 'practitioner' and does not differentiate this tool from similar sibling tools like 'list_patients' or 'list_businesses', leaving ambiguity about scope and distinctions.
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. It does not mention prerequisites, context for usage, or comparisons to sibling tools such as 'list_patients' or 'list_businesses', leaving the agent to infer usage based on the name alone without explicit direction.
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 full burden. 'Create a new appointment' implies a write operation but doesn't disclose behavioral traits such as authentication needs, side effects (e.g., calendar updates), error handling, or response format. It lacks details on what happens if constraints are violated (e.g., overlapping appointments), making it insufficient for a mutation tool with zero annotation coverage.
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, efficient sentence with zero waste—'Create a new appointment' is front-loaded and appropriately sized for the tool's purpose. Every word earns its place, making it highly concise and well-structured without unnecessary elaboration.
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 complexity (a mutation tool with 6 parameters, no annotations, and no output schema), the description is incomplete. It doesn't address return values, error conditions, or system-specific behaviors. For a tool that creates appointments in a medical context, more context on constraints or outcomes is needed, making it inadequate despite the concise structure.
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 documents all 6 parameters thoroughly (e.g., 'starts_at' as ISO 8601, 'patient_id' as optional). The description adds no meaning beyond this, not explaining relationships between parameters or business rules. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new appointment' states the basic action and resource, which is clear but minimal. It distinguishes from siblings like 'update_appointment' or 'cancel_appointment' by specifying 'new', but lacks detail on what constitutes an appointment in this context. It's not tautological but remains vague about scope or system specifics.
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. It doesn't mention prerequisites (e.g., patient must exist), exclusions, or comparisons to siblings like 'update_appointment' or 'get_available_times'. Usage is implied only by the tool name, with no explicit context or alternatives stated.
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 behavioral disclosure. 'Create a new patient' implies a write operation, but it doesn't specify permissions needed, whether the operation is idempotent, what happens on duplicate data, or the response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence ('Create a new patient') with zero waste. It's appropriately sized and front-loaded, though it could benefit from more detail given the tool's complexity.
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 (16 parameters, mutation operation) and lack of annotations or output schema, the description is incomplete. It doesn't explain return values, error handling, or behavioral aspects like data validation, leaving the agent with insufficient context for reliable 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 has 100% description coverage, with each parameter clearly documented (e.g., 'first_name' as 'Patient first name', 'date_of_birth' with format 'YYYY-MM-DD'). The description adds no additional parameter information beyond the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new patient' clearly states the verb ('Create') and resource ('patient'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'update_patient' or 'delete_patient' beyond the basic action, nor does it specify what constitutes a 'patient' in this context (e.g., medical record vs. contact).
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 like 'update_patient' or 'get_patient', nor does it mention prerequisites (e.g., required fields, authentication needs) or context for creation. It's a bare statement without usage 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 provided, the description carries full burden for behavioral disclosure. It states this is an update operation, implying mutation, but doesn't mention permissions required, whether changes are reversible, error handling, or what happens to unspecified fields. This leaves significant gaps 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 extremely concise with just four words, front-loading the core purpose without any wasted words. It's efficiently structured for quick comprehension, though this conciseness comes at the cost of completeness.
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?
For a mutation tool with 4 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens when updating (e.g., partial updates allowed?), error scenarios, or return values. The high schema coverage helps but doesn't compensate for missing behavioral 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?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description doesn't add any parameter-specific information beyond implying that parameters update fields, which is already clear from the tool name. This 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing appointment' clearly states the verb (update) and resource (appointment), but it's quite generic and doesn't differentiate from sibling tools like 'update_patient' or specify what aspects can be updated. It's a basic but accurate statement of purpose without distinguishing features.
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 like 'create_appointment' or 'cancel_appointment', nor does it mention prerequisites such as needing an existing appointment ID. It's a bare statement with no contextual usage information.
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 carries the full burden of behavioral disclosure. It mentions 'clean up' (implying deletion) and a 'dry-run option', but fails to specify critical details such as whether this operation is reversible, what permissions are required, if there are rate limits, or what happens to related data. For a destructive tool with 7 parameters, this is a significant gap in transparency.
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, efficient sentence that front-loads the core purpose ('clean up all test data') and adds key features ('granular control and dry-run option') without any wasted words. Every element earns its place, making it highly concise and well-structured.
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 (7 parameters, no annotations, no output schema, and low schema coverage), the description is insufficient. It lacks details on behavioral aspects like safety, permissions, and output format, and doesn't fully explain parameter semantics or usage context. For a comprehensive cleanup tool, this leaves too many gaps for effective agent use.
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 low at 14%, with only the 'dry_run' parameter having a description. The tool description mentions 'granular control' and 'dry-run option', which loosely map to some parameters, but it doesn't explain the meaning of parameters like 'delete_patients', 'test_domain', or the interaction between 'delete_all_test_data' and other boolean flags. This doesn't adequately compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the verb 'clean up' and resource 'all test data', and it adds 'granular control' and 'dry-run option' which provide useful context. However, it doesn't explicitly distinguish this tool from its sibling 'cleanup_test_data', which appears to be a similar tool, so it misses full sibling differentiation.
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 like 'cleanup_test_data' or 'delete_patient'/'delete_appointment'. It mentions 'granular control' and 'dry-run option' but doesn't explain when these features are beneficial or when to prefer this over other deletion tools.
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 carries the full burden of behavioral disclosure. While 'Cancel' implies a mutation operation, it doesn't specify whether this requires special permissions, if the action is reversible, what happens to associated data (e.g., invoices), or if there are rate limits. This is inadequate for a mutation tool with zero annotation coverage.
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, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the essential information ('Cancel an appointment'), making it easy to parse quickly.
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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., success confirmation, error details), side effects, or how it differs from similar tools like 'delete_appointment'. Given the complexity of appointment management, more context is needed.
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, clearly documenting both parameters (appointment_id and cancellation_reason) and their types. The description adds no additional parameter information beyond what's in the schema, so it meets the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cancel') and resource ('an appointment'), making the tool's purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'delete_appointment', which appears to serve a similar function, preventing a perfect score.
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 like 'delete_appointment' or 'update_appointment'. It also doesn't mention prerequisites (e.g., needing an existing appointment) or contextual constraints, leaving the agent to infer usage from the tool name alone.
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 carries the full burden of behavioral disclosure. It states the action is to 'Delete an appointment completely', implying a destructive, irreversible operation, but doesn't specify permissions needed, side effects, error conditions, or response format. This is inadequate for a mutation tool with zero annotation coverage.
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, direct sentence with no wasted words, making it highly concise and front-loaded. Every word contributes to the core purpose without unnecessary elaboration.
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 complexity of a deletion operation, no annotations, and no output schema, the description is incomplete. It fails to address critical aspects like what 'completely' entails, confirmation steps, return values, or error handling, leaving significant gaps for the 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?
The input schema has 100% description coverage, fully documenting the 'appointment_id' parameter. The description adds no additional meaning beyond what the schema provides, such as format details or examples, so it meets the baseline score 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('appointment'), making the purpose unambiguous. However, it doesn't differentiate from the sibling tool 'cancel_appointment', which might have similar functionality, so it doesn't reach the highest score.
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 like 'cancel_appointment' or other deletion-related tools. It lacks context about prerequisites, consequences, or typical use cases, leaving the agent with minimal direction.
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 carries full burden for behavioral disclosure but only states what the tool does, not how it behaves. It doesn't mention whether this creates persistent data, requires specific permissions, has side effects, or what the output format looks like. For a data generation tool with 15 parameters and no annotations, this is a significant gap.
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, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with this level of complexity and gets straight to the point with zero wasted text.
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?
For a complex data generation tool with 15 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what 'comprehensive' means, how the synthetic data relates to real data, what happens to existing data, or what the tool returns. The agent would struggle to use this tool effectively without additional 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?
With 0% schema description coverage for all 15 parameters, the description doesn't compensate by explaining any parameters. However, the description does imply that parameters control generation across 'all Cliniko categories', which provides some high-level context about what the parameters likely represent. This earns the baseline score despite the complete lack of parameter-specific information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generate' and the resource 'comprehensive synthetic test data across all Cliniko categories', which is specific and actionable. However, it doesn't explicitly differentiate from the sibling tool 'generate_test_data', leaving some ambiguity about when to choose one over the other.
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 like 'generate_test_data' or 'cleanup_comprehensive_test_data'. There's no mention of prerequisites, dependencies, or typical use cases, leaving the agent with insufficient context for proper tool selection.
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 behavioral disclosure. While 'Generate synthetic test data' implies a write operation (creation of data), the description doesn't specify whether this affects production data, requires special permissions, has side effects, or what the output looks like. For a tool that creates data with no annotation coverage, this lack of behavioral context is a significant gap.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool and front-loaded with the core functionality. Every part of the sentence earns its place by specifying what, for whom, and the domain context.
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 creates synthetic data (a write operation) with no annotations and no output schema, the description is incomplete. It doesn't address critical context like whether this is for testing environments only, what data gets generated, authentication requirements, or potential impacts. For a data generation tool with zero structured behavioral information, the description should provide more operational guidance.
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%, with all three parameters well-documented in the schema (num_patients, num_appointments, days_ahead). The description adds no additional parameter information beyond what's in the schema, so it doesn't enhance parameter understanding. According to the rules, with high schema coverage (>80%), the baseline score is 3 even without param info in the 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 clearly states the tool's purpose: 'Generate synthetic test data for Cliniko (Australian healthcare data)'. It specifies the verb ('Generate'), resource ('test data'), and domain context ('Cliniko', 'Australian healthcare data'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'generate_comprehensive_test_data', which is a missed opportunity for sibling distinction.
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. There's no mention of prerequisites, when this tool is appropriate, or how it differs from similar tools like 'generate_comprehensive_test_data' or 'cleanup_test_data'. Without this context, an agent might struggle to choose between these tools effectively.
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 full burden. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't disclose any behavioral traits such as authentication needs, rate limits, return format, or whether it's a real-time check versus cached data. This is a significant gap for a tool with no annotation coverage.
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, efficient sentence that directly states the tool's purpose without any fluff or redundancy. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of appointment scheduling and no output schema, the description is incomplete. It lacks details on return values (e.g., time slots, duration), error handling, or dependencies on other tools. With no annotations and a read operation that likely involves business logic, more context is needed for effective 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?
Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no additional meaning beyond what's in the schema, such as explaining relationships between parameters or usage nuances. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'available appointment times for a practitioner', making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'list_appointments' or 'get_appointment', which might also involve appointment scheduling, so it misses full sibling distinction.
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. With siblings like 'list_appointments' and 'get_appointment', there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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 full burden. It states a read operation ('Get'), but doesn't disclose behavioral traits such as error handling for invalid IDs, authentication needs, or rate limits. The description is minimal and lacks critical context for safe invocation.
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, efficient sentence with zero waste. It is appropriately sized and front-loaded, clearly stating the tool's purpose without unnecessary elaboration.
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 no annotations and no output schema, the description is incomplete. It lacks details on return values, error conditions, or operational constraints, making it inadequate for a tool that retrieves sensitive data like patient records.
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 fully documents the 'patient_id' parameter. The description adds no additional meaning beyond implying ID-based retrieval, meeting the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('a specific patient'), specifying retrieval by ID. It distinguishes from siblings like 'list_patients' by focusing on a single record, 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 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 like 'list_patients' or 'get_patient_invoices'. The description implies usage for retrieving a single patient by ID, but lacks explicit context or exclusions.
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 full burden for behavioral disclosure. 'List or search for appointments' implies a read-only operation but doesn't specify pagination behavior (implied by 'page'/'per_page' parameters), rate limits, authentication requirements, or what happens with no filters (e.g., returns all appointments). For a tool with 8 parameters and no annotation coverage, this is inadequate.
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, efficient phrase ('List or search for appointments') that front-loads the core purpose with zero wasted words. Every element earns its place by covering both listing and filtering aspects concisely.
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 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the tool's scope (e.g., whether it returns past/future appointments), pagination defaults, error conditions, or relationship to sibling tools. For a complex filtering tool in a crowded namespace, more contextual guidance is needed.
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 all 8 parameters are documented in the schema. The description adds no parameter-specific information beyond implying filtering capability ('search for'). This meets the baseline of 3 when the schema does the heavy lifting, but the description doesn't enhance understanding of parameter interactions or default behaviors.
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 'List or search for appointments' clearly states the verb ('list'/'search') and resource ('appointments'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_appointment' (singular retrieval) or 'list_appointment_types' (different resource), which prevents a perfect score.
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. With siblings like 'get_appointment' (for single appointments), 'list_patients' (different resource), and 'get_available_times' (related but distinct), the agent receives no help in choosing between them. The description merely restates the tool's function without contextual boundaries.
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 behavioral disclosure. 'List all appointment types' implies a read-only operation, but it doesn't specify if this requires authentication, how results are ordered, whether it's paginated (though schema hints at pagination), or what the output format is. For a tool with no annotation coverage, this is a significant gap in transparency.
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, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 no annotations and no output schema, the description is incomplete for a tool with parameters. It doesn't explain the return values (e.g., what fields appointment types include), error conditions, or authentication needs, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.
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%, with clear descriptions for 'page' and 'per_page' parameters. The description doesn't add any meaning beyond what the schema provides (e.g., it doesn't explain default values or constraints), so it meets the baseline of 3 where the schema does the heavy lifting.
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 'List all appointment types' clearly states the verb ('List') and resource ('appointment types'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_appointments' or 'list_patients' beyond the resource name, which keeps it from a perfect score.
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. With siblings like 'get_appointment' or 'list_appointments', there's no indication of whether this is for administrative setup, patient scheduling, or other contexts, leaving the agent to guess based on naming alone.
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 carries full burden but only states the basic action ('update') without disclosing behavioral traits like permission requirements, whether updates are partial or full, side effects on related data, or error handling. This is inadequate for a mutation tool with complex parameters.
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, efficient sentence with no wasted words, making it easy to parse. It is front-loaded with the core action, though it could benefit from more detail given the tool's complexity.
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?
For a mutation tool with 17 parameters, no annotations, and no output schema, the description is insufficient. It lacks details on behavior, return values, error cases, and how it differs from siblings, leaving significant gaps for an AI agent to operate effectively.
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 fully documents all 17 parameters. The description adds no additional meaning beyond implying that parameters correspond to patient attributes, which the schema already covers. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('update') and resource ('existing patient'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_patient' or 'get_patient' beyond the verb choice, missing explicit distinction about modifying versus creating or retrieving.
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 such as 'create_patient' for new patients or 'get_patient' for retrieval. The description lacks context about prerequisites, error conditions, or typical use cases, leaving the agent without usage direction.
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 carries full burden for behavioral disclosure. It mentions archiving (implying soft deletion rather than permanent removal), which adds some context beyond just 'delete.' However, it lacks critical details like whether this requires special permissions, if deletion is reversible, what happens to associated data (e.g., appointments, invoices), or error conditions. For a destructive operation with zero annotation coverage, this is insufficient.
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 extremely concise—a single phrase with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place by clarifying the action (archive vs. delete) and target.
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 (a destructive mutation on a key resource like a patient), the lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral nuances (e.g., archiving effects, dependencies), error handling, or return values. For a high-stakes operation in a medical context, more context is warranted.
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 input schema has 100% description coverage, with the single parameter 'patient_id' clearly documented. The description doesn't add any parameter-specific information beyond what the schema provides, but with only one well-documented parameter and high schema coverage, the baseline is strong. No additional parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete (archive)') and resource ('a patient'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from other patient-related tools like 'update_patient' or 'get_patient' beyond the obvious deletion action.
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. It doesn't mention prerequisites (e.g., patient must exist), consequences of deletion, or when to choose this over similar tools like 'cleanup_test_data' for test patients. The agent must infer usage from context alone.
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 carries full burden but only states the basic operation. It doesn't disclose behavioral traits such as error handling (e.g., what happens if ID is invalid), authentication needs, rate limits, or whether it's a read-only operation (implied but not stated).
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, clear sentence with zero waste—front-loaded and efficiently communicates the core purpose without unnecessary details. 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?
For a simple read operation with one parameter and no output schema, the description is minimally adequate. However, given no annotations and missing output details, it lacks completeness for informed agent use, such as error cases or return format.
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 parameter 'appointment_id' is fully documented in the schema. The description adds no additional meaning beyond implying ID-based retrieval, meeting the baseline for high schema coverage without extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('appointment'), specifying retrieval by ID. It distinguishes from sibling 'list_appointments' by focusing on single-item retrieval rather than listing multiple items, though it doesn't explicitly name the sibling for comparison.
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 like 'list_appointments' or 'get_patient'. The description implies usage when you have a specific appointment ID, but lacks explicit context, prerequisites, or exclusions for tool selection.
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 carries the full burden of behavioral disclosure. It adds 'READ-ONLY' to indicate safety, which is helpful, but fails to cover other aspects like permissions needed, rate limits, or what the return format looks like (e.g., list of invoices, error handling). This leaves significant gaps for a tool with potential complexity.
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, efficient sentence with zero waste—it states the action, target, and a key behavioral trait ('READ-ONLY') without redundancy. It is appropriately sized and front-loaded.
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?
Given the tool's moderate complexity (retrieving invoices for a patient) and lack of annotations or output schema, the description is minimally adequate. It covers the basic purpose and safety but misses details like return values or error cases, making it incomplete for full agent understanding.
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 description coverage is 100%, so the input schema already documents the 'patient_id' parameter fully. The description does not add any meaning beyond what the schema provides (e.g., no details on ID format or constraints), warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('invoices for a specific patient'), making the purpose unambiguous. However, it does not differentiate from sibling tools like 'get_invoice' or 'display_invoices_for_date', which limits it to a 4 instead of a 5.
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 like 'get_invoice' or 'list_invoices'. It lacks explicit when/when-not instructions or prerequisites, leaving usage context implied at best.
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 carries the full burden of behavioral disclosure. 'List all businesses' implies a read-only operation but doesn't specify permissions, pagination, rate limits, or what 'all' entails (e.g., scope, limits). This is inadequate for a tool with zero annotation coverage.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple list operation, earning its place by stating the core action clearly.
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 no annotations, no output schema, and a simple purpose, the description is incomplete. It lacks behavioral details (e.g., what 'list' returns, any constraints) that would help an agent use it correctly, making it insufficient for even a basic tool.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, but that's fine here—baseline 4 is appropriate for zero-param tools as there's nothing to compensate for.
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 'List all businesses' clearly states the verb ('List') and resource ('businesses'), making the purpose immediately understandable. It doesn't differentiate from sibling tools (like list_appointments, list_patients, etc.), but it's not vague or tautological.
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. There's no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
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 carries the full burden of behavioral disclosure. It states the tool provides 'instructions' (implying read-only, informational output), but doesn't clarify format (e.g., text, steps, links), potential side effects, or authentication needs. For a tool with zero annotation coverage, this leaves significant behavioral gaps, though it's not misleading.
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, efficient sentence: 'Get instructions on how to create invoices in Cliniko (manual process)'. It's front-loaded with the core purpose, includes clarifying scope in parentheses, and has zero wasted words. Every element 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It explains what the tool does but lacks details on output format or behavioral context. For a purely informational tool, this is passable but leaves room for improvement in guiding the agent on what to expect.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose. A baseline of 4 is applied since the schema fully handles parameters, and the description doesn't add unnecessary param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get instructions on how to create invoices in Cliniko (manual process)'. It specifies the action ('Get instructions'), resource ('invoices in Cliniko'), and scope ('manual process'), which distinguishes it from automated invoice creation tools. However, it doesn't explicitly differentiate from sibling tools like 'demo_invoice_generation' or 'display_invoices_for_date', preventing a perfect score.
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 minimal usage guidance. It implies this tool is for learning about manual invoice creation, but doesn't specify when to use it versus alternatives like 'demo_invoice_generation' or 'create_invoice' (if it existed). No explicit when-not-to-use scenarios or prerequisites are mentioned, leaving the agent with little contextual direction.
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 of behavioral disclosure. It explicitly states 'READ-ONLY', which clarifies that this is a safe, non-destructive operation. However, it does not cover other behavioral aspects like rate limits, authentication needs, error handling, or response format, leaving gaps in transparency.
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, efficient sentence that is front-loaded with the core purpose ('Get invoices for a specific appointment') and includes a key behavioral note ('READ-ONLY'). There is no wasted text, making it highly concise and well-structured.
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?
Given the tool's low complexity (1 parameter, no nested objects) and the absence of an output schema, the description is minimally adequate. It covers the basic operation and safety but lacks details on return values, error cases, or integration with sibling tools, which would enhance completeness for agent 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 has 100% description coverage, with the single parameter 'appointment_id' clearly documented. The description does not add any additional semantic information beyond what the schema provides, such as format examples or constraints, so it meets the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('invoices for a specific appointment'), making the purpose explicit. However, it does not distinguish this tool from sibling tools like 'get_invoice', 'get_patient_invoices', or 'display_invoices_for_date', which limits its score to 4 instead of 5.
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 such as 'get_patient_invoices' or 'display_invoices_for_date'. It lacks any mention of prerequisites, exclusions, or specific contexts, offering only a basic functional statement without usage differentiation.
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 of behavioral disclosure. It explicitly states 'READ-ONLY', which is helpful for safety, but doesn't mention other traits like error handling, response format, or whether it requires authentication. It adds basic value but misses key operational 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 a single, efficient sentence that front-loads the core purpose ('Get details of a specific invoice') and includes a key behavioral note ('READ-ONLY'). There is no wasted verbiage, making it easy for an agent to parse quickly.
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?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic operation and safety but lacks details on return values, error cases, or integration with sibling tools. For a read-only retrieval tool, this is passable but leaves gaps in full contextual understanding.
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, with the 'invoice_id' parameter clearly documented. The description doesn't add any semantic details beyond what the schema provides (e.g., format examples or ID sourcing). This meets the baseline for high schema coverage but doesn't enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('details of a specific invoice'), making the purpose understandable. It distinguishes from siblings like 'list_invoices' by specifying retrieval of a single invoice. However, it doesn't explicitly contrast with 'get_appointment_invoices' or 'get_patient_invoices', which might retrieve related invoice subsets.
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 like 'list_invoices' or 'get_patient_invoices'. It lacks context about prerequisites (e.g., needing an invoice ID) or exclusions, leaving the agent to infer usage from the name and parameters alone.
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 of behavioral disclosure. It adds value by explicitly stating 'READ-ONLY', which informs the agent that this is a safe, non-destructive operation. However, it lacks details on permissions, rate limits, or return format, leaving gaps in behavioral context.
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, efficient sentence that front-loads the core purpose ('List items in an invoice') and includes a key behavioral note ('READ-ONLY') without any wasted words, making it highly concise and well-structured.
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?
Given the tool's low complexity (1 parameter, no output schema) and the description's inclusion of 'READ-ONLY', it provides adequate context for a basic read operation. However, without annotations or output details, it lacks completeness for more advanced use cases, such as error handling or pagination.
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, with the 'invoice_id' parameter clearly documented. The description does not add any meaning beyond what the schema provides, such as format examples or constraints, so it meets the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'items in an invoice', making the purpose specific and understandable. However, it does not differentiate from sibling tools like 'list_invoices' or 'get_invoice', which reduces the score from a perfect 5.
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 such as 'list_invoices' or 'get_invoice'. It lacks context on prerequisites or exclusions, leaving the agent without clear usage instructions.
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 key behavioral traits: it's read-only (explicitly stated) and that invoices must be pre-created in the web interface (a constraint). However, it doesn't cover other important aspects like pagination behavior (implied by page/per_page parameters but not explained), rate limits, or authentication needs, leaving gaps for a mutation-free tool.
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, efficient sentence that front-loads the core purpose ('List invoices with filtering options') and adds a critical constraint. There's no wasted text, but it could be slightly more structured (e.g., separating purpose from constraints) for optimal clarity.
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?
Given the tool's complexity (7 parameters, no output schema, no annotations), the description is moderately complete. It covers the read-only nature and creation constraint but lacks details on output format, pagination behavior, or error handling. For a list tool with filtering, this leaves some gaps, though the high schema coverage mitigates this somewhat.
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 fully documents all 7 parameters (e.g., page, patient_id, status with enum). The description adds no additional parameter semantics beyond mentioning 'filtering options,' which is already evident from the schema. This meets the baseline score of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List invoices') and resource ('invoices'), specifying it's a read-only operation with filtering capabilities. However, it doesn't explicitly differentiate from sibling tools like 'get_invoice' (singular) or 'display_invoices_for_date' (date-specific), which would be needed for a perfect score.
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 context by mentioning 'invoices must be created in Cliniko web interface,' suggesting this tool is for viewing existing invoices, not creating them. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_invoice' (for single invoices) or 'display_invoices_for_date' (for date-specific displays), leaving some ambiguity.
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 the read-only nature and manual creation requirement, which are useful behavioral traits. However, it doesn't cover aspects like error handling, rate limits, or response format details, leaving gaps that lower the score to 3.
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 with zero waste: the first states the purpose and scope, and the second adds crucial context about manual creation. It's front-loaded and appropriately sized, earning a perfect score for efficiency.
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?
Given no annotations and no output schema, the description provides basic purpose and constraints but lacks details on return values, error cases, or integration with sibling tools. For a read-only tool with 2 parameters, it's minimally adequate but has clear gaps, resulting in a score of 3.
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 fully documents both parameters. The description adds no additional parameter semantics beyond what the schema provides, such as explaining the impact of 'display_format' choices. Thus, it meets the baseline of 3 without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'display' and resource 'invoices for a specific date', with the parenthetical '(READ-ONLY)' reinforcing the action. However, it doesn't explicitly differentiate from sibling tools like 'list_invoices' or 'get_invoice', which limits the score to 4 rather than 5.
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 context by noting invoices 'must be created manually in Cliniko', suggesting this tool is for viewing existing data. However, it lacks explicit guidance on when to use this versus alternatives like 'list_invoices' or 'get_invoice', and doesn't specify prerequisites or exclusions, resulting in a score of 3.
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 full burden. It discloses the destructive action ('Delete') and target criteria, but lacks details on permissions needed, whether deletion is reversible, rate limits, or what happens on success/failure. For a destructive tool with zero annotation coverage, this is insufficient.
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, efficient sentence with zero waste—it directly states the action, target, and criteria without unnecessary words. It is appropriately sized and front-loaded for quick understanding.
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?
Given the destructive nature and lack of annotations/output schema, the description is minimally adequate but incomplete. It specifies what gets deleted but omits critical behavioral context like safety warnings, confirmation steps, or response format. For a high-stakes deletion tool, more completeness is warranted.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately focuses on behavior rather than inputs, meeting the baseline for parameterless tools.
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 specific action ('Delete') and target resource ('all test patients'), with precise criteria defining test patients (emails ending in @gmail.com, @outlook.com, etc.). It distinguishes from siblings like 'delete_patient' by specifying bulk deletion of test data only.
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 implies usage context for cleaning up test data, but does not explicitly state when to use this vs. alternatives like 'cleanup_comprehensive_test_data' or 'delete_patient'. It provides clear scope (test patients by email domain) but lacks explicit exclusions or prerequisites.
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 of behavioral disclosure. It effectively communicates that this is a demo tool (not for production use), mentions the read-only limitation for invoices via API, and implies data generation and cleanup behaviors. However, it doesn't explicitly mention rate limits or potential side effects of 'clear_existing' beyond what the parameter description covers.
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 extremely concise and front-loaded with essential information. The first sentence states the core purpose, and the second provides the critical limitation. Every word earns its place, with no redundant information or unnecessary elaboration.
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 demo tool with comprehensive parameter documentation (100% schema coverage) but no output schema, the description provides excellent context about the tool's purpose, limitations, and appropriate usage. The only minor gap is the lack of information about what the tool returns (though as a demo tool, this is less critical). The description compensates well for the absence of annotations.
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 documents all 5 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, but it provides context about the overall workflow that helps understand how parameters fit together. This meets the baseline expectation when schema coverage is complete.
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: generating test patients and appointments, then demonstrating invoice creation. It specifies the exact sequence of actions (generate test data first, then show invoice creation) and distinguishes itself from siblings by focusing on a demo workflow rather than individual operations like create_patient or get_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: for demonstration purposes to show how invoices are created. It also gives a critical 'when-not' warning: 'Cliniko API is READ-ONLY for invoices - they must be created via the web interface,' which clearly distinguishes it from actual invoice creation tools and explains the demo nature.
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:

[![mcp-cliniko MCP server](https://glama.ai/mcp/servers/BoabAI/mcp-cliniko/badges/card.svg)](https://glama.ai/mcp/servers/BoabAI/mcp-cliniko)

Score Badge

Copy to your README.md:

[![mcp-cliniko MCP server](https://glama.ai/mcp/servers/BoabAI/mcp-cliniko/badges/score.svg)](https://glama.ai/mcp/servers/BoabAI/mcp-cliniko)

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/BoabAI/mcp-cliniko'

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