What can you do with this server?

This server lets an AI agent onboard a website for AnswerHatch's cite-or-refuse answer widget, entirely from chat. * Sign up or log in to an AnswerHatch account (answerhatch_signup, answerhatch_login), or use a pre-set token. * Register a domain and get proof-of-control options (answerhatch_create_tenant). * Start a crawl once control is proven, and retry if verification isn't visible yet (answerhatch_start_crawl). * Poll status and receive the embed snippet when the site is live (answerhatch_status). * Start a paid subscription and get a Stripe checkout link (answerhatch_subscribe).

How do I use answerhatch-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@answerhatch-mcp Add cited answers to docs.example.com" 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.

answerhatch-mcp

Official

by answerhatch

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

AnswerHatch MCP

License: MIT Node MCP

Put a cite-or-refuse answer box on your docs, from the chat where you already work. Ask your agent to add cited answers to a site and this server does the whole onboarding: register the domain, prove you own it (a DNS record, a file, or a homepage tag, whichever is easiest, and an agent with write access can place the file or tag itself), crawl the pages, and hand back a one-line embed. No dashboard, no operator.

What AnswerHatch is

AnswerHatch answers your visitors from your own published pages, links the source on every answer, and refuses when it has no source. It never invents an API parameter, an endpoint, or a wrong command.

Every "AI on your docs" tool optimises for always answering. For documentation that is the wrong default: a confidently wrong answer is not a bad chat, it is a broken integration and a support ticket. AnswerHatch is built the other way round.

Cite or refuse. Every answer carries the page it came from, or the widget declines and gives the reason. The refusal is a gate in the request path, not a line in a prompt that can be talked around.
No third-party model in the path. Your docs and your users' questions are processed on AnswerHatch's own machines. They do not transit OpenAI or any other model API.
A provenance registry. Every crawled document carries its source URL, the date it was fetched, and its hash, so a reviewer can audit exactly what the widget is allowed to say.

See it refuse a made-up question, live: https://answerhatch.com

Related MCP server: RAG MCP Server

Install

Requires Node 20 or newer.

Claude Code, one line:

claude mcp add answerhatch -- npx -y answerhatch-mcp

Any MCP client, config form:

{
  "mcpServers": {
    "answerhatch": {
      "command": "npx",
      "args": ["-y", "answerhatch-mcp"]
    }
  }
}

From source, to hack on it:

git clone https://github.com/answerhatch/answerhatch-mcp
cd answerhatch-mcp
npm install
claude mcp add answerhatch -- node /absolute/path/to/answerhatch-mcp/index.js

You need an AnswerHatch account. The agent can create one for you with answerhatch_signup, or sign up yourself at https://answerhatch.com (self-serve, a free trial) and use answerhatch_login. For non-interactive use, set ANSWERHATCH_TOKEN in the server's environment and skip both.

Use it

In your agent, just ask:

You:    Sign me up and add cited answers to docs.example.com
Agent:  (answerhatch_signup, then answerhatch_create_tenant)
        Account created. Prove control of docs.example.com by any one of a DNS
        record, a file, or a homepage meta tag. You have write access to the
        repo, so I'll drop in the file:
          docs.example.com/.well-known/answerhatch-challenge.txt  ->  ah-verify-...
        (commits the file and deploys)
Agent:  (answerhatch_start_crawl, then polls answerhatch_status)
        Verified by file. Live. Paste this into your site:
          <script async src="https://cdn.answerhatch.com/api/widget.js"
            data-agency="..." data-key="..." data-env="prod"></script>
You:    start a professional subscription
Agent:  (answerhatch_subscribe)
        Open this link to enter your card and start the 14-day trial:
          https://checkout.stripe.com/...

The tools enforce the order the API requires (register, prove control, then crawl) and each one tells the agent what to do next, so the agent drives the whole flow without you touching a console. Proof of control takes three forms, so the agent picks the one it can act on: a DNS TXT record, a file at /.well-known/answerhatch-challenge.txt, or a <meta name="answerhatch-verify"> tag on the homepage.

Tools

Tool	What it does
`answerhatch_signup`	Create a new account and sign in, so onboarding runs without leaving the agent. Use `answerhatch_login` instead if you already have one.
`answerhatch_login`	Sign in with email and password; holds the bearer token for the session. Skip it if `ANSWERHATCH_TOKEN` is set.
`answerhatch_create_tenant`	Register one domain and return three ways to prove control: a DNS TXT record, a well-known file, or a homepage meta tag. Any one is enough. The crawl does not start here.
`answerhatch_start_crawl`	Start the crawl once one proof is published. If none is visible yet, returns all three options again to retry.
`answerhatch_status`	Report lifecycle stage, pages crawled, and verification. When the site is live it returns the embed snippet.
`answerhatch_subscribe`	Start a paid subscription and return a Stripe checkout link. The card is entered on Stripe's page, never in the agent. 14-day free trial.

Security

The bearer token lives in memory for the session only. It is never written to disk, never logged, and it is scrubbed from tool output even if an API response tried to echo it back.

License

MIT. See LICENSE.

Available Tools

4 tools

answerhatch_create_tenantRegister a domainA

Register one domain and return its tenant id plus the DNS TXT record that proves the customer controls it. The crawl does not start here. Give the record to the user verbatim, wait for them to publish it, then call answerhatch_start_crawl. Call this once per site; if a crawl will not start, retry the crawl rather than registering again.

ParametersJSON Schema

Name	Required	Description	Default
`pages`	No	crawl budget in pages, default 120, maximum 2000
`domain`	Yes	bare hostname such as example.com, no scheme and no path

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses what it returns (tenant id and DNS TXT record), that it does not start crawling, and that it should be called only once. It doesn't cover error cases (e.g., duplicate domain) or side effects beyond registration, but the core behavior is clearly explained.

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, front-loaded with the primary action and outcome. Every sentence earns its place – the second sentence prevents a common misuse (starting crawl prematurely), the third enforces idempotency. Zero fluff.

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 2-parameter tool with no output schema and no annotations, the description covers the essential flow: what it returns, the DNS verification step, and the retry guidance. It could mention duplicate-domain handling or error responses, but the tool is simple enough that these gaps are minor.

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% – both 'domain' and 'pages' are fully documented in the schema. The description adds no extra parameter-specific meaning beyond the schema, so the 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 opens with 'Register one domain and return its tenant id plus the DNS TXT record' – a specific verb, resource, and output. It also distinguishes itself from sibling answerhatch_start_crawl by stating 'The crawl does not start here', making its scope unmistakable.

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?

It gives explicit when-to-use guidance ('Call this once per site') and when-not-to-use ('if a crawl will not start, retry the crawl rather than registering again'). It also directs the agent to the correct next step: wait for DNS publication, then call answerhatch_start_crawl.

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

answerhatch_loginSign in to AnswerHatchA

Sign in and hold the bearer token for the rest of this session. Call this once before any other answerhatch tool. Skip it when the server was started with ANSWERHATCH_TOKEN set. This tool does not create accounts: sign up first at answerhatch.com/signup. Never print the password back to the user.

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	account email address
`password`	Yes	account password

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that it holds a bearer token for the session, never prints the password, and does not create accounts. Missing failure behavior, but the key stateful and safety behaviors are covered.

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 with the primary action. Each sentence adds distinct value: session token, usage prerequisite, skip condition, account creation boundary, and password privacy. No wasted words.

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 login tool with no output schema, the description explains the session token and the skip condition, which are essential. It could mention what happens on failure or whether a return value exists, but these are not critical for a session initiator. Overall, it is complete enough for an agent to use 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 100%, so both email and password are already documented. The description adds a note about not printing the password, which is more behavioral than parameter-specific, so it provides minimal extra semantic value beyond the 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?

Clearly states the verb 'Sign in' and the resource 'AnswerHatch', and explicitly says it holds the bearer token for the session. It differentiates from siblings by instructing to call it before any other answerhatch tool, making its role unambiguous.

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?

Provides explicit guidance: call once before other tools, skip if ANSWERHATCH_TOKEN is set, and it does not create accounts (directing to signup). This fully addresses when to use and when not to use, including alternatives.

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

answerhatch_start_crawlStart the crawlA

Start the crawl for a registered tenant. Call it only after the TXT record from answerhatch_create_tenant is published. If the record is not visible yet the tool returns the record again with instructions to publish and retry: wait about a minute and call this tool again. The crawl is asynchronous, so poll answerhatch_status afterwards.

ParametersJSON Schema

Name	Required	Description	Default
`tenant_id`	Yes	tenant id returned by answerhatch_create_tenant

TDQS

A4.5/5.0

Behavior4/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 that the crawl is asynchronous, that it may return the record again with instructions, and that a retry after about a minute is expected. This is valuable behavioral context, though it doesn't mention side effects beyond starting a crawl.

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 every clause adds value. It efficiently covers prerequisites, retry behavior, and follow-up without wasted words.

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?

For a one-parameter tool with no output schema, the description covers the full calling context: when to call, what to expect, how to handle the retry case, and what to do next. Nothing an agent needs is missing.

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 already documents the single parameter with a description ('tenant id returned by answerhatch_create_tenant'), and schema coverage is 100%. The tool description adds no extra semantics about the parameter beyond referencing the sibling, so 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 states a specific action ('Start the crawl') with a clear target ('for a registered tenant'), and it distinguishes itself from siblings by explicitly referencing create_tenant for prerequisites and status for follow-up. The verb and resource are unambiguous.

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?

It gives explicit sequencing guidance: call only after the TXT record is published, and poll status afterwards. It also provides a retry condition with a wait time. This is clear when-to-use and when-to-use-alternative guidance.

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

answerhatch_statusCheck tenant statusA

Report a tenant's lifecycle stage, worker phase, pages crawled and domain verification. Poll this every 20 to 30 seconds while a crawl runs. When the stage reaches live it also returns the embed snippet and the steps for pasting it into the site, which is the end of onboarding.

ParametersJSON Schema

Name	Required	Description	Default
`tenant_id`	Yes	tenant id returned by answerhatch_create_tenant

TDQS

A4.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the conditional return of an embed snippet and steps at the live stage, which is helpful. However, it does not explicitly state whether the operation is read-only or if there are side effects, errors, or authentication requirements.

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, consisting of three short sentences with no redundant content. It efficiently conveys the core functionality, polling behavior, and conditional output.

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?

Given there is no output schema, the description sufficiently enumerates the returned fields (lifecycle stage, worker phase, pages crawled, domain verification) and the conditional embed snippet and steps. It also provides usage context, making the tool easy to invoke correctly.

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 only parameter, tenant_id, has a clear description: 'tenant id returned by answerhatch_create_tenant'. This directly tells the agent where to obtain the value, fully clarifying its semantics.

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 that the tool reports a tenant's lifecycle stage, worker phase, pages crawled, and domain verification. The title 'Check tenant status' reinforces the purpose, and it is distinct from the sibling tools (login, create_tenant, start_crawl).

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?

Explicit guidance is given: 'Poll this every 20 to 30 seconds while a crawl runs.' It also explains the conditional behavior when the stage reaches live, providing clear when-to-use and what-to-expect instructions.

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 updatesv0.1.0Sep 7, 2026
- First observedanswerhatch_create_tenant
- First observedanswerhatch_login
- First observedanswerhatch_start_crawl
- First observedanswerhatch_status

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.7/5.0

Scored 2026-09-07 11:25 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: authentication, domain registration, crawl initiation, and status polling. There is no overlap or ambiguity between them.

Naming Consistency5/5

All tools follow a consistent 'answerhatch_<verb/noun>' pattern with lowercase snake_case, making the naming uniform and predictable.

Tool Count5/5

With exactly 4 tools, the set is concise and well-scoped for the onboarding workflow it implements, fitting comfortably within the ideal range.

Completeness5/5

The tools cover the full lifecycle from authentication through domain verification, crawl execution, and final status reporting with embed snippet delivery. No essential operations are missing for the stated purpose.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Koskamo A
com.koskamo
Cited, versioned knowledge for agents: retrieve sourced passages and propose owner-approved fixes.
RAG Systems Knowledge & Memory Documentation Access
61
Citation Verification A
io.github.guptaprakhariitr
Real-time fact-check, citation verification, and source-freshness for AI agents.
Search RAG Systems
321
mcp-server A
com.quelvio
Your company's brain for AI agents. Cited, permission-aware knowledge across every system.
Knowledge & Memory Search RAG Systems
32
oka-anywhereOAuth
io.github.forgeagents-jp
Your office's procedures inside Claude or ChatGPT - verified citations or an honest refusal.
Documentation Access RAG Systems
1

Related MCP Servers

rag-mcp-server
RAG Systems Search Knowledge & Memory
Rubrum95
A
license
Not graded
quality
D
maintenance
Enables Claude Code to index and semantically search through PDFs, code, and documents with exact citations and zero hallucinations.
Updated 7 months ago (2026-03-12 17:08 UTC)
MIT
RAG MCP Server
RAG Systems AI & Machine Learning
johnylira
F
license
Not graded
quality
C
maintenance
Enables document indexing and question answering with Retrieval-Augmented Generation, providing cited answers from user-supplied documents.
Updated a month ago (2026-08-25 00:54 UTC)
-
ossian-mcp
RAG Systems Knowledge & Memory
dockndevai
A
license
A
quality
A
maintenance
Enables agents to query an organization's own documents and receive cited answers, while also maintaining persistent memory across conversations.
Updated 6 days ago (2026-09-21 12:25 UTC)
4
52 npm
2
Apache 2.0
CiteAnything MCP Server
RAG Systems Search
veriglow
A
license
Not graded
quality
A
maintenance
Enables AI agents to create verifiable, replayable citations, search private knowledge bases, and publish Markdown with verified citation markers.
Updated 24 days ago (2026-09-03 06:46 UTC)
MIT

AnswerHatch MCP

What AnswerHatch is

Install

Use it

Tools

Security

Links

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers