Homechecker Guides MCP
{
"answer": "This is a read-only MCP server that lets you search and retrieve Homechecker's governed Australian residential-building guidance corpus — without touching customer records, property data, or the assessment engine. You can:\n\n- List the guide catalogue (list_guides): Browse published guide metadata, filterable by jurisdiction (e.g. VIC), guide cluster (how-to-buy, state-rules, read-building, shared-buildings, own-change), property type, construction era, or buying stage.\n- Search guides with natural language (search_guides): Ask a homebuyer question in plain language (e.g. about inspections, disclosures, conditions, maintenance, apartments, or the buying process) and get ranked guides, relevant sections, canonical URLs, review metadata, and limitations. Supports optional filters and a result limit of 1–10.\n- Retrieve a full guide by slug (get_guide): Pull one canonical guide as a summary, selected sections, or full markdown — including source links, review metadata, method, and limitations.\n- Build a deterministic buyer checklist (build_buyer_checklist): Assemble a sourced, general checklist (4–20 items) from the guide corpus based on buyer context like state, property type, construction era, buying stage, and specific concerns. This does not analyze an actual property or listing.\n\nAll tools are read-only, idempotent, and non-destructive — no access to production databases, customer documents, payments, or the assessment engine, and they do not call an AI model or write to external systems."
}
Provides a GitHub Copilot plugin package that exposes the Homechecker guide search, retrieval, and checklist capabilities within GitHub Copilot.
Provides an OpenAI distribution package for OpenAI-compatible agents to access the Homechecker guide corpus and its search, retrieval, and checklist tools.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Homechecker Guides MCPWhat should I check when buying a house in Victoria?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Homechecker Guides MCP
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/mcpMCP Server Card (experimental extension):
https://mcp.homechecker.com.au/mcp/server-cardExtended Homechecker service metadata:
https://mcp.homechecker.com.au/server-card.jsonRead-only REST API:
https://mcp.homechecker.com.au/v1/*OpenAPI 3.1:
https://mcp.homechecker.com.au/openapi.jsonARD catalogue:
https://homechecker.com.au/.well-known/ard.jsonAgent Skills:
skills/*/SKILL.mdHomechecker llms.txt:
https://homechecker.com.au/llms.txtGuide RSS feed:
https://homechecker.com.au/guides/feed.xmlMachine-readable guide export:
https://homechecker.com.au/guides/export.jsonClaude plugin package:
.claude-plugin/plugin.json+.mcp.jsonGitHub Copilot plugin package:
.github/plugin/marketplace.jsonOpenAI 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-cardcontains identity and remote connection details only;/server-card.jsonretains 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
/mcpand 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
canonicalUrlfields always use the clean Homechecker canonical URL. REST/WebMCP responses may add a separatereferralUrlfor 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/guidesSearch guides
GET https://mcp.homechecker.com.au/v1/search?query=what+should+i+check+before+buying+an+older+houseRetrieve a guide
GET https://mcp.homechecker.com.au/v1/guide?slug=reading-a-section-32Build a checklist
GET https://mcp.homechecker.com.au/v1/checklist?jurisdiction=VIC&era=1950s-1970sREST 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.jsonAgent 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.jsonIt 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.jsonThe 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://cataloguehomechecker://guides/indexhomechecker://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 devThe remote MCP endpoint will be available at:
http://localhost:3000/mcpMachine 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/guidesFor a local stdio client:
npm run build
npm run start:stdioExample 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.
Create or use the repository containing this project.
Import the repository into Vercel.
Set the project's Node.js version to 22.
Deploy without adding any application secrets.
Attach
mcp.homechecker.com.auto the project.Use
https://mcp.homechecker.com.au/mcpas 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-guidesRelease 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:
Actions → Refresh guides snapshot → Run workflow.
The workflow fetches
https://homechecker.com.au/guides/export.json.It rebuilds
data/guides.jsonand runs the validator, core tests and retrieval benchmark.If content changed, it opens a pull request.
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 benchmarkValidation
npm run validate:snapshot
npm run test:core
npm run benchmark
npm run checkThe 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 routingContent 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.
Available Tools
4 toolsbuild_buyer_checklistBuild a Homechecker buyer checklistARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| era | No | For example 1950s-1970s or 2000s-on. | |
| limit | No | ||
| concerns | No | ||
| buyingStage | No | For example research, before offer or auction, contract review, or physical inspection. | |
| jurisdiction | No | Australia or a state/territory code or name, such as NSW, nsw or New South Wales. | |
| propertyType | No | For example house, apartment, or townhouse or unit. |
TDQS
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.
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.
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.
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.
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.
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 guideARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Guide slug, for example reading-a-section-32. Use guides for the main hub. | |
| format | No | full | |
| sectionIds | No | When format is sections, return only these section IDs. |
TDQS
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.
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.
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.
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.
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.
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 guidesARead-onlyIdempotentInspect
List the published Homechecker guide catalogue, optionally filtered by jurisdiction, guide cluster, property type, construction era, or buying stage. Returns metadata only.
| Name | Required | Description | Default |
|---|---|---|---|
| era | No | For example pre-1920s, 1950s-1970s, or 2000s-on. | |
| cluster | No | ||
| buyingStage | No | For example research, contract review, physical inspection, ownership, or selling. | |
| jurisdiction | No | Australia or a state/territory code or name, such as VIC, vic or Victoria. | |
| propertyType | No | For example house, apartment, or townhouse or unit. | |
| includePillar | No |
TDQS
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.
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.
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.
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.
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.
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 guidanceARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| era | No | ||
| limit | No | ||
| query | Yes | The homebuyer question or issue to search for. | |
| cluster | No | ||
| buyingStage | No | ||
| jurisdiction | No | Optional state/territory code or name, such as WA, wa or Western Australia. | |
| propertyType | No |
TDQS
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.
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.
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.
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.
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.
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.
4 tool updates
v1.0.1- First observed
build_buyer_checklist - First observed
get_guide - First observed
list_guides - First observed
search_guides
TDQS
Scored across 4 tools
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.
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.
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.
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
Related MCP Connectors
Read-only Bicycle Guide registry: published guides, homes, taxonomy, capability spine. No auth.
Read-only Bicycle Guide registry: published guides, homes, taxonomy, capability spine. No auth.
Read-only Bicycle Guide registry: published guides, homes, taxonomy, capability spine. No auth.
Read-only Bicycle Guide registry: published guides, homes, taxonomy, capability spine. No auth.
Related MCP Servers
- AlicenseBqualityDmaintenanceEnables users to search and navigate over 22,500 indexed sections across 16 Canadian building codes and user guides. It supports keyword searches, hierarchy navigation, and optional full-text extraction from user-provided PDF documents.73MIT
- AlicenseAqualityFmaintenanceRead-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.5MIT
- AlicenseAqualityCmaintenanceProvides read-only access to iFixit repair guides, device information, repairability scores, categories, search, media, and contributor profiles via MCP tools.8BSD Zero Clause
- FlicenseNot gradedqualityCmaintenanceProvides read-only MCP tools to query building construction approval lifecycle data, covering project discovery, bidding, contracts, drawing review, permits, and completion records.1-