CRM Health Doctor

A deterministic CRM reliability audit with three read-only WebMCP tools that let ChatGPT and humans co-review the same prioritized evidence on the page.

Comment

Inspiration

AI agents and CRM automation are only as reliable as the data they act on.

A CRM can appear operational while still containing missing ownership, stale deals, weak activity signals, or malformed fields that undermine routing, reporting, automation, and eventually agent behavior.

CRM Health Doctor started as a deterministic CRM reliability diagnostic: evaluate known conditions, calculate health scores, and produce a prioritized review queue rather than asking an LLM to guess what is wrong.

For the WebMCP Challenge, I wanted to explore a different question:

What if an AI agent and a human reviewer could inspect the same deterministic CRM evidence directly on the page, without giving the agent write access to the CRM?

That became the WebMCP human-agent co-review layer.

What it does

CRM Health Doctor evaluates a synthetic CRM dataset using explicit deterministic rules and produces:

  • an overall CRM health score
  • category-level scores
  • a prioritized issue queue
  • record-level evidence
  • deterministic review guidance

For the WebMCP Challenge, I extended that report with three browser-native, read-only tools:

  • get_crm_health_summary
  • list_priority_issues
  • explain_priority_issue

Instead of asking the agent to infer findings from visible HTML, the page exposes bounded structured state through WebMCP.

The most important interaction is the synchronization between agent and human. When the agent prioritizes or explains a record such as C-008, the corresponding row is automatically focused and highlighted on the report page.

This creates an observable co-review workflow where the agent and the human are reviewing the same evidence.

Who this is for

The immediate audience is CRM administrators, RevOps teams, and automation/AI practitioners preparing CRM systems for agent-assisted operations. These teams already depend on ownership, activity, lifecycle, and pipeline data for routing, reporting, automation, and AI workflows; unreliable CRM state makes every downstream system less trustworthy.

Why WebMCP changes the interaction

Without this WebMCP layer, the human can inspect the report visually while an agent must either infer state from the rendered interface or receive a separate backend integration. Here, the page itself exposes a governed structured interface to the agent and simultaneously shows the human which evidence the agent selected. The browser becomes a shared review surface rather than two disconnected experiences.

How I built it

The diagnostic layer is implemented in Python using deterministic normalization, rules, scoring, prioritization, and remediation mappings.

The generated report is a self-contained static HTML page containing safely embedded synthetic report state.

The WebMCP browser layer is implemented in JavaScript and registers three tightly scoped read-only tools. Tool inputs are validated, outputs are bounded, and CRM-derived strings are treated as untrusted evidence rather than instructions.

The architecture is deliberately simple:

Synthetic CRM fixture → Deterministic Python diagnostic engine → Precomputed safe report state → Static HTML report → WebMCP tools → Agent + human co-review

The public challenge deployment is hosted on Render as a static site. It requires no backend, database, authentication service, or live CRM connection.

CRM Health Doctor existed before the WebMCP Challenge. The pre-existing work includes the deterministic diagnostic engine, scoring logic, fixtures, and original report UI.

The challenge-period contribution adds:

  • structured WebMCP-safe report state
  • three browser-native read-only tools
  • strict tool input contracts
  • bounded structured outputs
  • deterministic remediation mappings
  • visible synchronization between agent selection and the report UI
  • graceful behavior when WebMCP is unavailable
  • public WebMCP deployment and validation

The repository includes explicit provenance documentation, a challenge-delta document, and a tagged pre-WebMCP baseline.

Challenges I ran into

Making agent behavior observable

Returning correct structured data was only part of the problem.

I wanted the human reviewer to see exactly what the agent was reasoning about. That required connecting tool execution to deterministic visual behavior on the page, including scrolling, row focus, highlighting, and an accessible status update.

Keeping the trust boundary narrow

It would have been easy to turn the demo into an autonomous remediation agent. I intentionally did not.

The public challenge version has:

  • no live customer CRM data
  • no CRM write path
  • no raw HubSpot record IDs
  • no network calls from the deployed page
  • strict tool inputs
  • bounded outputs
  • deterministic remediation guidance
  • explicit human-review requirements

Working with an evolving WebMCP environment

WebMCP is still evolving and browser behavior remains experimental.

I validated the implementation through both ChatGPT's in-app browser and a WebMCP-enabled Chrome build. During testing, I encountered a difference in how the experimental Chrome build expected tool arguments to be passed.

Rather than hiding that implementation detail, I documented the exact validated invocation flow in the public repository.

Accomplishments I'm proud of

I am most proud that the final challenge build is small, explainable, and observable.

The project successfully demonstrates:

  • three working WebMCP tools on a public deployment
  • deterministic CRM health evaluation
  • bounded structured agent access
  • visible synchronization between agent actions and the report UI
  • explicit human review instead of autonomous writes
  • validation in both ChatGPT and WebMCP-enabled Chrome
  • a reproducible synthetic demo with no customer data

The strongest moment in the demo is simple: the agent identifies C-008 as a priority issue, and the same record is immediately highlighted for the human reviewer.

That interaction is the core idea behind the project.

What I learned

The biggest lesson was that agent UX is not only about giving a model more context.

A stronger pattern is:

deterministic evidence → bounded tool → agent reasoning → visible human review

WebMCP makes the browser itself a useful coordination surface between the agent and the user.

Instead of asking an agent to scrape or visually interpret a dashboard, a page can expose exactly the structured state the agent is allowed to reason over while keeping consequential decisions under human control.

I also learned that deterministic systems and AI agents do not need to compete with each other.

Deterministic logic can establish the evidence and operating boundaries, while the agent provides interpretation and interaction on top of that trusted layer.

What's next for CRM Health Doctor

CRM Health Doctor is still a narrow prototype, not a production CRM auditing platform.

The next logical direction is an agent-readiness layer for CRM operations.

The broader workflow is:

CRM evidence → Deterministic reliability assessment → Prioritized review queue → Governed agent analysis → Human approval → Controlled remediation

Future work could include:

  • broader diagnostic coverage
  • authenticated multi-portal assessment
  • historical reliability trends
  • richer evidence sources
  • configurable policy thresholds
  • controlled remediation workflows with explicit approval gates
  • integration with CRM and operational MCP tools after reliability checks pass

The larger opportunity is not simply to let an AI agent operate a CRM.

It is to help determine when the CRM data and operating controls are reliable enough for an agent to act safely in the first place.

Built With

Share this project:

Updates

Submission history