togomcp: Skill for Claude Code

MIE File Generator

An MIE file is a compact YAML document that describes an RDF database well enough for an LLM to write correct, efficient SPARQL against it on the first try. Good MIE files are the difference between "Claude writes a working query" and "Claude times out the endpoint with a FILTER(CONTAINS()) over 244M triples".

Format: v3. The authorable contract is togo_mcp/data/docs/MIE_v3_spec.md — read it before writing. v3 is organized by agent need × recoverability with the verified, executable worked example as the atomic unit: five need-based parts (database, discovery, the header, examples, schema_delta, id_join_map), where each example simultaneously is the schema shape, the sample triple, and (via traps_avoided) the warning it would otherwise be written as three or four times. The worked reference is the hand-authored pilot togo_mcp/data/mie/uniprot.yaml. Carry only what the model cannot recover on its own (spec §4.3); where this skill and the spec disagree, the spec wins.

This skill lives in a Claude Code environment with filesystem access and SPARQL execution tools (from the togomcp_local MCP server). Use filesystem tools freely — that is the normal mode of operation here.

The Two Hard Rules

1. No blind SPARQL retry loops. Schema discovery legitimately requires many queries, but if a query fails twice in a row, stop and diagnose — wrong predicate, wrong graph, wrong IRI pattern — before retrying. More retries without diagnosis do not fix a structurally wrong query.

2. Nothing in the MIE file is invented — and "it ran" is not "it's right." Every examples entry must be executed against the real endpoint before the file is written, its live result recorded in the verified: block with a date:, and that result confirmed correct, not merely error-free:

• SPARQL (every examples[].sparql, including the aggregation and cross_db ones): must run AND return the right thing. A query that succeeds but returns a union-inflated COUNT is a failed test, not a passing one — scope the graph and verify the figure (Phase 2g / 5c). The verified: block records the actual figure you saw, so a later re-run that disagrees is a drift signal, not silent rot.
• Search-wrapper claims: any assertion the file makes about a search_* / ncbi_esearch / OLS4:searchClasses tool's behavior (e.g. "use search_chembl_target for targets, EGFR → CHEMBL203") must be run through the actual tool and the claimed hit confirmed to appear at a usable rank/limit — not buried at rank 5 behind unrelated hits, and present at the limit the claim implies (Phase 5e).