housecall-pro-mcp

by tedmcfadden

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action combination (e.g., list_customers vs. get_customer, list_invoices vs. list_job_invoices). The descriptions clearly differentiate similar-sounding tools, so an agent can reliably select the correct one.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., list_customers, create_estimate, convert_lead, preview_invoice). Even the longer names like bulk_update_estimate_option_line_items adhere to this pattern, making the naming predictable and uniform.
Tool Count3/5
With 23 tools, the server falls into the 'borderline heavy' range (16-25). While the tools cover a wide range of Housecall Pro features, the count is higher than the typical well-scoped server, and some tools (e.g., get_company, list_employees) are single-purpose, contributing to the total.
Completeness3/5
The tool set provides robust read and create capabilities for customers, jobs, estimates, invoices, and leads, but notable gaps exist: there are no update operations for jobs (except schedule), estimates, or leads, and no delete operations at all. Invoices are read-only, which may be acceptable but limits full lifecycle management.
Average 3.6/5 across 23 of 23 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only restates the operation ('Get a single job by ID') without mentioning response format, error conditions, authentication, or side effects (none). This adds no value beyond the tool's name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with a doc link, front-loaded with the core action. No wasted words, and the link offers additional reference without cluttering the text.
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 get-by-id tool with one parameter and no output schema, the description is minimal but sufficient to invoke correctly. However, it does not explain what the response contains or any error handling. The doc link partially compensates for the lack of return-value detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no new meaning beyond the schema—'by ID' simply mirrors the job_id parameter description. No extra context or format details are provided.
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 'Get a single job by ID', which specifies the verb (get), resource (job), and the identifying parameter. It distinguishes from list_jobs by implying a single item fetch, though it doesn't explicitly name the alternative.
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 gives no explicit when-to-use or exclusions. It says 'by ID', implying it's for a known job ID, but does not mention alternatives like list_jobs for fetching multiple jobs or when to prefer this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only mentions 'paginated', which is minimal. It does not state whether the operation is read-only, requires authentication, what the response format is, or any side effects. 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 sentence that is front-loaded and to the point. It conveys the core purpose without extraneous information, and the docs link is a useful addition without being verbose.
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 has 5 parameters all described in the schema, no output schema, and a docs link, the description is minimally adequate for a simple list endpoint. However, it lacks details about return structure, alternatives, and any limitations. The docs link provides external context but the description itself is relatively sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter meaning beyond what the schema already provides. The extra_query parameter is well-documented in the schema but not 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 lists or searches invoices, using a specific verb and resource. It does not explicitly distinguish from sibling tools like list_job_invoices or get_invoice, but the purpose is unambiguous.
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 any exclusions, prerequisites, or scenarios where a different tool should be used. The only hint is the name 'list_invoices', but that is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose whether the preview is read-only, what it returns, or any prerequisites. The 'preview' wording implies a read operation but lacks explicit safety or side-effect 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 one concise sentence plus a documentation link. It front-loads the core purpose with no wasted words, though the docs link adds useful reference.
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 one-parameter tool, the description is minimal but sufficient to understand the basic function. However, it lacks usage context and behavioral details, and given the similar sibling get_invoice, more differentiation would be valuable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes invoice_uuid as 'Invoice UUID.' The description reinforces the UUID usage but adds no new semantic information. With 100% schema coverage, baseline 3 is appropriate.
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 gets a customer-facing preview of an invoice by UUID. This distinguishes it from sibling tools like get_invoice, though it doesn't explicitly name the difference.
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 get_invoice or list_invoices. The description simply states the action without context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions 'paginated' as behavioral detail, omitting read-only safety, auth requirements, rate limits, and response format. The docs link may help, but the description itself is sparse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the primary purpose, followed by a useful docs link. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description is incomplete. It does not state return value structure, default page size, or sort field options, leaving an agent under-informed. The docs link compensates somewhat, but the description itself is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds the hint of 'search' which maps to extra_query, but does not meaningfully extend beyond the schema's own detailed parameter descriptions.
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/search') and resource ('customers'), and the pagination note distinguishes it from single-customer retrieval via get_customer. However, it lacks explicit scope details like filters or whether all customers are returned.
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 paginated list/search framing implies use when multiple customers are needed, but there is no explicit guidance on when to use this tool versus alternatives like get_customer or list_jobs. No exclusions or alternative recommendations are provided.
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?
There are no annotations, so the description bears full responsibility for behavioral disclosure. It states the tool is paginated, but does not describe the return format, whether it is read-only, response structure, or any rate limits. This is minimal for a tool that lists potentially many estimates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 'List/search estimates, paginated,' followed by a docs link. It is concise and front-loaded, with no redundant words. The docs link provides additional reference without cluttering the description.
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?
The tool has no output schema, yet the description does not explain what the response contains (e.g., estimate objects, fields, pagination metadata). The docs link is provided, but the description alone is insufficient for an agent to know what to expect. Given the complexity of the extra_query parameter shape, more context would be valuable.
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?
All five parameters have descriptions in the schema (100% coverage), so the description doesn't need to add parameter details. The description's mention of 'search' aligns with the extra_query escape hatch but adds no specific parameter semantics. Thus, the schema itself carries the parameter documentation.
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 states 'List/search estimates, paginated,' which clearly identifies the tool's action (list/search) and resource (estimates), distinguishing it from other list tools for different resources. It also mentions pagination, which is a key feature. This is specific and not a tautology.
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_estimate for retrieving a single estimate. It does not mention any prerequisites, exclusions, or scenarios where this tool is preferred. The only usage hint is the verb 'search,' which implies filtering, but no explicit alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It reveals that the body is passed straight through and instructs to confirm field names, but it doesn't disclose authentication requirements, idempotency, error behavior, or response format. The 'Create' verb implies mutation but lacks deeper behavioral detail.
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 a link, front-loaded, and free of fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but lacks return-value info and usage context. The docs link helps, but the description doesn't explain what the API returns or how to handle errors, and it doesn't address when to prefer this over sibling lead tools.
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 already covers the body parameter well, including that it is raw JSON and to match docs. The tool description adds a docs link and repeats the 'matching fields' instruction. Since schema coverage is 100%, baseline is 3; the description doesn't add significant new meaning.
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 'Create a new lead' with a specific verb and resource. It doesn't explicitly distinguish from sibling tools like create_customer or convert_lead, but the purpose is unambiguous.
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 gives no guidance on when to use this tool versus alternatives like list_leads or convert_lead. It only states the action and points to docs, so the agent must infer usage from the name.
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?
There are no annotations provided, so the description carries the full burden of disclosing behavioral traits. It only says 'Get a single estimate by ID' without mentioning return format, error handling, permissions, rate limits, or any side effects. The docs link is a reference but does not enrich the description with 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 one concise sentence that front-loads the core purpose. The docs link is appended without cluttering the main statement. Every word earns its place; there is no redundancy or filler.
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?
This is a simple get-by-ID tool with a single fully documented parameter, but there is no output schema and no annotations. The description does not explain what the response contains (e.g., full estimate object fields) or any edge-case behaviors, which leaves some gaps for the agent. However, for a basic read operation, the description is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the only parameter (estimate_id) as 'Housecall Pro estimate ID' with 100% coverage, so the description adds no additional semantic value beyond that. The description's mention of 'by ID' reiterates what the schema provides, meeting the baseline but not exceeding it.
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 'Get a single estimate by ID' clearly states the action (get), resource (estimate), and scope (single by ID), distinguishing it from list_estimates which would retrieve multiple records, and from create_estimate which creates.
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_estimates or create_estimate. It does not mention any prerequisites, exclusions, or alternative contexts. The only implied usage is that you must have an ID, but this is not explicitly 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?
With no annotations, the description must bear the full burden of behavioral disclosure. It only says 'Update a job's scheduled window / assigned employees' and points to external docs, but it does not disclose side effects, permission requirements, reversibility, or what happens to unsupported fields. The agent is left reliant on the linked documentation for critical 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a docs link, with no wasted words. It front-loads the core purpose, though it is arguably too sparse to stand alone. The structure is clean and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has moderate complexity (a raw JSON body) and no output schema or annotations. The description covers basic purpose and provides a docs link, but it omits return-value details, error scenarios, and any side effects. It is not fully self-contained, though the docs link partially mitigates this gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides detailed descriptions for both parameters, including that `body` is a raw pass-through object. The description adds minimal value by naming 'scheduled window / assigned employees' as the body's content, but this is not essential given the schema's high coverage. The description does not introduce new parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and the resource ('a job's scheduled window / assigned employees'), making it distinct from sibling tools like update_customer or create_job. It provides specific scope without ambiguity.
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 this tool is for schedule updates but does not explicitly state when to use it vs alternatives (e.g., get_schedule_windows). There is no mention of prerequisites, exclusions, or fallback tools, so guidance is only implicit through the stated purpose.
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 responsibility for disclosing behavioral traits. It says to provide a body matching Housecall Pro's bulk_update fields and links to docs, but it does not disclose whether the update replaces existing line items, whether it is destructive, what permissions are required, or what the response format is. The description is too sparse to inform the agent about side effects.
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 concise and front-loaded: it states the core action in the first sentence and then directs to the docs for details. No unnecessary words or repetition. It is appropriately sized for 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 mutation behavior, lack of annotations, and absence of an output schema, the description should provide more context. It does not explain whether the update is additive or replacement, what response to expect, or any prerequisites. The docs link partially compensates, but the description alone is insufficient for reliable autonomous use without external lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by referencing the docs link and explicitly stating that the body must match Housecall Pro's bulk_update fields, giving crucial context for building the body parameter beyond the schema's generic 'Raw JSON request body' description. This extra guidance justifies a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Bulk-update' and clearly identifies the resource: 'line items on one option of an estimate.' This clearly distinguishes it from sibling tools that operate on whole estimates or customers. The purpose is unmistakable and immediately actionable.
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 states what the tool does but provides no explicit guidance on when to use it versus alternatives. Usage is implied by the function name and description (i.e., when you need to bulk-update line items on an estimate option), but no exclusions or comparisons to sibling update tools are mentioned. This is minimally acceptable.
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?
There are no annotations, so the description carries full responsibility for behavioral disclosure. It does not mention side effects such as whether the lead status changes, whether this is irreversible, or what the response contains. It only vaguely points to docs, but does not describe the conversion behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loading the purpose and including a direct link to documentation. Every sentence is useful and there is no unnecessary filler.
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 conversion operation with no annotations and no output schema, the description is incomplete. It does not explain what the expected response looks like, what prerequisites exist (e.g., lead must be in convertible state), or any error conditions. The schema and docs link help but the description alone leaves significant gaps.
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%, and the schema already explains that `body` is a raw request body matching Housecall Pro docs and that `lead_id` is a lead ID. The tool description adds little beyond the schema, only noting to 'Provide body matching Housecall Pro's convert fields,' which is redundant with the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Convert an existing lead into an estimate or a job,' naming the specific action (convert) and resource (lead) and the result (estimate or job). This distinguishes it from sibling tools like create_estimate or create_job, which create from scratch rather than converting an existing lead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this is for existing leads, implying it should be used when you have a lead_id and want to transform it into a quote or work order. It does not explicitly mention when not to use it or name alternatives, but the 'existing lead' context is sufficient to differentiate from creation 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states 'Get a single lead by ID' without addressing error handling, not-found behavior, permissions, or response format. This is a minimal disclosure that leaves important operational details unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a documentation link, immediately front-loaded with the action and resource. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get operation, the description is adequately complete for an agent to select and invoke the tool correctly. It states the purpose and access method clearly, and the schema covers the parameter. The lack of an output schema and behavioral details is a minor gap, but the tool's simplicity and the provided docs link mitigate this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes lead_id as 'Housecall Pro lead ID' with 100% coverage, so the baseline is 3. The description adds no extra meaning beyond 'by ID', leaving the schema to carry the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'single lead' and access method 'by ID', which clearly distinguishes it from sibling tools like list_leads or create_lead. It is unambiguous about what the tool does.
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 for fetching a specific lead by its ID, but it does not explicitly state when to prefer this over list_leads or provide any exclusions. No direct comparison with alternatives is given, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only implies a read operation ('Get') and mentions no auth, rate limits, response format, or pagination. The docs link is external but not inline disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: one for purpose, one for parameter usage, plus a useful docs link. No redundancy or fluff.
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 getter with one optional parameter and no output schema, the description is adequate but lacks explicit response structure, pagination, or error behavior. The docs link helps mitigate but does not fully compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the parameter, but the description adds specific filter types (date-range/employee) beyond the schema's example (start_date/end_date), enriching parameter understanding.
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 'Get company schedule availability windows' uses a specific verb and resource, clearly distinct from siblings like get_company or list_jobs. It states exactly what the tool does.
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 advises using extra_query for date-range/employee filters, which is useful but parameter-level guidance. It does not explicitly state when to choose this tool over alternatives or when not to use it, though no direct sibling serves the same purpose.
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 disclosing behavior. It states the result is 'paginated', which is a useful behavioral trait. However, it does not mention whether the operation is read-only, the default sorting or filtering behavior, or any potential side effects. The docs link offers more detail but the description itself is thin on operational 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 concise sentence: 'List employees/techs, paginated.' followed by a docs link. Every element earns its place, with no redundant information. It is front-loaded with the core purpose and efficiently directs to external docs for details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple list tool but leaves gaps. It does not describe return values (no output schema exists), mention filtering/sorting capabilities beyond pagination, or note any constraints. The docs link partially compensates, and the schema covers parameter details, but the description alone gives only a minimal understanding of the tool's full functionality.
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 parameters are fully documented in the schema. The description adds only the word 'paginated', which implicitly relates to page and page_size parameters, but this adds no new semantic value beyond what the schema already provides. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List employees/techs' with the verb 'List' and the specific resource 'employees/techs', which distinguishes it from sibling tools like list_customers or list_jobs. The addition of 'paginated' further clarifies the scope and behavior, making the purpose unambiguous.
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 implied usage is to retrieve employees or techs when a list is needed. However, there is no explicit guidance on when to use this tool versus alternatives, and no exclusions or prerequisites are mentioned. The description relies on the tool's name and simple purpose, which provides basic context but lacks comparison with siblings.
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. It only restates the operation without disclosing any behavioral details such as response format, pagination, ordering, authorization requirements, or error behavior. The link to external docs is not part of the description's disclosed behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a documentation link, with no redundant words. It is front-loaded and efficient, earning a top score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description is quite terse. It omits behavioral context like pagination, ordering, or required scopes, and relies on external docs. While adequate for a minimal viable description, it has clear gaps in self-contained completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage and describes job_id as 'Housecall Pro job ID.' The description adds no further meaning beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'invoices', and the scope 'for a specific job'. This distinguishes it from sibling tools like list_invoices (which presumably lists all invoices) and get_invoice (which retrieves a single invoice).
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 when invoices need to be filtered by job, providing clear context. However, it does not explicitly name alternatives or exclusions, so it misses the full 'when not to use' guidance.
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. It only states the operation is an update and defers to external docs. It does not explain partial vs. full update semantics, whether omitted fields are cleared, required permissions, validation behavior, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and includes a direct documentation link. Every word earns its place without being verbose.
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 schema fully documents the two parameters and a documentation link is provided, the tool is minimally viable. However, there is no output schema and no mention of return values, error handling, or update behavior beyond the docs link, leaving meaningful gaps for an agent deciding or invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters have clear descriptions: customer_id is the Housecall Pro ID, and body is the raw JSON request body with a warning to confirm field names. The tool description itself adds little beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing customer', which is a specific verb and resource. It unambiguously distinguishes this from sibling tools like create_customer, list_customers, and get_customer.
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 phrase 'Update an existing customer' provides clear context for when to use the tool. It does not explicitly mention alternatives, but the purpose is obvious given the sibling tool names and the description implicitly excludes creation and read-only operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. 'Get' clearly indicates a read-only operation, which is the primary safety signal. However, it does not disclose response format, error behavior (e.g., 404 for non-existent ID), or authentication requirements. The docs link is referenced but not expanded upon.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing the essential information: what it does and the identifying parameter. It includes a documentation link for further reading without unnecessary verbosity. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description is largely sufficient. It names the action and the key. It could be improved by noting the return type (e.g., 'Returns full customer object') or error handling, but the simplicity of the operation reduces the need. The docs link compensates for missing details.
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 provides 100% coverage with customer_id described as 'Housecall Pro customer ID.' The description adds no additional parameter context. According to the baseline, since schema coverage is high, a score of 3 is appropriate without needing description compensation.
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 'Get a single customer by ID' uses a specific verb (get), resource (customer), and scope (single by ID), clearly distinguishing it from list_customers (which retrieves multiple) and create/update_customer (which modify). This matches the high standard of specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific customer_id is known, but does not explicitly mention alternatives like list_customers for searching or create_customer for adding. The phrase 'by ID' hints at the prerequisite, but there is no direct when-to-use or when-not-to-use guidance.
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. It only restates the read operation ('Get') and does not disclose potential errors, authentication requirements, response structure, or behavior when the UUID is invalid. This is minimal transparency beyond the purpose itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a useful documentation link. There is no fluff or redundant detail, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read tool with no output schema and no annotations, the description is adequate: it identifies the resource and the lookup key, and the docs link supplements missing details. The return value is predictable from the name and verb, so it does not need extensive explanation.
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 has 100% coverage for its single parameter, which is described as 'Invoice UUID.' The description adds no extra meaning beyond saying 'by its UUID', so the schema already carries the semantic weight. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'single invoice' and the identifier type 'UUID', making it clear this tool fetches one invoice as opposed to listing invoices. It clearly distinguishes from sibling tools like list_invoices and list_job_invoices.
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 states it retrieves a single invoice by UUID, which clearly implies use when you already have the invoice UUID. It does not explicitly mention alternatives or exclusions, but the context is clear enough for a simple getter.
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?
No annotations are provided, so the description carries the full burden. It indicates a mutating operation ('Create') and discloses that the request body is passed straight through to Housecall Pro, with a link to the official docs for field names. However, it doesn't disclose response format, error behavior, or any required authentication or permissions, leaving some uncertainty about side effects.
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: the first states the purpose, the second gives the key usage instruction and a direct docs link. It's front-loaded, concise, and every sentence earns its place with no wasted words.
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?
While the schema covers the parameter well and the docs link provides field details, the description lacks information about the return value, potential side effects, or any prerequisites. For a create operation with no output schema and no annotations, an agent would benefit from knowing what to expect in the response. The docs link compensates partially, but the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single 'body' parameter, with a detailed description explaining it's raw JSON and points to the docs. The tool description adds little beyond the schema, reiterating the same info and providing the docs URL. Since the schema already carries the meaning, the description adds marginal value, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new customer' with a specific verb and resource, distinguishing it from sibling tools like update_customer and list_customers. The purpose is unambiguous and directly usable by an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool—creating a new customer—and instructs the agent to provide a body matching the documented fields. It doesn't explicitly mention exclusions or alternatives, but the purpose is clear enough that an agent won't confuse it with update or list operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool lists (a read operation) and is paginated, but does not specify return structure, authentication requirements, rate limits, or other side effects. This is minimal but 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 concise sentence that front-loads the action and resource, followed by a helpful docs link. Every word earns its place; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a listing tool with five parameters and no output schema, the description is adequate but sparse. It does not explain what is returned (e.g., an array of lead objects) or how search filters are applied, relying on the docs link. The schema covers parameters, but the return format and search behavior are ambiguous.
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 five parameters. The description adds no additional parameter meaning beyond hinting at search via 'search', which is also covered by the extra_query parameter. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List/search') and the resource ('leads'), and notes pagination. This distinguishes it from sibling tools like get_lead (single lead), create_lead, and convert_lead, which perform different operations.
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 use for listing or searching leads with pagination, providing clear context. However, it does not explicitly mention alternatives like get_lead for individual leads or exclude any use cases, so it is clear but lacks explicit exclusions.
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 transparency burden. It states the core behavior (creation) and directs the user to external docs for field specifics. However, it does not disclose return values, error handling, or side effects beyond the obvious 'create' implication, so it only meets the minimum bar.
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 remarkably concise: two sentences that state the purpose and provide a direct link to authoritative documentation. Every sentence earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and no output schema, the description is quite complete: it tells the agent what to do, where to find the exact fields, and provides a docs link. The only gap is lack of return value info, but the schema and the link to docs compensate sufficiently for an agent to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a thorough description of the 'body' parameter, including that it is a raw JSON request body, matches Housecall Pro's docs, and is passed straight through. The tool description merely repeats the need to match fields, adding no new conceptual information beyond what the schema covers, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new estimate', which is a specific verb+resource combination. This clearly distinguishes it from siblings like get_estimate and list_estimates, leaving no ambiguity about what action it performs.
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 phrase 'Create a new estimate' clearly implies when to use this tool: when the agent needs to create an estimate. It does not explicitly list alternatives or exclusion cases, but the purpose is obvious enough that an agent can correctly select it among siblings without further guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It implies authentication ('authenticated account') but doesn't state whether the operation is read-only, possible error conditions, rate limits, or the exact content of the returned profile. This limited disclosure leaves significant gaps for an agent deciding whether to invoke the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the action and target, followed by a documentation link. It is concise, front-loaded, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description sufficiently states what is retrieved ('company profile') and provides a docs link for more details. While the return structure isn't detailed, the low complexity and absence of schema make the description reasonably complete.
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 zero parameters, and the schema coverage is 100% (trivially). Per the rubric, a 0-parameter tool gets a baseline of 4. The description adds no parameter info because none exists, and none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and clearly identifies the resource as 'the authenticated Housecall Pro account's company profile.' This distinguishes it from siblings like get_customer or get_estimate, which target different entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this tool retrieves the company profile of the authenticated account. While it doesn't explicitly mention alternatives or when not to use it, the specific resource makes the intended usage obvious, satisfying the 'clear context, no exclusions' criterion.
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 pagination behavior and provides a docs link for further detail, but does not state read-only nature, response format, or any rate limits. The minimal transparency is adequate for a list operation but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a docs link. It is front-loaded with the core purpose, followed by a filter hint, and ends with a reference link. Every sentence earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 5 parameters, nested extra_query, and lack of output schema, the description provides essential usage context: pagination, filters, and a docs URL for exact parameters. It does not describe the response shape, but the word 'list' implies an array of jobs, and the docs link fills gaps. This is reasonably complete for a list 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?
Schema description coverage is 100%, so baseline is 3. The description adds value by giving concrete examples for extra_query (customer_id, employee_ids, work_status, scheduled_start_min/max), with scheduled_start_min/max not already in the schema. This helps agents understand how to construct filters.
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 states 'List/search jobs, paginated' which clearly identifies the verb (list/search), resource (jobs), and scope (paginated). This distinguishes it from sibling tools like get_job (single job) and list_estimates (different resource).
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 gives specific guidance on using extra_query for filters, but does not explicitly compare to alternatives like get_job or state when not to use this tool. Usage context is implied by 'list/search', but no exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the body fields and links to docs, but does not disclose side effects, authentication requirements, rate limits, or response format. This is acceptable for a simple create operation but lacks deeper 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 two sentences, front-loaded with the purpose, and includes a doc link. Every sentence earns its place with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex body parameter and no output schema. The description links to official docs for field details, but does not describe the response or error behavior. This is sufficient for basic use but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a descriptive text. The tool description adds example field names (customer_id, addresses, schedule, line_items), providing extra semantic context beyond the schema's generic 'Raw JSON' description.
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 'Create a new job', which is a specific verb and resource. It distinguishes from sibling tools like create_estimate or create_customer by explicitly naming the target resource.
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 makes the use case obvious: you use this to create a job. It provides clear context but does not explicitly contrast with alternatives or mention when not to use it.
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:

[![housecall-pro-mcp MCP server](https://glama.ai/mcp/servers/tedmcfadden/housecall-pro-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tedmcfadden/housecall-pro-mcp)

Score Badge

Copy to your README.md:

[![housecall-pro-mcp MCP server](https://glama.ai/mcp/servers/tedmcfadden/housecall-pro-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tedmcfadden/housecall-pro-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tedmcfadden/housecall-pro-mcp'

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