Exposing a raw query interface to an agent usually fails the same way: the query is syntactically fine and references a field that does not exist, and the error comes back as a schema complaint the model then guesses around. Searching the schema first turns that into a lookup. Offering SQL over staged data alongside GraphQL is the other considered decision, because the two suit different questions — GraphQL for traversing relationships from a known variant, SQL for counting and grouping across the corpus. Four ways in means the caller has to choose, which is a small cost for a curated scientific dataset where the questions vary this much.
A client for CIViC, the Clinical Interpretation of Variants in Cancer knowledgebase, offering four access paths over the same data rather than a fixed set of question-shaped tools.
- civic_search searches the GraphQL schema itself for query roots, types and fields — the tool you call before writing a query against a schema you do not know.
- civic_graphql_query executes against the CIViC GraphQL API directly.
- civic_query_sql runs read-only SQL against staged CIViC data in SQLite, which is a different shape of question from GraphQL and much better at aggregation.
- civic_execute runs JavaScript against the GraphQL API in a sandbox, for the case where the answer needs several dependent queries.
Nothing to supply — CIViC is a public knowledgebase.
One command — npx mcp-remote https://civic-mcp-server.quentincody.workers.dev/mcp