Submit a lead (contact request) to Covington Heat & Air. Requires an API key and explicit user consent.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| No | |||
| phone | Yes | ||
| cityZip | No | ||
| consent | Yes | ||
| message | No | ||
| consentText | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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 the useful prerequisites of an API key and explicit consent, but it does not describe the external side effects of submitting a lead, any response/return behavior, error conditions, or what happens after submission. For a mutation-like action 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The primary action is front-loaded and the key prerequisites are stated immediately after, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter tool with no output schema and no annotations, this description is minimal. It omits response format, error handling, consent text requirements, and guidance on how this lead submission relates to the booking sibling. An agent would need to make assumptions or inspect external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds little parameter-level meaning. It clarifies that consent is required, but leaves email, phone, cityZip, message, and consentText unexplained. The parameter names are somewhat self-evident, but the description does not compensate for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a lead') and the target ('Covington Heat & Air'). It distinguishes this from the sibling booking tool by describing the resource as a lead/contact request, though it does not explicitly contrast itself with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for lead/contact requests and gives some logical prerequisites ('Requires an API key and explicit user consent'). However, it does not state when to prefer this tool over submit_covington_booking_request or other siblings, nor does it mention exclusions or fallback scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action or resource: retrieving articles, searching articles, getting business info, checking service area, describing the analysis tool, running the analysis, and submitting two different types of contact requests. The two content tools are clearly separated as search vs. full retrieval, and booking vs. lead submissions are differentiated by their descriptions.
All tool names follow a consistent verb_noun pattern with snake_case: get_*, search_*, run_*, and submit_*. While the domain prefixes vary (hvac, okc_hvac, covington, repair_or_replace), the overall grammatical structure is uniform and predictable.
Eight tools is well-scoped for this server's purpose. It covers content discovery, business information, service area verification, decision tool metadata, the actual analysis, and two conversion paths without unnecessary redundancy.
The tool surface covers the full user journey: learning through articles, verifying eligibility through service area, running the repair-or-replace analysis, and taking action via booking or lead submission. For a read-mostly decision tool and lead generation server, there are no meaningful dead ends.