Skip to main content
Glama
hcpapi

io.github.hcpapi/housecall-pro-mcp

by hcpapi

hcp_render_report

Read-onlyIdempotent

Render findings into a self-contained offline interactive HTML report with sortable tables, severity-coded sections, and copy-back rows for clear review.

Instructions

Render a findings report into one self-contained, offline, interactive HTML file: sortable and filterable tables, severity-coded sections, collapsible worklists, selectable rows that copy back to chat, light and dark theme, print. This is a presentation tool: it makes no Housecall Pro call and takes findings you already have.

Pass a report contract. Required keys: skill, title, sections (an array). Each section has a title, an optional severity (confident|ok|warning|blocked|info|neutral), and blocks (an array). A block is one of: table ({columns:[{label,numeric?}], rows:[[cells]], selectable?, collapsedRows?, defaultSort?}), prose/lead ({html}), list ({items,crosses?}), subhead ({text}). Optional top-level keys: kicker, stats (cards), coverage, headline, order (suggested work), meta, generated, provenance, closing. In table cells and list items, `backticks` render as chips, **stars** as bold, and [text](https://...) as a link opening in a new tab (http/https only) - use it to link records to their pages in the owner's own dashboard. Keep money as display strings; exports and paste-backs show a link's text without the URL.

Where the report ends up depends on the client, and the response says which happened. On a client that displays reports inline (Claude and Claude Desktop), it opens in the conversation on its own and the response is a short confirmation - do not repeat the contents or save a file. Everywhere else the response carries the finished HTML: in Claude Code write it to a .html file and give the owner the path. On a contract error nothing renders and the exact problems are listed so you can fix and re-call.

Input Schema

NameRequiredDescriptionDefault
reportYesThe report contract object (see the description for its shape).
as_fileNoForce the standalone HTML file back even on a client that displays the report inline. Use only if the owner says nothing appeared.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.19.0
    • changedInput schema / additionalProperties
      Previous value: -falseNew value: +true
    • addedInput schema / properties / as_file
      Added value: +{
      +  "description": "Force the standalone HTML file back even on a client that displays the report inline. Use only if the owner says nothing appeared.",
      +  "type": "boolean"
      +}
  2. First observedv1.15.1

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover the safety profile (readOnly, idempotent, non-destructive, openWorld); the description adds substantial behavior beyond that — client-dependent output destination, the fact that the response states which path happened, no repo/network call, and validation-error behavior. This is well past the lowered bar set by annotations.

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?

Front-loaded with purpose before the contract, and nearly every sentence is load-bearing given the empty schema. It is dense and long, but the length is justified by the contract detail; only minor trimming would be possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description still explains what the response contains per client (short confirmation vs. full HTML), nested contract structure, enum values, and failure behavior. An agent has everything needed to build a valid call and interpret the result.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema's report object is effectively empty (additionalProperties only), so the description carries the full contract: required keys (skill, title, sections), section shape with the severity enum values, each block type with its fields, optional top-level keys, and inline markdown/chip/link parsing rules. This adds meaning far beyond the near-empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and artifact: render a findings report into one self-contained, offline, interactive HTML file, and enumerates the concrete features (sortable tables, severity sections, themes, print). It also explicitly separates itself from the sibling Housecall Pro tools by declaring 'it makes no Housecall Pro call and takes findings you already have.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when/when-not conditions: on inline-display clients do not repeat contents or save a file; in Claude Code write the returned HTML to a .html file and report the path. It also scopes the one optional parameter ('use only if the owner says nothing appeared') and describes the error path to re-call after fixing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.