Planthire AI MCP
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation4/5
Tools have distinct purposes, but rent_equipment subsumes the functionality of search, quote, availability, booking, and safety, creating potential ambiguity for agents whether to use the composite tool or the granular individual tools.
Naming Consistency5/5All tool names follow a consistent verb_noun pattern in snake_case (e.g., calculate_transport, check_availability, create_booking). No mixing of conventions.
Tool Count5/57 tools is well within the optimal 3-15 range for a plant hire server. Each tool serves a distinct part of the workflow without being excessive or minimal.
Completeness3/5Core workflows (search, quote, availability, booking, safety, transport) are covered, but there are notable missing operations such as update/cancel booking or modify transport. The end-to-end tool partially mitigates this but doesn't provide full CRUD.
Average 3.9/5 across 7 of 7 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.
This repository includes a glama.json configuration file.
This server has been verified by its author.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The 'Behavioral Transparency' section claims the tool is read-only with no side effects, directly contradicting the tool's apparent purpose of creating a booking (a write operation). This is a critical inconsistency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly long and includes redundant content (e.g., repeated behavioral info) and irrelevant sections like generic 'When to use' text. It should be concise and focused on booking creation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 11 parameters and no output schema or annotations, the description fails to coherently explain how to create a booking. The contradictory behavior claims and irrelevant analysis context make it incomplete and unusable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists 10 out of 11 parameters with short explanations (e.g., 'equipment_id: Equipment ID from catalog'), adding value beyond the schema's minimal titles. However, the api_key parameter is missing from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description initially states 'Create an equipment booking' but later includes a 'Behavior' section describing a read-only analysis tool with no side effects, which contradicts the tool's name and purpose. This confusion undermines clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections describe generic 'structured analysis or classification' use cases that are irrelevant to creating bookings, providing no actual guidance on when to use this booking tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides a dedicated 'Behavior' and 'Behavioral Transparency' section covering side effects (read-only, no modifications), authentication (none for basic, API key for pro), rate limits (10/day free, unlimited pro), error handling (structured errors), idempotency (fully idempotent), and data privacy (no storage). This is thorough and compensates for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and contains redundant sections: 'Behavior' and 'Behavioral Transparency' overlap significantly. The 'When to use' section is off-topic and could be omitted. While the main purpose is front-loaded, extraneous text reduces conciseness and could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers behavioral and parameter details well, but the output description is minimal ('Matching equipment with specs and rates'). Given no output schema, more detail on the return structure would be beneficial. The misaligned usage guideline also detracts from completeness. Overall, adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section describes 6 of the 7 parameters with meaningful details (e.g., units, context like 'excavators only' for min_dig_depth_m). The missing parameter 'api_key' is not described in Args but is mentioned in the behavioral transparency section. Since the schema provides no descriptions, the description adds substantial value, though one parameter is omitted from the structured list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's main purpose: 'Search the construction equipment catalog' with explicit parameters. However, the later 'When to use' section introduces a generic description about structured analysis that does not align with the equipment search functionality, potentially causing confusion and reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'When to use' and 'When NOT to use' sections are present but vague and not specific to this tool. The 'When to use' mentions 'structured analysis or classification' which is misaligned. There is no guidance on when to use this tool versus sibling tools like 'check_availability' or 'get_rental_quote', leaving the agent without sufficient differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description thoroughly covers read-only, stateless, idempotent, rate limits, authentication, error handling, and data privacy, exceeding basic requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose with redundant behavioral sections and a generic 'When to use' that adds little value. It front-loads the purpose but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite missing output schema and one parameter detail, the description provides extensive context on behavior and error handling, mostly compensating for the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args:' section explains four parameters but omits 'api_key', which is in the schema. Though mentioned later in behavioral transparency, the parameter list is incomplete, reducing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks equipment availability for a date range, with a specific verb and resource. It distinguishes from sibling tools like create_booking and get_rental_quote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections are provided, but the guidance is generic (e.g., 'structured analysis') and lacks differentiation from alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it explicitly states read-only, idempotent, no side effects, authentication needs, rate limits, error handling, and data privacy. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, but has redundancy between 'Behavior' and 'Behavioral Transparency' sections, repeating read-only and idempotent information. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes return value hint, input descriptions, behavior, and constraints. It covers error handling and rate limits. However, the return format could be more detailed. Overall adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates well. It explains equipment_id, distance_miles, depot, and return_trip with context. The api_key is not in the Args list but is described in the authentication section. Overall adds meaningful semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it estimates transport costs for equipment delivery/collection, using specific verbs and resources. It distinguishes from sibling tools like get_rental_quote and search_equipment by focusing on transport cost estimation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'When to use' and 'When NOT to use' sections provide context and exclusions, though the 'When to use' could be more specific to transport cost estimation rather than generic analysis. Alternatives are not explicitly named but differentiation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description fully discloses side effects (read-only, no side effects), authentication needs, rate limits, error handling, idempotency, and data privacy in a dedicated 'Behavioral Transparency' section.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-organized with sections but contains redundancy: the top 'Behavior' paragraph repeats information in the later 'Behavioral Transparency' section. Could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description notes return value is a detailed checklist with regulatory references. Parameter coverage is adequate except for api_key. Overall sufficient for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains equipment_type with examples but does not explicitly describe the api_key parameter, though authentication is discussed elsewhere. Partial coverage limits clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a pre-use safety inspection checklist for equipment types, citing specific regulatory frameworks (HSE, CPCS, IPAF) and listing categories. It distinctly separates from sibling tools like rent_equipment or search_equipment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'When to use' and 'When NOT to use' sections, guiding the agent to use it for structured analysis and cautioning against real-time production decisions without human review.
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 adequately discloses the tool's multi-step behavior including creating a booking and returning a safety checklist. It does not mention authorization needs or reversibility, but it covers the main side effects (booking creation).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a bold header, a concise purpose paragraph, clearly separated arguments with bullet points, and a structured return example. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides a detailed return JSON object covering all steps (search, quote, availability, booking, safety). It also fully explains arguments and workflow, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an 'Args:' section that explains each parameter with defaults and constraints (e.g., equipment_type options, postcode meaning). However, it omits the 'api_key' parameter present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is an 'end-to-end plant hire' tool that rents equipment in one call, performing multiple steps: search, quote, availability, booking, safety checklist. This distinguishes it from sibling tools that handle individual sub-steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a complete rental workflow is desired ('Rents a piece of plant equipment in one call'). However, it does not explicitly state when not to use it or mention alternatives for partial workflows, but the sibling list makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral traits: read-only, stateless, idempotent, rate limits, authentication, error handling, side effects, and data privacy. This adds significant value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (Args, Returns, Behavior, When to use) and front-loaded purpose. However, there is some redundancy (rate limits mentioned in both Behavior and Behavioral Transparency), which slightly reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description explains returns ('Detailed pricing breakdown in GBP') and covers all necessary aspects: parameters, behavior, error handling, rate limits, and idempotency. It is complete for a complex pricing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. The 'Args' section explains each parameter's purpose and default values, except for 'api_key' which is omitted. Overall, it adds meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Calculate rental pricing for equipment.' It details tiered pricing (daily, weekly, monthly) and optional costs (insurance, fuel, operator). This specificity distinguishes it from sibling tools like search_equipment or create_booking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit 'When to use' and 'When NOT to use' sections, providing clear guidance. It also contextualizes the equipment_id parameter as coming from search_equipment results, and outlines rate limits and authentication requirements.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/CSOAI-ORG/planthire-ai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server