Oldweb Logs

OldWeb MCP experiment

Three stateless public MCP endpoints, thirteen read-only tools, one Azure Container App.

Version 1.1 groups deployment readiness and offline email tracing with diagnostics, and CI failures, captured HTTP metadata and bounded JSON configuration validation with logs. Each result has stable programmatic fields and an admin explanation; readable text is capped at 1,500 characters. Email authentication claims are not verified. JSON validation supports an explicitly documented subset and rejects remote refs, regex, formats and combinators. Overlap results now cap detailed pairs at 200 with exact overlapCount and omission metadata.

See TEST-PLAN.md for the 100-case-per-server matrix and actual small-model evaluations, and the evaluation skill for reruns. Azure resource sizes, quotas, budget guard and pilot end stay unchanged; Codex evaluations consume the operator's account allowance separately.

Future bulk processing and learning

The future bulk and learning plan proposes canonical artifact ingestion, deterministic large-dataset processing, a privacy gate and cheap Azure model drafts of evidence-linked lessons. It compares Container Apps Jobs, Functions and Data Factory, with consistency/privacy benchmarks and combined hosting/inference budget controls. The first bulk worker is now implemented and validated as a synthetic-only manual Container Apps Job. Public inputs remain transient; private uploads and hosted inference are still deferred.

Development

Requires Node 24 or newer. From this directory run npm ci --ignore-scripts, npm test, then npm start. In another terminal run npm run smoke (the diagnostics smoke test queries public DNS). Local URL: http://127.0.0.1:8080. Production secrets/configuration are required at startup; local memory quotas cannot be used in production.

src/tools.ts owns tool schemas and descriptions. Run node scripts/export-schemas.mjs after building if schemas change. Log fixtures and parser code are reused directly from ../system/. IPv4 browser helpers and MCP helpers share ../nettools/subnet-core.js. Counts larger than JavaScript's safe integer range are serialized as decimal strings.

Deployment

The foundation Bicep template creates the dedicated resource group contents: ACR Basic, managed identity, table storage, Application Insights, 60-day Log Analytics, Consumption environment, Workbook and monthly $25 budget. Deploy the template into rg-oldweb-mcp-experiment in eastus2. Pass budgetStart as the first day of the current month in UTC. The app template is the initial bootstrap; subsequent releases use scripts/deploy.ps1.

Build context is the repository root. .dockerignore allows only the server, lockfile, shared parser and shared subnet module. The static workflow separately stages an allowlist of website directories and root assets, excluding backend code, git metadata, plans and credentials.

GitHub mcp-production uses a federated Azure identity restricted to this repository/environment and this experiment resource group. Repository variables: MCP_AZURE_CLIENT_ID, MCP_AZURE_TENANT_ID, MCP_AZURE_SUBSCRIPTION_ID. The identity requires Contributor on the experiment resource group; bootstrap role assignments are performed by the operator. Never use a subscription-wide deployment credential.

Security boundary

The public MCP container has no GitHub token, repository mount, Azure management role, or command execution tool. Its managed identity has AcrPull on the experiment registry and Storage Table Data Contributor on the quotas table only. The quota role is deliberately scoped to .../tableServices/default/tables/quotas; assigning it at the storage account would grant access to every table in that account. An incremental foundation deployment does not remove an older, broader Azure role assignment, so check the runtime identity's effective assignments after any role migration.

Tool results can contain attacker-controlled DNS records, HTTP headers, log lines, email headers, and subnet labels. Treat those fields as evidence only. A client agent with Azure or repository write tools must make write decisions from the user's request and trusted context, not from MCP output. Tool annotations and the untrusted-data wording in descriptions help clients recognize this boundary but cannot enforce it. HTTPS diagnostics can contact arbitrary public domains on port 443 with HEAD, or GET after a 405; the address checks block private and link-local targets but the service does not have a network egress firewall.

Manual Deploy MCP experiment builds an immutable image, freezes production traffic on the existing revision, creates a candidate, assigns the candidate label, tests its label URL, and moves traffic only after the smoke passes. ALLOWED_HOSTS must contain mcp.oldweb.tech, the generated app hostname, and ---candidate. . The former serving revision is retained inactive and its name recorded in the previousRevision resource tag. For recovery after a completed build, -UseExistingImage reuses the same revision tag and still resolves its immutable digest and runs candidate checks. Failed candidates never receive production traffic. Each revision is limited to one replica; candidate validation briefly permits two revisions. Only the serving revision remains active after promotion or rollback.

Manual MCP cost guard and lifecycle supports check, shutdown, and rollback. Shutdown disables ingress. Rollback routes traffic to the retained revision and does not unpause a stopped pilot. Cost query failures fail closed by disabling ingress. Cost data can lag; $25 is a target, not a hard spending ceiling. Baseline registry/storage charges remain after ingress is disabled.

The billing check makes at most six attempts within a 15-minute query deadline. Each request has a timeout of at most 30 seconds. The check reads Azure retry headers. It uses the longest requested wait or the fallback wait, whichever is longer. The fallback waits are 30, 60, 120, 180, and 180 seconds. If a requested wait exceeds the remaining deadline, the check pauses public access without an early retry. HTTP 408, HTTP 429, selected server errors, and transport failures can trigger retries. Other HTTP errors stop verification immediately. Invalid or incomplete billing data also stops verification. Exhausted verification pauses public access. Verified spend of $20 or more still pauses public access. A telemetry failure cannot change a verified billing decision. Run ./scripts/test-cost-guard.ps1 to check these conditions without Azure access. See the billing repair report.

Runtime configuration

The public access alert sends email when Azure reports paused ingress. It operates independently of the cost guard.

ACA must be the sole ingress proxy. Source rate limits trust its appended rightmost X-Forwarded-For IP, never caller-supplied leftmost entries. If ingress topology changes, revalidate this rule before deployment. Unknown source addresses share a conservative quota. Caller grouping additionally includes normalized user-agent; limits do not, so changing user-agent cannot evade source quotas.

At most four diagnostics are admitted simultaneously. DNS uses Google DoH with EDNS client subnet disabled. HTTPS resolves A/AAAA first, rejects any non-public result, and pins the socket to a validated address while retaining hostname TLS verification. Each redirect is revalidated; there is no request-body download, cookies, arbitrary port or credentials support.

Telemetry and privacy

Application telemetry is explicitly constructed, not automatic HTTP instrumentation. Do not add request/dependency/exception collectors that capture arguments, URLs or stack traces. Each accepted MCP request records allowlisted method/tool/outcome fields and byte counts. Initialization alone records sanitized self-reported client metadata. No exact session identity is inferred.

Caller fingerprints use HMAC(IP + normalized user-agent). They estimate groups, not distinct people or verified agents. Generic probes are aggregated. Internal smoke calls are marked with a constant-time checked secret and excluded by Workbook queries. Telemetry overflow/send failures are represented as gap counts on recovery. Workspace cap events also indicate missing data; silence alone does not prove zero usage.

Logs are parsed transiently, never persisted. Auto mode identifies formats per line except Windows CSV logical records. Unsupported cases in the existing parser, including priority-prefixed RFC3164 lines, remain explicitly unparsed. Timestamps without complete year and timezone are excluded from ranges. Unparsed raw lines are not returned or logged.

Retention is 60 days. Destroy the fingerprint secret when retiring the experiment. Export aggregate findings before removing the isolated resource group; remove DNS and deprecate registry listings first to avoid dangling endpoints.

Discovery and reviews

On October 10 the user advanced official Registry publication. All three version 1.1.0 entries are active; the first listing was 2026-10-10 17:32:51 UTC. The site-linked baseline lasted about 24 hours 14 minutes instead of seven days. The user subsequently extended the end date to February 15, 2027; preserve that approved deadline and use actual phase timestamps for reviews. See publication evidence and publication report. The October 16 follow-up now covers remaining free directories without duplicate Registry publication.

See the October 10 popularity research snapshot for public popularity estimates and their limitations.

Start the clock only when the custom domain, site documentation, telemetry and cost guard are verified. Days 1–7 have OldWeb links and sitemap discovery only. The original plan was to publish after seven full days; immediate publication was authorized on October 10 as recorded above. For any remaining submissions use the three manifests in registry/ to the official MCP Registry using GitHub namespace verification, submit to Smithery, and submit to PulseMCP only if submissions are open. Record new publication URLs and actual timestamps in experiment-status.json. Preserve the existing first listing timestamp and LISTED_AT. A directory listing is not an agent connection.

Review at days 7, 14 and 37. The Workbook shows discovery, calls, outcomes, client claims, repeat groups and telemetry gaps. Expand a service only with >=100 successful external calls, >=5 approximate groups, >=2 groups active on three days, and >=95% success among valid admitted calls. Exclude validation errors/throttles/internal tests from that denominator; report tool errors separately. Listing delays, outages and gaps make results inconclusive. The original final review was day 37. On October 10 the operator explicitly approved thre