QueryHost

QueryHost gives browser agents typed WebMCP tools to query live game servers, then renders the same result for a person to inspect and continue.

Comment

Why QueryHost

Game servers expose status through different protocols, default ports, optional query ports, and response shapes. A person or browser agent should not need to know those details before asking whether a server is online or who is playing.

Browser agents can operate page controls, but that hides the site's domain contract and safety rules. A detached agent response also leaves the person without the query inputs, source provenance, warnings, and raw result in the product UI.

What it does

QueryHost puts six game profiles behind one public playground and two document-scoped WebMCP tools:

  • list_supported_games returns canonical game IDs, names, ports, recommended modes, and capabilities from [email protected].
  • query_game_server accepts a canonical game, plain host, bounded ports, query mode, and deadline, then sends the request through the same /api/query route as the form.

An agent can discover the right profile, run a bounded query, and render the response into the playground. The person can inspect the overview, game data, source reports, warnings, and raw JSON, then change the populated controls and continue manually.

Why WebMCP

WebMCP makes the site's real domain contract discoverable instead of asking an agent to infer it from presentation markup. QueryHost keeps target validation, throttling, cancellation, and result semantics in one path shared by people and agents.

That shared UI creates the handoff: the agent handles discovery and the first query, while the person sees the evidence and continues from the same state.

How it works

The browser registers the tools only when document.modelContext exists. Both definitions live in the web application; the portable library and hosted API contain no browser-specific code.

query_game_server calls the same-origin POST /api/query route. That route validates and throttles the caller before forwarding to the private Railway API, which uses [email protected] to query a validated, pinned public target. The browser returns the existing playground response unchanged and renders it into the visible UI.

One coordinator handles human and agent cancellation. Request identity prevents late responses from replacing newer results. Server-controlled names, messages, rules, and player data are explicitly marked as untrusted data, not instructions.

Existing-project work completed during the challenge

After August 25, 2026, QueryHost added the two WebMCP tools, shared agent-and-human request coordination, browser cancellation, visible agent-result handoff, WebMCP documentation, regression coverage, Chrome compatibility, and production acceptance evidence. Signed commits ceaa6d2 and dc72c57 identify that work.

Testing

The production build passed formatting, TypeScript and Astro checks, lint, 41 tests, and the production build. Chrome acceptance covered both tools, an approved live Minecraft Java query, a blocked localhost target, cancellation, stale-result prevention, and the normal unsupported-browser experience.

No credentials are required. Open query.host in ChatGPT's in-app browser or Chrome 149 or later with WebMCP enabled. Discover both tools, query test-minecraft.nodecraft.gg as minecraft-java, and confirm the agent result appears in the playground. Then switch to Full details under Advanced options and continue by hand.

AI and Codex

A compatible browser agent reads the two WebMCP schemas, selects a canonical game profile, invokes the query tool, and receives structured data that QueryHost also renders for the person.

OpenAI Codex helped plan and implement the WebMCP adapter, regression tests, security review, browser acceptance, deployment checks, and submission materials. ChatCut Desktop produced the demo edit and AI voiceover.

Links

Built With

Share this project:

Updates

Submission history