Skip to main content
Glama
Steven3265

Homechecker Guides MCP

Homechecker Guides MCP

Smithery

Homechecker's professionally authored guides for Australian homebuyers, served over the Model Context Protocol and a set of complementary machine-readable interfaces. A connected assistant can search the corpus, retrieve canonical guides and build sourced buyer checklists across inspections, contracts, strata, construction eras, disclosure and maintenance, citing homechecker.com.au throughout.

Public, read-only and deliberately separated from customer and assessment systems.

The service exposes the current Homechecker guide system without connecting to the Moyne Ross portal, Supabase, customer records, payments, uploaded documents or the Homechecker assessment engine.

Version: 1.2.1 · Protocol: MCP 2026-07-28 with stateless 2025-era compatibility · Live endpoint: https://mcp.homechecker.com.au/mcp · Health: mcp.homechecker.com.au/health · Official Registry: io.github.Steven3265/homechecker-guides · Connect it: homechecker.com.au/ai

Machine discovery surface

Homechecker publishes one deterministic guide corpus through several interoperable discovery and execution surfaces.

  • MCP: https://mcp.homechecker.com.au/mcp

  • MCP Server Card (experimental extension): https://mcp.homechecker.com.au/mcp/server-card

  • Extended Homechecker service metadata: https://mcp.homechecker.com.au/server-card.json

  • Read-only REST API: https://mcp.homechecker.com.au/v1/*

  • OpenAPI 3.1: https://mcp.homechecker.com.au/openapi.json

  • ARD catalogue: https://homechecker.com.au/.well-known/ard.json

  • Agent Skills: skills/*/SKILL.md

  • Homechecker llms.txt: https://homechecker.com.au/llms.txt

  • Guide RSS feed: https://homechecker.com.au/guides/feed.xml

  • Machine-readable guide export: https://homechecker.com.au/guides/export.json

  • Claude plugin package: .claude-plugin/plugin.json + .mcp.json

  • GitHub Copilot plugin package: .github/plugin/marketplace.json

  • OpenAI distribution package: distribution/openai/homechecker/

  • GitHub Agent Finder contribution pack: distribution/github-agentfinder/

The repository is also a portable Agent Plugins 1.0.0 package. plugin.json identifies the package, skills/ contains the open Agent Skills, and mcp.json points compatible clients to the hosted Streamable HTTP MCP server.

These are adapters around one knowledge system, not separate versions of Homechecker. The canonical editorial corpus remains on homechecker.com.au, the MCP serves a deterministic snapshot of that corpus, and every machine interface ultimately resolves to the same retrieval core and canonical source URLs.

Related MCP server: proofrelay

Ecosystem listings

Homechecker Guides is independently indexed across the emerging MCP ecosystem. These third-party listings may update on their own cadence.

The authoritative server identity remains io.github.Steven3265/homechecker-guides in the official MCP Registry, with the canonical live endpoint at https://mcp.homechecker.com.au/mcp.

Protocol foundation

Version 1.2.1 uses the MCP TypeScript SDK v2 server package and the 2026-07-28 protocol revision.

The official createMcpHandler entry provides stateless per-request serving, server/discover, modern MCP routing headers, server identity and cache fields while retaining stateless compatibility for 2025-era HTTP clients during rollout.

For modern Streamable HTTP requests, the SDK validates MCP routing headers against the JSON-RPC request and rejects mismatches. The bare fetch endpoint now also applies the SDK's Host and Origin validation helpers before protocol handling, including 403 rejection for a supplied Origin outside the allowlist. Every tool advertises both an input schema and an output schema for structuredContent. Application telemetry reads the Mcp-Method protocol header for operational method identification but does not parse the JSON-RPC body for logging.

The protocol shell can evolve independently of the durable parts of the product: the reviewed snapshot, deterministic retrieval, tool contracts and professional boundaries.

See docs/PROTOCOL-SUPPORT.md, docs/RELEASE-1.2.1.md and CHANGELOG.md.

Explore the Homechecker guides

What is included

  • 35 MCP resources: one machine-readable catalogue, the guide hub and 33 published guides.

  • 4 read-only MCP tools: catalogue listing, natural-language search, canonical guide retrieval and a deterministic buyer checklist.

  • Read-only HTTP adapters: REST endpoints exposing the same deterministic list, search, retrieval and checklist functions.

  • OpenAPI 3.1: a machine-readable description of the REST surface for clients that do not speak MCP.

  • Two discovery documents: the standards-track experimental MCP Server Card at /mcp/server-card contains identity and remote connection details only; /server-card.json retains richer Homechecker service metadata for compatibility and diagnostics.

  • 4 Agent Skills: portable workflows for Australian homebuyer due diligence, property documents, building-risk interpretation and home-ownership planning.

  • Two MCP transports: stateless remote Streamable HTTP at /mcp and modern/legacy-compatible local stdio.

  • A bundled content snapshot: rebuilt from Homechecker's public guide export at https://homechecker.com.au/guides/export.json. The repository needs no runtime access to the portal codebase.

  • A browser-triggered refresh workflow: Actions → Refresh guides snapshot regenerates, tests and opens a pull request. No local environment is required.

  • Canonical model-facing links: MCP-rendered text and canonicalUrl fields always use the clean Homechecker canonical URL. REST/WebMCP responses may add a separate referralUrl for attribution (homechecker-rest / homechecker-webmcp) without changing the URL an assistant is instructed to cite.

  • Privacy-minimised operational telemetry: application telemetry records operational fields such as MCP method, tool name, query length, coarse filters, counts, match strength, outcome and duration where applicable. Raw questions, session identifiers, IP addresses and identifying request-header values are not intentionally logged by the application. See docs/SECURITY.md.

  • Tests and retrieval evaluation: snapshot integrity, core search, release metadata, protocol, HTTP-adapter and official MCP conformance checks plus 199 retrieval cases, including an 85-query open-world collision suite.

Tools

list_guides

Lists published guide metadata.

Filters include jurisdiction, cluster, property type, construction era and buying stage.

search_guides

Searches the corpus from a natural-language homebuyer question.

It returns ranked guides, relevant sections, canonical URLs, review metadata and limitations. Questions about inspection fees can surface building and pest inspection costs, while questions about movement can surface the guide to structural and cosmetic wall cracks.

get_guide

Retrieves one guide by slug as a summary, selected sections or the full canonical markdown representation.

build_buyer_checklist

Builds a deterministic, sourced checklist from buyer context such as state, property type, era, buying stage and concerns.

It can draw from practical guidance such as how to read a building and pest report, arranging an inspection before auction, and buying an apartment with strata or owners-corporation exposure.

It does not assess an actual property. Its boundary text notes once that Homechecker provides an independent address-specific desktop read for $99 inc GST.

Read-only REST API

The REST surface provides ordinary HTTP access to the same deterministic functions for systems that do not use MCP.

List guides

GET https://mcp.homechecker.com.au/v1/guides

Search guides

GET https://mcp.homechecker.com.au/v1/search?query=what+should+i+check+before+buying+an+older+house

Retrieve a guide

GET https://mcp.homechecker.com.au/v1/guide?slug=reading-a-section-32

Build a checklist

GET https://mcp.homechecker.com.au/v1/checklist?jurisdiction=VIC&era=1950s-1970s

REST results preserve clean canonical Homechecker URLs and expose separately tagged referral URLs for attribution.

The complete contract is published at:

https://mcp.homechecker.com.au/openapi.json

Agent Skills

The canonical portable Skills live under skills/.

Australian Homebuyer Due Diligence

skills/australian-homebuyer-due-diligence/SKILL.md

Structures sourced residential-property due diligence before an offer, auction or contract becomes binding.

Australian Property Documents

skills/australian-property-documents/SKILL.md

Provides jurisdiction-aware workflows for understanding sale disclosure, contracts and strata or owners-corporation material.

Australian Building Risk Reader

skills/australian-building-risk-reader/SKILL.md

Helps an agent reason carefully about common Australian residential-building risks by era, construction and symptom without remotely diagnosing a property.

Australian Home Ownership Planner

skills/australian-home-ownership-planner/SKILL.md

Organises maintenance, records, renovation preparation and ownership planning using Homechecker guidance.

skills/ is the canonical source. Public and OpenAI distribution copies are synchronised from these files and release validation fails if the copies drift.

Discovery

Homechecker's first-party Agentic Resource Discovery catalogue is published at:

https://homechecker.com.au/.well-known/ard.json

It describes the Homechecker MCP and all four Agent Skills using domain-anchored identifiers and representative natural-language queries.

Homechecker's robots.txt also advertises the catalogue through:

Agentmap: https://homechecker.com.au/.well-known/ard.json

The same machine identity is reinforced through llms.txt, the guide RSS feed, OpenAPI, the standards-track experimental MCP Server Card, GitHub and the official MCP Registry.

Resources

  • homechecker://catalogue

  • homechecker://guides/index

  • homechecker://guides/<slug> for every published guide

Each guide resource includes the article, sources, review metadata, method, limitations and canonical Homechecker URL.

Deliberate boundaries

This service cannot:

  • access the Moyne Ross or Homechecker production database;

  • inspect a property or analyse a listing;

  • read customer documents or issued assessments;

  • call an AI model;

  • order or charge for a Homecheck;

  • write to any external system;

  • provide legal advice or replace a physical inspection.

The only runtime content dataset is data/guides.json.

Where general guidance is not enough, Homechecker offers an independent address-specific desktop read of the available records, imagery and documents, from $99 inc GST.

Privacy and security

The service is public, read-only and requires no authentication.

It does not have credentials for the Moyne Ross portal, Supabase, payments, customer files or assessment systems.

Application-level operational telemetry is deliberately minimised. It may record:

  • the MCP protocol method;

  • tool name;

  • query length rather than query text;

  • coarse filters;

  • result counts;

  • match strength;

  • request outcome;

  • duration.

The application does not intentionally log raw questions, session identifiers, IP addresses or identifying request-header values.

Infrastructure providers may maintain their own access and security logs independently of the application.

See docs/SECURITY.md and data/TERMS.md.

Local setup

Requirements: Node.js 22 or later.

npm install
npm test
npm run benchmark
npm run check
npx vercel dev

The remote MCP endpoint will be available at:

http://localhost:3000/mcp

Machine service information:

http://localhost:3000/
http://localhost:3000/health
http://localhost:3000/mcp/server-card
http://localhost:3000/server-card.json
http://localhost:3000/openapi.json
http://localhost:3000/v1/guides

For a local stdio client:

npm run build
npm run start:stdio

Example stdio client configuration:

{
  "mcpServers": {
    "homechecker-guides": {
      "command": "node",
      "args": ["/absolute/path/homechecker-guides-mcp/dist/src/stdio.js"]
    }
  }
}

Deploy to Vercel

This repository is configured as a standalone Vercel project.

  1. Create or use the repository containing this project.

  2. Import the repository into Vercel.

  3. Set the project's Node.js version to 22.

  4. Deploy without adding any application secrets.

  5. Attach mcp.homechecker.com.au to the project.

  6. Use https://mcp.homechecker.com.au/mcp as the remote MCP endpoint.

The root route publishes service metadata, /health confirms the bundled guide count, /mcp/server-card publishes the experimental MCP Server Card, /server-card.json retains the richer Homechecker service metadata document, /openapi.json describes the REST surface, and /v1/* provides read-only HTTP adapters.

The MCP endpoint validates both Host and any supplied Origin header before protocol handling. Server-to-server MCP clients normally omit Origin and continue to work without configuration. Browser origins for Homechecker, current Claude surfaces, ChatGPT and loopback MCP Inspector use are allowed by default. Vercel deployment, branch and project-production aliases are admitted from VERCEL_URL, VERCEL_BRANCH_URL and VERCEL_PROJECT_PRODUCTION_URL; extra hosts can be supplied through ALLOWED_HOSTS. ALLOWED_ORIGINS is an authoritative exact-origin override (scheme, hostname and effective port), while a concrete legacy ALLOWED_ORIGIN preserves its prior exact single-origin restriction. Wildcard Origin validation is deliberately not supported; a historical ALLOWED_ORIGIN=* falls back to the safe built-in allowlist.

Official MCP Registry

The registered server identity is:

io.github.Steven3265/homechecker-guides

Release publication is automated through:

GitHub → Actions → Publish to MCP Registry → Run workflow

The workflow installs dependencies, runs the release checks, authenticates with GitHub OIDC, publishes the current server.json metadata and verifies that the official Registry can resolve the Homechecker server.

Release versions are published to the official MCP Registry through the pinned GitHub OIDC publication workflow.

Updating the guides snapshot

The MCP does not fetch the live website at runtime. It serves a bundled snapshot rebuilt from the public export.

The Homechecker portal remains the editorial source of truth: publish or edit guides there, deploy, and the export updates automatically.

From the browser:

  1. Actions → Refresh guides snapshot → Run workflow.

  2. The workflow fetches https://homechecker.com.au/guides/export.json.

  3. It rebuilds data/guides.json and runs the validator, core tests and retrieval benchmark.

  4. If content changed, it opens a pull request.

  5. Merge the pull request and Vercel redeploys.

If nothing but the timestamp would change, the snapshot is left untouched and no pull request is opened.

One-time repository setting:

Settings → Actions → General → Allow GitHub Actions to create and approve pull requests

From a terminal, optionally:

npm run snapshot
npm run snapshot -- --url <export-url>
npm test
npm run benchmark

Validation

npm run validate:snapshot
npm run test:core
npm run benchmark
npm run check

The retrieval evaluation contains 199 cases across every published spoke, multi-state retention, jurisdiction isolation, legislation-title/ACT ambiguity, era-confidence regressions, weak/background questions, correct-empty off-topic questions and an 85-query open-world collision suite. The current calibration baseline is 91.1% top-1 recall, 100% top-3 recall, 100% weak/background handling, 100% correct-empty handling, 100% open-world safety, zero false-strong negatives (0/109) and zero jurisdiction leakage (0/13 leakage probes).

This is an internal retrieval benchmark, not an independent assessment of legal or technical accuracy.

Release validation also checks machine-distribution metadata and ensures derived Skill copies remain identical to the canonical skills/ source.

Repository map

api/
  index.ts                 service metadata
  mcp.ts                   Streamable HTTP MCP endpoint
  health.ts                health and snapshot status
  mcp-server-card.ts       experimental MCP Server Card (identity + remote connection)
  server-card.ts           extended Homechecker service metadata
  openapi.ts               OpenAPI 3.1 description
  v1/                      read-only REST adapters

src/
  identity.ts              canonical server/protocol identity
  core.ts                  deterministic search and checklist logic
  server.ts                MCP tools, resources and operational telemetry
  http-handler.ts          REST adapter over the deterministic core
  http-json.ts             shared HTTP/CORS/attribution helpers
  stdio.ts                 local stdio entry

skills/                    canonical portable Agent Skills
public/skills/             public synchronised Skill copies
distribution/
  openai/homechecker/      OpenAI Skills/plugin submission package
  github-agentfinder/      GitHub Agent Finder contribution records

.claude-plugin/            Claude plugin metadata
.github/plugin/            GitHub/Copilot plugin metadata
.github/workflows/         validation, refresh and Registry publication
plugin.json                Agent Plugins package manifest
mcp.json                   Agent Plugins MCP dependency
.mcp.json                  Claude-compatible MCP configuration

data/guides.json           bundled canonical guide snapshot
data/TERMS.md              editorial corpus terms
data/benchmark.json        retrieval benchmark cases

scripts/                   snapshot, Skill sync, validation and benchmarks
docs/                      architecture, protocol, security and release notes
public/.well-known/        machine-readable security contact
vercel.json                production routing

Content and licence

The software and configuration code are MIT-licensed under LICENSE.md.

The Homechecker editorial corpus, including data/guides.json and guide material reproduced elsewhere in this repository, remains © Steven McCormack, trading as Moyne Ross, and is governed separately by data/TERMS.md.

Reasonable extracts may be quoted with attribution and a link to the canonical guide.

"Homechecker" and "Moyne Ross" are trading names used by Steven McCormack (ABN 18 890 160 412).

About the publisher

Homechecker is a residential guidance and assessment service operated by Steven McCormack (ABN 18 890 160 412), trading as Moyne Ross.

Homechecker · Guide library · AI & connector · Moyne Ross

Available Tools

4 tools
build_buyer_checklistBuild a Homechecker buyer checklistA
Read-onlyIdempotent
Inspect

Build a deterministic, sourced checklist from the Homechecker guide corpus for a buyer context. This assembles general questions and checks; it does not analyse a listing, document or actual building.

ParametersJSON Schema
NameRequiredDescriptionDefault
eraNoFor example 1950s-1970s or 2000s-on.
limitNo
concernsNo
buyingStageNoFor example research, before offer or auction, contract review, or physical inspection.
jurisdictionNoAustralia or a state/territory code or name, such as NSW, nsw or New South Wales.
propertyTypeNoFor example house, apartment, or townhouse or unit.

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, destructiveHint=false. The description adds value by clarifying 'deterministic' (reproducible output) and 'sourced' (grounded in guide corpus), and explicitly states it does not analyse a listing or building, which sets correct expectations about the tool's non-analytic nature. This adds meaningful context beyond the 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?

The description is compact - two sentences that front-load the core purpose ('deterministic, sourced checklist') and then add a clarifying disclaimer about scope. Every sentence 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.

Completeness3/5

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

The tool has 6 non-required params, no enums, and no output schema, making the description an important source of behavioral guidance. The description explains what the tool does at a high level but doesn't address how the parameters shape the output, what the return format is, or token/result expectations. It's adequate but leaves gaps for a parameter-rich, schema-poor 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 description coverage is 67% (4 of 6 params have descriptions). The description itself adds 'deterministic' and 'sourced' framing that clarifies the checklist is derived from guides rather than being free-form, but it doesn't elaborate on parameter interplay (e.g., how concerns, buyingStage, jurisdiction, or propertyType combine). With moderately good schema coverage, the baseline of 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 uses a specific verb ('Build') with a clear resource ('deterministic, sourced checklist from the Homechecker guide corpus') and context ('buyer context'). It distinguishes itself from sibling tools by explicitly noting it 'assembles general questions and checks' and does not analyse a listing, document or actual building, which separates it from search/retrieval siblings like list_guides and get_guide.

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 context: it's for building a general checklist from the guide corpus, and clarifies it does NOT analyse a listing/document/building. However, it does not name specific alternative tools or give explicit when-to-use vs when-not-to-use guidance beyond the negative statement about what it doesn't do. There's no comparison against list_guides or get_guide as alternatives.

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

get_guideGet a Homechecker guideA
Read-onlyIdempotent
Inspect

Retrieve one canonical Homechecker guide by slug. Use a slug returned by list_guides or search_guides. Returns source links, review metadata, method and limitations with the guide.

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesGuide slug, for example reading-a-section-32. Use guides for the main hub.
formatNofull
sectionIdsNoWhen format is sections, return only these section IDs.

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds the return-value context (source links, review metadata, method, limitations) which is useful. It doesn't address potential behaviors like slug-not-found errors, but with strong annotations, the added context meets baseline expectations.

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 two sentences and front-loaded with the primary purpose, immediately followed by the most critical usage hint (use a slug from sibling tools). It's efficient with no filler, though it could arguably be tightened slightly.

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 read-only retrieval tool with three parameters (one required), strong annotations, and clear schema documentation, the description provides adequate context: what's returned, how to source a slug, and the canonical nature of the guide. With no output schema, describing the return contents is helpful. Minor gaps like error handling aren't critical for this simple fetch 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 67%, with slug and sectionIds described in the schema. The description adds marginal value by mentioning the guide contains 'method and limitations' but doesn't elaborate on parameter semantics beyond the schema. The slug example and sectionIds behavior are already documented in the schema, so the description adds limited incremental value—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 'Retrieve one canonical Homechecker guide by slug' with a specific verb+resource+method of lookup. It distinguishes itself by noting it retrieves 'source links, review metadata, method and limitations.' However, it doesn't explicitly differentiate from search_guides—though the sibling names imply search vs retrieval, which is somewhat evident.

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 gives clear guidance to 'Use a slug returned by list_guides or search_guides,' which connects it to sibling tools and provides the correct workflow for obtaining a valid slug. It doesn't explicitly state when NOT to use this tool (e.g., when build_buyer_checklist is appropriate), but the slug-source guidance is practical and helpful.

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

list_guidesList Homechecker guidesA
Read-onlyIdempotent
Inspect

List the published Homechecker guide catalogue, optionally filtered by jurisdiction, guide cluster, property type, construction era, or buying stage. Returns metadata only.

ParametersJSON Schema
NameRequiredDescriptionDefault
eraNoFor example pre-1920s, 1950s-1970s, or 2000s-on.
clusterNo
buyingStageNoFor example research, contract review, physical inspection, ownership, or selling.
jurisdictionNoAustralia or a state/territory code or name, such as VIC, vic or Victoria.
propertyTypeNoFor example house, apartment, or townhouse or unit.
includePillarNo

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds value by noting it 'Returns metadata only', clarifying the content shape. However, it doesn't disclose whether includePillar alters return structure, pagination, or ordering. Bar is lower due to annotations; the metadata-only note adds modest 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?

A single, dense sentence that names all five filters and the metadata-only return. Efficient and front-loaded with the core purpose. Minor deduction for the trailing 'Returns metadata only' clause being behaviorally useful but slightly tangential to conciseness.

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?

Complexity is moderate (6 optional params, no required). No output schema exists, so the 'Returns metadata only' clarification helps. With read-only annotations and mostly-documented params, this is largely complete for a listing tool, though includePillar's meaning and search_guides differentiation would round it out.

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 67%, so most parameters already have descriptive examples in the schema (jurisdiction, buyingStage, era, propertyType). The description lists the filter dimensions, mirroring but not exceeding the schema. The includePillar parameter is undocumented in the schema and the description gives no meaning for it, leaving a 1-parameter gap. Baseline 3 is correct given high coverage.

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?

Specific verb+resource ('List...guide catalogue') clearly states what the tool does. The listed filter dimensions are explicit. However, it doesn't distinguish from sibling 'search_guides' — both appear to return guide lists, so without an explicit differentiator the purpose is clear but sibling differentiation is missing.

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 optional filtering by five dimensions, implying usage when a filtered catalogue is needed. But it does not clarify when to use list_guides vs search_guides vs get_guide, nor state any exclusions. No alternatives are named, so usage context is present but not differentiated.

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

search_guidesSearch Homechecker guidanceA
Read-onlyIdempotent
Inspect

Search professionally authored Australian homebuyer guidance using a natural-language question. Use this for general property, inspection, disclosure, apartment, condition, maintenance, era and buying-process questions. It does not assess an actual property.

ParametersJSON Schema
NameRequiredDescriptionDefault
eraNo
limitNo
queryYesThe homebuyer question or issue to search for.
clusterNo
buyingStageNo
jurisdictionNoOptional state/territory code or name, such as WA, wa or Western Australia.
propertyTypeNo

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety profile is covered by structure. The description adds useful behavioral context by noting it returns 'professionally authored' guidance and clarifying it does not assess actual properties — which reveals it's a knowledge retrieval tool rather than an evaluator. This is meaningful value beyond annotations, though it doesn't describe return format or ordering.

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?

Three sentences, zero waste. Front-loaded with the core purpose in the first sentence, usage in the second, and a critical limitation in the third. Every sentence contributes meaningful 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 search/retrieval tool with six optional filters plus one required query, the description effectively communicates when to use it and its fundamental limitation. The lack of an output schema and the large number of optional parameters make full completeness impossible without more param documentation, but the description covers the core decision points well enough for an agent to select and invoke correctly.

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 low (29%), with only query and jurisdiction having descriptions. The description adds context that query is a 'natural-language question' and clarifies it's general guidance, but doesn't elaborate on era, limit, cluster, buyingStage, or propertyType semantics beyond what the schema enum provides for cluster. The description's guidance about what question types it handles partially compensates, providing a baseline 3.

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 opens with a specific verb+resource ('Search professionally authored Australian homebuyer guidance') and clearly scopes the domain. It distinguishes itself from siblings by stating it handles general property/inspection/disclosure questions and notably clarifies 'It does not assess an actual property' — a key differentiator from property-specific tools.

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 lists specific question categories (property, inspection, disclosure, apartment, condition, maintenance, era, buying-process) giving clear when-to-use context. It doesn't explicitly name alternative sibling tools or state when-not-to-use, but the 'does not assess an actual property' exclusion is a strong implicit rejection for those needing property-level assessment, and individual parameters (cluster, jurisdiction) add contextual guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.0.1
    • First observedbuild_buyer_checklist
    • First observedget_guide
    • First observedlist_guides
    • First observedsearch_guides

TDQS

A4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: list_guides enumerates the catalogue, search_guides answers natural-language questions, get_guide retrieves a specific canonical guide by slug, and build_buyer_checklist assembles a deterministic checklist. There is no meaningful overlap or ambiguity between any pair of tools.

Naming Consistency5/5

All four tools follow a consistent verb_noun pattern (list_guides, search_guides, get_guide, build_buyer_checklist) with descriptive action verbs and their target object. The naming is fully predictable and uniform.

Tool Count5/5

Four tools is an appropriate, well-scoped set for a knowledge-documentation server covering catalogue browsing, search, retrieval, and synthesis. Each tool earns its place and there is no redundancy.

Completeness5/5

The surface covers the full lifecycle of interacting with the guide corpus: discover contents (list), query by question (search), retrieve details (get), and generate derived artifacts (build checklist). No obvious gaps for the stated purpose of a documentation/knowledge server.

Maintenance

ActivityActive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    F
    maintenance
    Read-only ProofRelay MCP verifier for non-confidential evidence bundles. Exposes 22 public-safe tools, 11 resources, and 11 prompts for bundle integrity checks, receipt-chain review, checkpoint recommendations, MCP risk metadata review, and real-estate closing proof-pack readiness.
    5
    MIT
  • A
    license
    A
    quality
    C
    maintenance
    Provides read-only access to iFixit repair guides, device information, repairability scores, categories, search, media, and contributor profiles via MCP tools.
    8
    BSD Zero Clause
  • F
    license
    Not graded
    quality
    C
    maintenance
    Provides read-only MCP tools to query building construction approval lifecycle data, covering project discovery, bidding, contracts, drawing review, permits, and completion records.
    1
    -