chore: drop ooxml-call dev harness; add data/README; surface structural tools in README

- Remove scripts/ooxml-call.ts: 23 query-layer tests cover the same
  dispatch path. The harness was load-bearing only while we were
  verifying e2e before tests existed.
- Add data/README.md describing what each subpath under data/ is for
  (sources.json committed manifest, xsd-cache gitignored cache,
  behavior-notes future curated content).
- Update README.md to list the structural tools alongside semantic
  search; both flavors share one MCP endpoint after the prod populate.
- Update CLAUDE.md and scripts/ingest-xsd/README.md to drop ooxml:call
  references; smoke testing now points at tests/mcp-server/.

44/0 still.

Author: caiopizzol

CLAUDE.md

@@ -37,7 +37,6 @@ scripts/
   ingest-xsd/          ECMA XSDs -> schema graph (structural query corpus)
   sources-sync.ts      data/sources.json -> reference_sources
   db-migrate.ts        Apply db/migrations/*.sql in order
-  ooxml-call.ts        Local CLI harness for the structural MCP tools
 db/
   schema.sql           PostgreSQL + pgvector + XSD schema graph
   migrations/          Numbered, idempotent SQL migrations

README.md

@@ -10,9 +10,10 @@ The OOXML spec, explained by people who actually implemented it.
 
 An interactive reference for ECMA-376 (Office Open XML) built by the [SuperDoc — DOCX editing and tooling](https://superdoc.dev) team. Every page combines XML structure, live rendered previews, and implementation notes that tell you what the spec doesn't.
 
-- **Live previews** — Edit XML and see it render in real-time. Every example is a working document.
-- **Implementation notes** — Where Word diverges from the spec, what will break your code, and what to do about it.
-- **Semantic spec search** — 18,000+ spec chunks searchable by meaning via MCP server.
+- **Live previews** - Edit XML and see it render in real-time. Every example is a working document.
+- **Implementation notes** - Where Word diverges from the spec, what will break your code, and what to do about it.
+- **Semantic spec search** - 18,000+ spec chunks searchable by meaning via MCP server.
+- **Structural schema lookup** - Element children, attributes, types, enums, namespaces. Same MCP server, deterministic answers from the parsed XSDs.
 
 ## Why?
 
@@ -22,13 +23,16 @@ We faced this at SuperDoc — building a document engine on native OOXML with no
 
 ## MCP Server
 
-Search the ECMA-376 spec with AI. Ask questions in natural language, get answers grounded in the actual specification.
+Ask questions in natural language and get answers grounded in the spec, or query the schema graph for precise structural answers.
 
 ```bash
 claude mcp add --transport http ecma-spec https://api.ooxml.dev/mcp
 ```
 
-Works with Claude Code, Cursor, and any MCP-compatible client. Three tools: `search_ecma_spec` (semantic search), `get_section` (by ID), and `list_parts` (browse structure).
+Works with Claude Code, Cursor, and any MCP-compatible client. Two flavors of tools share one server:
+
+- **Semantic** (over the spec PDF): `search_ecma_spec`, `get_section`, `list_parts`
+- **Structural** (over the parsed XSDs): `ooxml_lookup_element`, `ooxml_lookup_type`, `ooxml_children`, `ooxml_attributes`, `ooxml_enum`, `ooxml_namespace_info`
 
 ## Development
 

data/README.md

@@ -0,0 +1,27 @@
+# data/
+
+Repository data root. Three categories live here:
+
+- **`sources.json`** (committed): canonical source manifest. One entry per
+  artifact (ECMA-376 PDFs, ECMA Part 4 XSD zip, future MS-OI29500, etc.) with
+  url, edition, sha256, and a license note. `bun run sources:sync` upserts these
+  rows into the `reference_sources` table. Edit by hand; the sync script reads
+  it.
+
+- **`xsd-cache/`** (gitignored): local XSD download cache. Populated by
+  `bun run xsd:fetch`. Contents are not load-bearing for the schema graph
+  itself - the graph lives in Postgres - they're just the source artifacts
+  the ingest reads. Safe to delete; regenerated on the next fetch.
+
+- **`behavior-notes/`** (committed when populated): curated YAML files
+  documenting how Microsoft Office actually behaves vs. the spec. A future
+  ingest will load these into the `behavior_notes` table so structural tool
+  responses can carry "what Word actually does" alongside the schema-level
+  answer. Empty until that workflow lands.
+
+What does NOT live here:
+
+- Generated build output: `dist/`, `dev/data/extracted/`, `dev/data/chunks/`,
+  `dev/data/embedded/` (all under `dev/`, gitignored).
+- Database state: lives in Postgres; reproducible from the manifest +
+  ingest scripts.

package.json

@@ -28,7 +28,6 @@
     "pdf:setup": "pip install -r scripts/requirements.txt",
     "xsd:fetch": "bun scripts/ingest-xsd/fetch.ts",
     "xsd:ingest": "bun scripts/ingest-xsd/ingest.ts",
-    "ooxml:call": "bun scripts/ooxml-call.ts",
     "test": "export TEST_DATABASE_URL=${TEST_DATABASE_URL:-postgresql://postgres:postgres@localhost:5432/ecma_spec} && bun test tests/db/ && bun test tests/ingest-xsd/ && bun test tests/mcp-server/"
   },
   "devDependencies": {

scripts/ingest-xsd/README.md

@@ -66,8 +66,15 @@ bun run xsd:ingest --schema-dir <path> --entrypoint <file> \
 
 ## Smoke-test the result
 
+The query layer is exercised by `tests/mcp-server/ooxml-queries.test.ts`
+against the same fixtures the ingest tests use. Run with:
+
 ```bash
-bun run ooxml:call ooxml_children   '{"qname":"w:tbl"}'
-bun run ooxml:call ooxml_attributes '{"qname":"w:pBdr"}'
-bun run ooxml:call ooxml_enum       '{"qname":"w:ST_Jc"}'
+bun test tests/mcp-server/
 ```
+
+To hit the live MCP, deploy the Worker and call the tools through any
+MCP client. For local poking against the dev DB, write a small bun
+script that imports `runOoxmlTool` from
+`apps/mcp-server/src/ooxml-tools.ts` with a `postgres.js`-backed sql
+function.