What can you do with this server?

This server exposes a broad ontology and knowledge-graph engineering and verification toolkit, covering loading, reasoning, validation, alignment, lifecycle management, querying, and AI-assistant integration. * Load & convert: load RDF files, pull from URLs/SPARQL, push to endpoints, convert between Turtle/NTriples/RDF/XML/NQuads/TRiG, and ingest CSV/JSON/XML/YAML/XLSX/Parquet * Query & inspect: run SPARQL, get store statistics and health status, capture lineage and history * Reason & verify: materialize RDFS/OWL inferences, check DL subsumption, explain unsatisfiability, validate with SHACL, and validate syntax * Plan & operate: Terraform-style diff/plan/apply, lock IRIs, monitor watchers, drift detection, version snapshots, rollback, and safe/migrate/force apply modes * Align & enrich: auto-detect alignments, give alignment feedback, compute similarities, search semantically, and map clinical crosswalk codes * Enforce quality: lint ontologies, enforce design patterns (generic/BORO/value partition) with feedback loops, and validate labels against clinical data * Extend & transform: generate mapping configs, import PostgreSQL schemas as OWL, enrich classes with SKOS mappings, and run an ingest→SHACL→reason pipeline

Which integrations are available for this server?

Provides tools to import database schemas from PostgreSQL and convert them into OWL ontologies for knowledge graph generation. Enables the ingestion and transformation of XML data files into RDF format as part of the ontology data pipeline. Allows for the ingestion of YAML data files to be mapped and integrated into the knowledge graph.

de en es ja ko ru zh

open-ontologies

by fabio-rovai

Overview Schema Source Related Servers Discussions Admin

Rust

Hybrid

Ask a reasoner why it believes something and it will tell you to trust it. This one hands you a proof, and refuses a forged one.

Open Ontologies builds, changes and operates ontologies and knowledge graphs with Terraform-style lifecycle management, and reasons over them with proof-carrying inference. Every conclusion comes with a certificate that a separate checker, written in Lean 4 and proved sound, will either accept or reject. Written in Rust, ships as a single binary, speaks MCP to Claude, Cursor and anything else that talks to it.

See it in action

Four triples in, three out. ex:Northwind was only ever asserted to be in a sanctioned jurisdiction; that it needs enhanced due diligence was derived, and the derivation is checkable by someone who does not trust you, your engine, or the model that wrote the ontology.

Related MCP server: Universal Ontology MCP

With a proof, and without one

The same query, answered by an ordinary reasoner and by this one.

	An ordinary reasoner	Open Ontologies
The answer	`Northwind needs enhanced due diligence`	the same answer
Why it holds	"the reasoner said so"	a certificate naming every rule and premise
Who can check it	nobody, short of rerunning the same engine	anyone, with a checker that shares no code with the engine
If the engine has a bug	you get a wrong answer, confidently	the checker rejects it, exit 1
If someone edits the output	undetectable	rejected, with the line and rule named
If a rule was yours, not the standard's	reported identically	a different verdict word, enforced by a test
What an auditor receives	a screenshot	a file they can re-verify themselves
Guarantee on an unsatisfiability answer	asserted	none, and it says so

That last row is the point of the whole project. Where something is measured rather than proved, the tool says measured; where a prover's opinion is an opinion, it never borrows the checker's vocabulary. What is proved, and what is not.

What it does

Capability	What you get
Reason over OWL and RDFS	Materialised inferences and a derivation certificate a proved checker accepts
Bring your own rules	SWRL, RIF Core or a Horn table, evaluated, with a verdict word that says they were yours
Validate against SHACL	A report from an evaluator measured against the W3C suite, not just asserted to pass
Ask if something is satisfiable	A finite model, replayed and checked, rather than a yes
Ask if something is inconsistent	A refutation where one is certifiable, and an honest engine opinion where it is not
Retrieve a slice for RAG	Per-claim entailment preservation, because 99% coverage can still drop the one triple that mattered
Change an ontology in production	Plan, blast radius, risk score, locked IRIs, apply, monitor, drift, rollback
Load real data	CSV, JSON, XML, YAML, XLSX, Parquet, PostgreSQL and DuckDB into RDF
Hand it to a prover	TPTP, CLIF, SMT-LIB and LADR from one translation, with what it cannot export named and counted
Work from an assistant	An MCP server, so Claude or Cursor drives all of it in conversation

Try the checker itself

The three files are in the repository, and the output below is what the checker printed, trimmed to the fields that matter.

$ cd lean && lake build            # builds the checkers, core Lean 4, no Mathlib
$ F=../tests/fixtures/horn

$ lake exe oo-horn check $F/builtin_rules.tsv $F/asserted.tsv $F/good.tsv
{"ok":true,"verdict":"entailed","theorem":"OOCert.entails_of_builtin_horn",
 "means":"every conclusion is true in every model of the asserted graph"}

$ lake exe oo-horn check $F/builtin_rules.tsv $F/asserted.tsv $F/bad_conclusion.tsv
{"ok":false}                        # one IRI in the conclusion changed. exit 1.

$ lake exe oo-horn check $F/user_rules.tsv $F/asserted.tsv $F/good.tsv
{"ok":true,"verdict":"entailed_under_supplied_rules","theorem":"OOCert.horn_certificate_sound"}

The third line is the one that matters. Same inference, but one of the rules was written by you, so it is an assumption the certificate carries and not a fact it establishes. The verdict word changes, and a test fails if it ever stops changing.

flowchart LR
  E["Untrusted engine<br/>Rust, or the pure-Python one"] -->|certificate| C["Verified checker<br/>core Lean 4"]
  I["Isabelle/HOL<br/>independent second kernel"] -.->|same bytes| C
  C -->|built-in rules| A["entailed"]
  C -->|your rules| B["entailed_under_supplied_rules"]
  C -->|forged| X["refused, exit 1"]

The whole thing in sixteen seconds

Three sentences in. Three inferences out. The checker accepts the proof, then one conclusion is forged with the premises left untouched and the same checker refuses it, naming the rule. Every line in that recording is real output, not a mock-up. The commands are below if you want to run it.

Run it on your own ontology

Those fixtures ship with the repository. Here is the same thing starting from a file you wrote. Install is below; this takes about a minute.

mkdir /tmp/oo-demo && cd /tmp/oo-demo
cat > coffee.ttl <<'EOF'
@prefix ex:   <http://example.org/> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:Espresso rdfs:subClassOf ex:Coffee .
ex:Coffee   rdfs:subClassOf ex:Drink .
ex:myCup    a               ex:Espresso .
EOF

export OPEN_ONTOLOGIES_STORAGE_MODE=persistent          # in-memory by default, see below
open-ontologies --data-dir /tmp/oo-demo/store load coffee.ttl
open-ontologies --data-dir /tmp/oo-demo/store reason --profile rdfs --certificate ./cert

Three triples in, three out: the cup is a Coffee, the cup is a Drink, and Espresso is a subclass of Drink. Any RDFS reasoner does that much. The difference is the directory it just wrote.

lake exe oo-cert /tmp/oo-demo/cert/asserted.tsv /tmp/oo-demo/cert/derivations.tsv
{"ok":true,"asserted":3,"derivations":3,"theorem":"OOCert.certificate_sound"}

Now lie to it. Leave the premises alone and forge one conclusion, claiming the cup is a Beer:

cp -r /tmp/oo-demo/cert /tmp/oo-demo/forged
sed -i '' 's|example.org/Drink>\t<http://example.org/myCup>|example.org/Beer>\t<http://example.org/myCup>|' \
  /tmp/oo-demo/forged/derivations.tsv     # GNU sed: drop the '' after -i
lake exe oo-cert /tmp/oo-demo/forged/asserted.tsv /tmp/oo-demo/forged/derivations.tsv

{"ok":false,"asserted":3,"derivations":3,"first_rejected":2,"rule":"rdfs9",
 "conclusion":"<http://example.org/myCup> <...#type> <http://example.org/Beer>",
 "premises":["<http://example.org/myCup> <...#type> <http://example.org/Coffee>",
             "<http://example.org/Coffee> <...#subClassOf> <http://example.org/Drink>"]}

Exit 1, the offending line numbered, the rule named, and the premises shown so you can see for yourself that they do not support it.

What the proof actually looks like

Two tab-separated files, 1.3 KB for the run above. asserted.tsv is what you claimed:

<ex:myCup>      <rdf:type>          <ex:Espresso>
<ex:Coffee>     <rdfs:subClassOf>   <ex:Drink>
<ex:Espresso>   <rdfs:subClassOf>   <ex:Coffee>

derivations.tsv is one line per step: the rule, then the conclusion, then the premises it used.

rdfs9    <ex:myCup> <rdf:type> <ex:Coffee>              <ex:myCup> <rdf:type> <ex:Espresso>        <ex:Espresso> <rdfs:subClassOf> <ex:Coffee>
rdfs11   <ex:Espresso> <rdfs:subClassOf> <ex:Drink>     <ex:Espresso> <rdfs:subClassOf> <ex:Coffee> <ex:Coffee> <rdfs:subClassOf> <ex:Drink>
rdfs9    <ex:myCup> <rdf:type> <ex:Drink>               <ex:myCup> <rdf:type> <ex:Coffee>          <ex:Coffee> <rdfs:subClassOf> <ex:Drink>

That is the whole proof. No model, no network, no vendor. A checker walks it, re-derives each conclusion from its own premises under the named rule, and confirms every premise is either asserted or concluded by an earlier line. Anyone can write one; ours is the one with a soundness theorem.

Who checks it, and when

The certificate is a file, so the answer is whoever holds the file, whenever they like.

Who	When	What they run
You, in the loop	every run, before trusting an answer	`lake exe oo-cert` alongside the reasoner
A reviewer	when a change lands	the same command in CI, on the artefact the run wrote
An auditor, months later	long after the engine has moved on	the same command, on the archived files
Another agent	on receiving a claim from one it does not trust	the same command, before acting on it

Nothing is streamed and nothing phones home. The engine and the checker share bytes on disk, not a protocol, which is what makes the last two rows possible at all: an auditor re-checking a claim next year needs the two files and a Lean build, not a running instance of this software.

What the certificate does not carry is which graph it came from. It proves the conclusions follow from the assertions listed in it; it cannot tell you those assertions are the ones in your database. That gap is issue #158 and it is open. Showing a green result would prove nothing, since anything can print ok. The point is that it goes red.

Two defaults that will bite you otherwise. Storage is in-memory unless OPEN_ONTOLOGIES_STORAGE_MODE=persistent is set, so load followed by reason starts from an empty store and cheerfully certifies nothing; the tool warns, and the warning is easy to skim past. And --data-dir is a flag rather than an environment variable, so a demo without it writes into ~/.open-ontologies beside real work.

The discipline behind all of this is not free and it has earned its keep: what the rules are, and what each has caught.

What is actually proved

You ask	You get back	Checked against
Reason over OWL	A derivation certificate	`OOCert.certificate_sound`
Reason with rules you wrote	A certificate, and a different verdict word	`OOCert.horn_certificate_sound`
Is this satisfiable	A finite model	`Dl.satisfiable_of_checkModel`
Is a solver's model real	The model, replayed	`Fol.satisfiable_of_check`
Is this inconsistent	A refutation	`OOCert.refutation_sound`
Does this data fit the shapes	A validation report	`Shacl.validate_spec`
Does a retrieval slice still support the answer	Per-claim preservation	`OOCert.certificate_sound`

That last row is the one to read twice. A retrieval slice at 99% coverage can have dropped the one triple an answer depends on, and one at 60% can preserve every claim that matters. Coverage is a proxy that rises as the slice grows, so a retriever tuned on it learns to fetch more rather than the right thing. Entailment preservation is the property, it is decidable here, and it carries a certificate per claim. See decision 0007.

Measuring the loss is the second-best answer. The best one is a subset that cannot lose anything, and onto_module_extract computes one: a syntactic locality module over a signature, where every entailment of the whole ontology over those terms is still an entailment of the subset. That guarantee is a theorem of Cuenca Grau, Horrocks, Kazakov and Sattler, JAIR 31 (2008), and it is CITED rather than machine-checked, because nothing under lean/ is about locality. The report says exactly that, names no theorem of this project, and offers to measure the consequence instead: reason the ontology and the module to a fixpoint and report every conclusion over the signature the module does not reach. On this repository's own pizza ontology that is 238 of 1,345 axioms, and zero lost out of 2,583 differences examined. onto_conservative_check is the same machinery pointed at the lifecycle: does adding these axioms change any consequence over the names the ontology already used? See decision 0011.

What is NOT proved

Every line above is worth less if this section is missing, so it is here rather than in a file nobody opens. These are the load-bearing limits, and none of them is hypothetical.

The Rust engine is not verified. The theorems are conditional on it reporting the run faithfully. That boundary is thirty properties: make verify bounded-model-checks six, and five are enforced by the engine rather than observed of a dependency, two properties being in both counts. Two are irreducible, because they are about an execution and not a function: that asserted.tsv is the graph reasoned over, and that derivations.tsv covers every triple added. Those are property-tested end to end, which is not proved. docs/trusted-computing-base.md says which is which.

The bridge to the specification is a theorem, and what stands in its place now is smaller and a different kind of thing. An OWL 2 RDF-Based interpretation is a Lean structure in its own right: the parts of RBS Table 5.1 the rules reach, and RDF 1.1 Semantics section 5's truth clause with its I(p) ∈ IP conjunct. OOCert.Conforming.toW3C proves that every such interpretation carries the W3C conditions at full strength, and the five axiomatic-triple facts the old prose assumed are discharged inside that proof, from five triples of the RDF and RDFS axiomatic tables carried as quoted fields. OOCert.certificate_conforming_sound is then the sentence: a checked certificate's conclusions are true, in the specification's own sense of true, in every interpretation meeting those conditions that satisfies the asserted graph. One of the five facts was previously sourced to a triple whose predicate is the wrong one, which is why it is now taken from rdf:type rdfs:range rdfs:Class . instead.

What is left is a containment, not a reading: the condition list is a SUBSET of the Recommendation's, which is the safe direction and is why it is allowed, and that it is a subset is checked cell by cell by a reader rather than by Lean. Two smaller things are named at the file. IL is total, following RBS section 4.2's wording, which excludes RDF 1.1 interpretations in which a literal fails to denote; that one does not run in the safe direction, and closing it needs a term-occurrence lemma about checkStep that nobody has written. And one reading is load-bearing: RBS Table 5.4 at n = 0, which the engine's cls-int1 already depends on for empty lists.

Two kernels agreeing is weaker than it sounds. They are theorems over model classes nobody has ordered in either direction, so "both said entailed" means less than a reader would naturally take it to mean. Lean's class is still larger than the specification's, so entailment transfers outward for free and non-entailment does not: each one needs its own witness in the smaller class, and every negative result about the built-in rules now has one.

A non-vacuity witness can be vacuous where it matters, and ours was. It satisfied nine of twenty-one conditions only because the relevant extensions were empty, and six of the fourteen arms rested entirely on those, which is the failure mode that most resembles success. It is rebuilt, and the gate is now stronger than non-emptiness: every one of the fourteen derivations must fire at a concrete instance, and every one of the twenty-one conditions must have a satisfied antecedent.

Negative answers are mostly unchecked opinion. A refutation cannot be replayed in core Lean, so an "unsatisfiable" from any prover is testimony, not a certificate. One clash rule has a semantic condition and is certified; the other sixteen are detected and deliberately carry no certificate. A model is a finite object and can be checked, which is why satisfiability can be certified and unsatisfiability cannot. The testimony does now come with an exhibit: fol-prove reads the derivation Vampire or E prints, matches every leaf against the problem this engine emitted, checks the DAG, and recomputes the resolution-family steps, naming and counting every step it could not. Over FOAF that was 1279 of Vampire's 3314 steps and 181 of E's 4644. It is evidence about what the prover was answering about; it is not a proof, and no verdict word there says it is.

Governance. main requires the CI, Lean, SHACL-conformance and Python checks to pass, refuses force pushes and deletion, and applies to administrators too. Commits are not signed: a signing key was set up and then removed, because a passphrase-less key on a laptop is forgeable by anyone with disk access, and a forgeable assurance signal is worse than none in a repository that makes verification claims.

The scope is wider than the idea. The one genuinely new thing here is proof-carrying reasoning: an engine that hands you evidence a separate verified checker accepts. The tool count, the Studio, the embeddings, the crosswalks and the plugins are a product built around it, and they are not what makes this different. If you are evaluating the claim, read docs/decisions/ and lean/, and ignore the rest.

The second kernel is in isabelle/, written from the W3C specifications with the Lean deliberately unread, and it is run over the same bytes on every differential run.

Its sharpest catch was not a disagreement about a certificate. It was that fourteen arms of the Lean's soundness proof, across twelve of its twenty-nine rules, were sound because a field of the condition record said the rule holds. Twelve of those arms are stated by no cell of any specification table. The proofs passed, the axiom footprints were clean, and the machine-checked content for those arms was close to nothing. All fourteen are now derived from cells quoted out of the specification's raw HTML, in lean/OOCert/W3C.lean, and OOCert.certificate_w3c_sound restates the checker's verdict over every interpretation meeting those cells, rather than over the weaker conditions this Lean used to posit. Same certificates, same checker, and not one of those derivations depends on any axiom at all.

That step short of the specification has since been closed. lean/OOCert/Conforming.lean builds the specification's own interpretation in core Lean, so there is something to quantify over, and the reading that used to be prose is OOCert.Conforming.toW3C. The five IP memberships the old bridge assumed are fields of that structure, quoted out of the RDF and RDFS axiomatic-triple tables, and discharged in one step each by section 5's truth clause. OOCert.certificate_conforming_sound is the sentence certificate_w3c_sound said it was not yet, and lean/OOCert/ConformingWitness.lean exhibits an interpretation satisfying every one of those conditions and every RDF and RDFS axiomatic triple, then names, as checked theorems, which conditions it leaves untested and which Table 5.2 row it breaks.

The same review found the limit of that result. Entailment transfers outward and non-entailment does not, so a ¬ Entails here is about this layer's model class unless something restates it over the stronger one. Five of the nine now are, four of them with their existing witness interpretations unchanged, including the one a report's entailed_under_supplied_rules verdict rests on. The four that are not carry the field that stops them as a machine-checked theorem. An earlier version of this section said every conforming countermodel had to be hand-built; that was wrong, and the correction is in docs/lean-certificates.md and in the changelog rather than edited out of sight.

A justification is minimal because re-running said so, not because anything proved it. onto_justify answers which asserted triples a conclusion or a contradiction rests on, and of the three claims in that answer only one can be machine-checked. That a set SUFFICES is checkable, and is, when a certificate is written for it. That every element is NECESSARY comes from running the engine again without each one, and no theorem covers it. That the list is COMPLETE comes from Reiter's hitting-set tree, which is complete for a monotone oracle, and the engine has one corner that is not monotone, named in docs/explanation.md. Nothing in onto_provenance is machine-checked at all.

The discipline matters more than the machinery, and it runs through all of it.

A rule you supplied is an assumption the certificate carries, never a fact it establishes, so it earns entailed_under_supplied_rules and never entailed. A model a solver hands back can be checked and becomes a certificate; a refutation cannot be replayed in core Lean and stays an oracle opinion. The two never share a word. Where something is measured rather than proved, the documentation says measured, and what the proofs assume about the Rust is written down rather than left implied.

The reasoning behind each of those rules is in docs/decisions/, one file per rule, each naming the failure it exists to prevent.

Install

# macOS (Apple Silicon)
curl -LO https://github.com/fabio-rovai/open-ontologies/releases/latest/download/open-ontologies-aarch64-apple-darwin
chmod +x open-ontologies-aarch64-apple-darwin && mv open-ontologies-aarch64-apple-darwin /usr/local/bin/open-ontologies

# Linux (x86_64)
curl -LO https://github.com/fabio-rovai/open-ontologies/releases/latest/download/open-ontologies-x86_64-unknown-linux-gnu
chmod +x open-ontologies-x86_64-unknown-linux-gnu && mv open-ontologies-x86_64-unknown-linux-gnu /usr/local/bin/open-ontologies

# Docker
docker pull ghcr.io/fabio-rovai/open-ontologies:latest

# From source (Rust 1.85+)
cargo build --release --features embeddings,plugins,sql

Intel macOS, native Windows and the rest: docs/quickstart.md and docs/windows.md.

serve starts an MCP server speaking JSON-RPC over stdin and stdout, so on launch it appears to hang while it waits for a client. That is expected. From a terminal, use the CLI subcommands instead, such as open-ontologies validate <file.ttl>.

Connect it to Claude

Add to ~/.claude/settings.json for Claude Code, or to ~/Library/Application Support/Claude/claude_desktop_config.json for Claude Desktop:

{
  "mcpServers": {
    "open-ontologies": {
      "command": "/path/to/open-ontologies",
      "args": ["serve"]
    }
  }
}

Restart, and the onto_* tools are available. Cursor, Windsurf, Zed and VS Code are in docs/quickstart.md.

What is in the box

120 tools to build, validate, query, diff, lint, version, reason over, align, plan, certify and govern RDF and OWL, over an in-memory Oxigraph store. A default build advertises 112 tools. Eight need an optional Cargo feature and return an error without it: four need embeddings, two need plugins, two need postgres or duckdb. The published binaries and the GHCR image are built with the default feature set, so they do not carry those eight.

The Python package open-ontologies-lite now reasons as well, in pure Python with no Rust toolchain, and its certificates are checked by the same Lean binaries. It is a second engine, and being untrusted costs nothing: the warrant was never in the engine.

tools/horn_differential.py runs both engines and the Lean checker over every RDF document the repository tracks. The two engines are not independent: they run the same algorithm over the same rule table and the Python's comments cite the Rust by file and line, so their agreement is strong evidence against a transcription slip and close to none against a shared misreading of a W3C rule. The independent leg is the Lean checker. The tool prints that caveat next to its agreement count on every run, and docs/lean-certificates.md states it as a limitation.

Alongside them, a marketplace of 33 standard ontologies, clinical crosswalks, semantic embeddings, a lineage audit trail, and a desktop Studio with a virtualized ontology tree, an AI chat panel and a Protégé-style inspector. No JVM. No Protégé.

Documentation

Topic	Link
Quickstart	docs/quickstart.md
Architecture	docs/architecture.md
Derivation certificates and the Lean checkers	docs/lean-certificates.md
Which axioms a conclusion rests on, and provenance semirings	docs/explanation.md
What the Lean proofs assume about the Rust	docs/trusted-computing-base.md
Aeneas at the Rust/Lean boundary: what it proves, and what it costs	docs/aeneas-boundary.md
Which gates a green CI tick actually ran	docs/ci-gates.md
First-order export, TPTP and Common Logic	docs/first-order-export.md
Every reasoning system, and why each was used or refused	docs/reasoning-systems-inventory.md
Design decisions, one rule per file	docs/decisions/
SHIQ reasoning	docs/reasoning.md
Schema alignment	docs/alignment.md
Data pipeline	docs/data-pipeline.md
Ontology lifecycle	docs/lifecycle.md
Locality modules and conservative extensions	docs/modules-and-conservativity.md
Semantic embeddings	docs/embeddings.md
Clinical crosswalks	docs/clinical.md
IES support	ecosystem · alignment · SPARQL examples
Benchmarks	docs/benchmarks.md
Determinism and corrected results	docs/determinism.md
Windows	docs/windows.md
Contributing	CONTRIBUTING.md

Open Ontologies for teams

The engine in this repository is MIT licensed and will stay that way. What it does not give you is somewhere to put the evidence: a place where certificates are kept, where a change to an ontology is reviewed before it ships, and where an auditor can re-verify an answer months later without installing anything.

That is what tesseractsemantics.com is being built for. If you are running ontologies where a wrong answer costs something, it is worth a conversation.

Stack

Rust edition 2024, single binary, no JVM. Oxigraph 0.5 for RDF and SPARQL 1.1. rmcp for MCP over streamable HTTP. SQLite for state, lineage and feedback. Lean 4 v4.33.1 for the checkers, core Lean only, no Mathlib. Tauri 2, React 19 and Tailwind 4 for the Studio. Full table in docs/architecture.md.

Citation

Open Ontologies: Tool-Augmented Ontology Engineering with Stable Matching Alignment. Fabio Rovai, 2026. arXiv:2605.09184
CIVeX: Causal Intervention Verification for Language Agents. Fabio Rovai, 2026. arXiv:2605.09168

CITATION.cff carries machine-readable metadata and powers GitHub's "Cite this repository" button.

License

MIT. Maintained by Fabio Rovai at Tesseract Semantics. If this is useful to you, you can support it through GitHub Sponsors.

Available Tools

42 tools

onto_alignB

Detect alignment candidates (owl:equivalentClass, skos:exactMatch, rdfs:subClassOf) between two ontologies using label similarity, property overlap, parent overlap, instance overlap, restriction patterns, and graph neighborhood. Auto-applies high-confidence matches above threshold.

ParametersJSON Schema

Name	Required	Description
`source`	Yes	Source ontology: inline Turtle content or file path
`target`	No	Target ontology: inline Turtle content or file path. If omitted, aligns against loaded store
`dry_run`	No	If true, return candidates only without inserting triples (default false)
`min_confidence`	No	Minimum confidence threshold for auto-apply (default 0.85)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It mentions auto-applying high-confidence matches and dry_run, but does not disclose permanence of changes, reversibility, authorization needs, or whether the tool is destructive. The write operation (inserting triples) is only implied via dry_run parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose, and avoids redundancy. It is efficient but could be slightly more structured (e.g., separating detection from auto-application). Minor improvement possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the tool's complexity and no output schema or annotations, the description omits return value details, side effects (permanent ontology modification), and guidance on interpreting dry_run results. Missing critical context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with each parameter already described. The description adds context about how min_confidence is used for auto-apply and the purpose of dry_run, but does not significantly extend beyond schema descriptions. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool detects alignment candidates using specific ontology relations (owl:equivalentClass, skos:exactMatch, rdfs:subClassOf) and multiple methods (label similarity, property overlap, etc.), distinguishing it from siblings like onto_map or onto_similarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies this tool is for automatic alignment detection and application, but does not explicitly state when to use it versus alternatives like onto_map (manual mapping) or onto_similarity (similarity computation). No when-not-to-use or alternative recommendations are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_align_feedbackA

Accept or reject an alignment candidate to improve future confidence scoring. Stores feedback in align_feedback table for self-calibrating weights.

ParametersJSON Schema

Name	Required	Description
`accepted`	Yes	Whether the alignment candidate was correct
`source_iri`	Yes	Source class IRI from the alignment candidate
`target_iri`	Yes	Target class IRI from the alignment candidate

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, but the description adequately discloses that feedback is stored in the align_feedback table for self-calibrating weights, indicating a persistent write operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the main action, no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple feedback storage tool with full parameter coverage and no output schema, the description sufficiently explains the action and effect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters have descriptions in the schema (100% coverage). The description adds no new meaning beyond purpose, meeting the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool accepts or rejects alignment candidates to improve confidence scoring, distinguishing it from siblings like 'onto_align' (generates alignments) and 'onto_lint_feedback' (lint feedback).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use after generating alignment candidates, but lacks explicit guidance on when to use vs. alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_applyA

Apply the last plan. Modes: 'safe' (clear+reload, checks monitor), 'force' (ignores monitor), 'migrate' (adds owl:equivalentClass/Property bridges for renames).

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	Apply mode: "safe" (default), "force" (ignores monitor), "migrate" (adds bridges)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses mode behaviors (clear+reload, monitor checks, bridge additions) but fails to mention potential side effects, prerequisites (e.g., existing plan), or error conditions. Without annotations, this coverage is moderate but has gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no extraneous information. The description is front-loaded with the action and immediately provides mode details, making it efficient and scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter set and no output schema, the description covers the tool's core functionality and modes. However, it omits mentions of dependencies (e.g., requires a plan created by onto_plan) and return behavior. Overall sufficient for a straightforward tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers the 'mode' parameter with descriptions, but the tool description adds meaningful context by explaining what each mode does operationally. This enriches the schema, moving above the baseline of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool applies the last plan and details three distinct modes ('safe', 'force', 'migrate') with specific behaviors. It distinguishes itself from siblings by focusing on execution of a plan rather than creation or analysis.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the modes but does not specify when to use this tool versus alternatives like onto_plan or onto_rollback. No explicit conditions or exclusions are provided, leaving the agent to infer usage context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_clearA

Clear all triples from the in-memory ontology store

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries full burden. It clearly states the destructive action of clearing all triples, which implies irreversibility. However, it does not explicitly mention that the action is irreversible or whether it requires special permissions, leaving some behavioral context unclear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded and contains no superfluous information. Every word contributes meaning, meeting the conciseness standard.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters, no output schema, and the action is straightforward, the description fully explains what the tool does. No additional context is necessary for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, and the schema coverage is 100%. According to guidelines, zero parameters baseline is 4. No additional parameter info is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'clear' and resource 'all triples from the in-memory ontology store', clearly distinguishing it from sibling tools like onto_validate or onto_query. There is no ambiguity or tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives, such as onto_rollback or onto_history, nor does it mention any prerequisites or exclusions. Given the many sibling tools, explicit usage context is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_convertB

Convert an RDF file between formats: turtle, ntriples, rdfxml, nquads, trig

ParametersJSON Schema

Name	Required	Description
`to`	Yes	Target format: turtle, ntriples, rdfxml, nquads, trig
`path`	Yes	Path to source RDF file
`output`	No	Optional output file path (if omitted, returns content)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries the burden. It does not disclose side effects (e.g., whether source file is modified, overwriting behavior), required permissions, or error handling. Minimal behavioral context beyond the stated conversion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, direct, no redundant words. Essential information is front-loaded. Excellent conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple conversion tool with no output schema, the description covers the basic purpose and formats. However, it omits details like error conditions, behavior when output file exists, or performance implications. Adequate but with gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description essentially repeats the parameter descriptions (e.g., list of formats matches 'to' schema description). Adds negligible additional meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clear verb 'Convert' and specific resource 'RDF file between formats' with explicit list of supported formats. Well distinguishes from sibling tools like onto_align, onto_validate, etc. which perform different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. Lacks explicit context for selection criteria, such as when format conversion is needed vs other RDF operations like validation or reasoning.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_crosswalkB

Look up clinical crosswalk mappings for a code and system (ICD10, SNOMED, MeSH). Requires data/crosswalks.parquet.

ParametersJSON Schema

Name	Required	Description	Default
`code`	Yes	Clinical code to look up (e.g. "I10")
`source_system`	Yes	Source system (e.g. "ICD10", "SNOMED", "MeSH")

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description only mentions a data file requirement, but does not disclose whether the operation is read-only, has side effects, rate limits, or other behavioral traits. The lookup nature is implied but not explicitly stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence front-loads the purpose, and the second adds a key prerequisite. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema. The description fails to explain what the tool returns (e.g., list of mappings, target codes). For a lookup tool, this is a critical missing detail. Also error handling is absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds some context by listing supported systems, but the schema already provides examples for code and source_system. The added value is marginal.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('look up'), resource ('clinical crosswalk mappings'), and scope ('for a code and system' with specific examples like ICD10, SNOMED, MeSH). It distinguishes this tool from many siblings by focusing on crosswalk mappings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., onto_map, onto_align). Only a prerequisite is mentioned (data/crosswalks.parquet), but no when-not or exclusion criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_diffB

Compare two ontology files and show added/removed triples

ParametersJSON Schema

Name	Required	Description	Default
`new_path`	Yes	Path to the new/modified ontology file
`old_path`	Yes	Path to the old/original ontology file

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the basic comparison action without revealing side effects, prerequisites, or whether the tool is read-only (expected for a diff). The agent lacks information on error handling, performance, or requirements.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no redundancy. It is appropriately concise for a simple tool, though it could benefit from a slight expansion on output or usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 parameters, no output schema), the description is minimally adequate. However, it lacks details such as the format of the diff output (e.g., plain triples, formatted table) and any constraints like file format requirements. This leaves gaps for an agent interpreting the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes both parameters (new_path, old_path) with 100% coverage. The description adds no new semantic meaning beyond 'ontology files' which is implied by the tool name. Baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'compare' and the resource 'ontology files', and specifies the output 'show added/removed triples'. This distinguishes it from siblings like onto_align, onto_drift, or onto_history, which serve different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (when comparing two ontology versions) but provides no explicit guidance on when not to use it or alternatives. For example, it does not explain how it differs from onto_drift or onto_history.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_dl_checkA

Check if one class is subsumed by another using DL tableaux reasoning. Returns whether sub_class is a subclass of super_class, with justification.

ParametersJSON Schema

Name	Required	Description	Default
`sub_class`	Yes	IRI of the sub-class (the more specific class)
`super_class`	Yes	IRI of the super-class (the more general class)

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the reasoning method (DL tableaux) and output format (boolean with justification), suggesting a read-only operation. However, it does not explicitly state that it is non-destructive, requires no special permissions, or any potential side effects like loading reasoners.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences. The first sentence immediately states the core purpose, and the second clarifies the return value. Every word is functional, and there is no redundancy. It is well-structured and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (two parameters, no output schema), the description is complete. It explains what the tool does, the reasoning method, and what it returns (boolean with justification). No additional information is necessary for an AI agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description text for parameters is identical to the schema descriptions, adding no new meaning beyond what the schema already provides. Thus, the description does not enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: checking if one class (sub_class) is subsumed by another (super_class) using DL tableaux reasoning. It specifies what it returns (boolean with justification) and the verb 'Check' precisely indicates the action. The sibling tools like onto_reason, onto_diff are distinct, so this tool's niche is well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for subsumption checking, but it does not explicitly state when to use this tool over alternatives (e.g., onto_reason for general reasoning) or when not to use it. No usage context or prerequisites are mentioned, leaving some ambiguity for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_dl_explainA

Explain why a class is unsatisfiable using DL tableaux reasoning. Returns an explanation trace showing the logical contradictions that make the class impossible to instantiate.

ParametersJSON Schema

Name	Required	Description	Default
`class_iri`	Yes	IRI of the class to explain unsatisfiability for

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must fully disclose behavior. It states that the tool returns an explanation trace, but it does not mention whether the tool is read-only, requires authentication, or has any side effects. The description is minimal and lacks details about error handling or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, consisting of two sentences that front-load the core purpose and output. Every word adds value, and there is no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a simple single-parameter interface with no output schema. The description covers the core functionality and output, but it does not mention that the class must be unsatisfiable for the tool to produce meaningful output, nor does it explain error scenarios. It is adequate but not thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage for the single parameter 'class_iri', already describing it as 'IRI of the class to explain unsatisfiability for.' The description adds no additional semantic value beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: 'Explain why a class is unsatisfiable using DL tableaux reasoning.' It also describes the output as 'an explanation trace showing the logical contradictions.' This clearly distinguishes it from siblings like onto_dl_check, which likely checks satisfiability without explanation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description indicates when to use the tool (to explain unsatisfiability) but does not provide guidance on when not to use it or what alternatives exist. For instance, if the class is satisfiable, this tool may not be applicable, but that is not mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_driftB

Detect drift between two ontology versions. Returns added/removed terms, likely renames with confidence scores, and drift velocity.

ParametersJSON Schema

Name	Required	Description	Default
`version_a`	Yes	First version as inline Turtle
`version_b`	Yes	Second version as inline Turtle

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the burden. It discloses that the tool returns added/removed terms, renames with confidence, and drift velocity, implying a read-only analysis. However, it does not confirm lack of side effects or mention any permissions needed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads purpose and return details. Every word contributes value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has two parameters with good schema descriptions, and the return behavior is summarized. However, it lacks context on input format constraints, size limits, or examples, which would be useful for a detection tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema coverage is 100% with descriptions for both parameters specifying they are Turtle strings. The description adds no further meaning beyond the schema, meeting the baseline for complete schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Detect' and resource 'drift between two ontology versions', and lists return types. It distinguishes from siblings like onto_diff by focusing on drift (including renames and velocity), but does not explicitly differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like onto_diff or onto_align. The description omits context such as prerequisites or constraints on input size or validity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_embedB

Generate text + structural Poincaré embeddings for all classes in the loaded ontology. Requires the embedding model (run open-ontologies init to download). Embeddings enable semantic search via onto_search and improve alignment accuracy.

ParametersJSON Schema

Name	Required	Description	Default
`struct_dim`	No	Structural embedding dimension. Default: 32
`struct_epochs`	No	Structural training epochs. Default: 100

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits, but it only says 'generate' without stating whether this is idempotent, destructive, or requires permissions. It does not mention what happens to existing embeddings or if there are side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences. The first sentence states the main function, and the second adds a prerequisite and links to related tools, avoiding unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description should hint at return values or side effects. It mentions enabling onto_search and alignment but does not clarify what the tool returns or if it modifies the ontology state. This leaves some gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters (struct_dim, struct_epochs). The description does not add any additional parameter semantics beyond what the schema already provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('generate') and the specific resource ('text + structural Poincaré embeddings for all classes in the loaded ontology'), distinguishing it from sibling tools like onto_search (which uses embeddings) and onto_align (which improves alignment).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool versus alternatives. The only prerequisite mentioned is needing the embedding model, but no when-to-use or when-not-to-use context is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_enforceA

Enforce design patterns on the loaded ontology. Built-in packs: 'generic' (orphan classes, missing domain/range/label), 'boro' (BORO 4D patterns), 'value_partition' (disjoint/covering checks). Also runs any custom rules stored for the pack.

ParametersJSON Schema

Name	Required	Description	Default
`rule_pack`	Yes	Rule pack to enforce: "generic", "boro", "value_partition", or custom pack name

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It mentions running packs and custom rules but fails to disclose whether the tool is read-only or modifies the ontology, nor does it discuss prerequisites, side effects, or error conditions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with core purpose, no redundancy, every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given one parameter and no output schema, the description covers basic usage but omits what the tool returns or whether it mutates the ontology, leaving important gaps for an enforcement tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning beyond the input schema by detailing what each built-in pack checks (e.g., orphan classes for generic, BORO patterns for boro, disjoint/covering for value_partition), which is not in the schema description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it enforces design patterns on the loaded ontology, listing specific built-in packs and custom rules. It distinguishes from siblings by focusing on enforcement rather than validation or linting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when one wants to enforce patterns, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_enforce_feedbackA

Accept or dismiss an enforce violation to improve future enforce runs. Dismissed violations are suppressed after 3 dismissals. Stores feedback for self-calibrating compliance.

ParametersJSON Schema

Name	Required	Description
`entity`	Yes	The entity IRI that triggered the violation
`rule_id`	Yes	The enforce rule ID (e.g. "orphan_class", "missing_domain", "missing_range", "missing_label", or custom rule ID)
`accepted`	Yes	true = this is a real violation, false = dismiss/override

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses key behaviors: dismissals are suppressed after 3 occurrences, and feedback is stored for self-calibration. With no annotations provided, this adequately informs the agent about side effects and persistence, though acceptance behavior could be more detailed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is exceptionally concise, using three short sentences to convey purpose, behavior, and storage effects. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the description covers core purpose and behavior, it lacks mention of return values (no output schema) and omits comparisons to similar feedback tools among siblings. For a simple feedback tool, it is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All three parameters are fully described in the input schema (100% coverage). The description adds no new meaning beyond the schema, placing it at the baseline score for parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool accepts or dismisses enforce violations to improve future enforce runs. It uniquely identifies the resource as 'enforce violation', distinguishing it from sibling tools like onto_lint_feedback or onto_align_feedback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage is implied by the name and action, but there is no explicit guidance on when to use this tool versus alternatives like onto_enforce or other feedback tools. No exclusions or prerequisites are mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_enrichB

Enrich an ontology class with a SKOS mapping triple from the clinical crosswalks.

ParametersJSON Schema

Name	Required	Description
`code`	Yes	Clinical code to map to
`system`	Yes	Code system (e.g. "ICD10")
`class_iri`	Yes	IRI of the ontology class to enrich

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It only states the action (adds a triple) but does not disclose whether it is destructive, idempotent, requires prior steps, or what the effect on existing data is. Behavioral traits like side effects are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single concise sentence that efficiently conveys the core action. No extraneous words, but could possibly add more context without becoming verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description is too sparse. It lacks explanation of the return value, what a 'SKOS mapping triple' is, and how the enrichment affects the ontology. For a tool with three required parameters, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for all three parameters. The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Enrich', a specific resource 'ontology class', and what is added 'SKOS mapping triple from the clinical crosswalks'. This provides a distinct purpose that differentiates it from sibling tools like onto_map or onto_align.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use or when not to use this tool. It does not mention alternatives or prerequisites, leaving the agent to infer usage without explicit direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_extendA

Convenience pipeline: ingest data → validate with SHACL → run OWL reasoning, all in one call. Combines onto_ingest + onto_shacl + onto_reason.

ParametersJSON Schema

Name	Required	Description
`format`	No	Data format (auto-detected if omitted)
`shapes`	No	Path to SHACL shapes file or inline Turtle
`mapping`	No	Mapping config (inline JSON or file path)
`base_iri`	No	Base IRI for generated instances
`data_path`	Yes	Path to the data file
`inline_shapes`	No	If true, treat shapes as inline Turtle
`inline_mapping`	No	If true, treat mapping as inline JSON
`reason_profile`	No	Reasoning profile (rdfs, owl-rl). Omit to skip reasoning.
`stop_on_violations`	No	If true (default), stop pipeline on SHACL violations

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It states the pipeline sequence but does not disclose behavioral traits such as atomicity, rollback behavior, side effects on data state, permissions required, or any constraints beyond the parameter schema. The 'stop_on_violations' parameter is not explained in the description, leaving the agent unaware of default behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy: first sentence explains the pipeline purpose and sequence, second lists the component tools. Every word earns its place. Highly concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is minimal; for a tool with 9 parameters and no output schema, it could provide more context about the pipeline's behavior (e.g., whether it's atomic, what happens on violation beyond the parameter, default reasoning profile). However, it gives a clear overview of the combined steps, which may be sufficient if the agent is familiar with the individual tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (all 9 parameters have descriptions), so baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter interplay or typical values. The description is generic and does not enhance parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is a convenience pipeline combining ingest, SHACL validation, and OWL reasoning in one call. It explicitly names the three sub-tools (onto_ingest, onto_shacl, onto_reason), distinguishing it from sibling tools that perform these steps individually.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage as a 'convenience pipeline' for combining steps, but does not explicitly state when to prefer it over individual tools, nor does it provide guidance on when not to use it (e.g., when fine-grained control is needed). The guidance is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_historyA

List all saved ontology version snapshots

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description lacks behavioral details such as authentication requirements, destructive potential, pagination, or any effect of the operation. With no annotations to supplement, the agent must infer safety and side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that conveys the core function without any unnecessary words. It is appropriately concise and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description is clear but incomplete: it does not specify what information is returned (e.g., snapshot names, dates). This could leave an AI agent without expectations for the output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Since the tool has no parameters, the input schema alone covers 100% of parameter information. The description does not need to add parameter semantics, and the baseline for zero parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'list' and the resource 'saved ontology version snapshots', effectively differentiating it from sibling tools like onto_save (which creates snapshots) and onto_load (which loads snapshots).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as onto_version or onto_status. The description merely states what the tool does without any exclusions or contextual cues.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_importB

Resolve and load all owl:imports from the currently loaded ontology

ParametersJSON Schema

Name	Required	Description	Default
`max_depth`	No	Resolve and load all owl:imports from the currently loaded ontology

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description only states the basic action without disclosing side effects (e.g., whether it modifies the ontology, requires network access, or can fail). With no annotations, the agent lacks behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fails to explain the effect of the operation (e.g., whether imports are added to the current ontology) or the return value. This leaves a significant gap for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (parameter description identical to tool description). The description adds no extra meaning beyond the schema, so baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Resolve and load all owl:imports from the currently loaded ontology'. It specifies the verb (resolve and load) and the resource (owl:imports), and distinguishes it from siblings like onto_import_schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like onto_load or onto_ingest. The description does not mention any prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_import_schemaA

Import a PostgreSQL database schema as an OWL ontology. Introspects tables, columns, primary keys, and foreign keys, then generates OWL classes, datatype/object properties, and cardinality restrictions.

ParametersJSON Schema

Name	Required	Description	Default
`base_iri`	No	Base IRI for generated classes (default: http://example.org/db/)
`connection`	Yes	Database connection string (e.g. postgres://user:pass@host/db)

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It indicates a read (introspect DB) and write (generate OWL) operation, but does not mention whether the database is modified, permissions required, or if the ontology overwrites existing data. Some transparency but gaps remain.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences efficiently convey the tool's purpose and capabilities. However, it omits essential info like output format or return value, which could be added without harming conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters and no output schema, the description should explain the output (e.g., ontology IRI) and prerequisites (e.g., DB access). It lacks this context, making it incomplete for an import tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions (base_iri, connection). The tool description reinforces the PostgreSQL context but adds no extra meaning beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool imports a PostgreSQL database schema as an OWL ontology, listing specific introspection details (tables, columns, PKs, FKs) and generated OWL constructs (classes, properties, cardinality restrictions). This clearly differentiates it from generic siblings like onto_import or onto_convert.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when a PostgreSQL database schema needs conversion to OWL, but lacks explicit when-not-to-use guidance or alternatives among siblings. No exclusions or comparison to onto_import or onto_ingest is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_ingestB

Parse a structured data file (CSV, JSON, NDJSON, XML, YAML, XLSX, Parquet) into RDF triples and load into the ontology store. Optionally uses a mapping config to control field-to-predicate mapping.

ParametersJSON Schema

Name	Required	Description
`path`	Yes	Path to the data file (CSV, JSON, NDJSON, XML, YAML, XLSX, Parquet)
`format`	No	Data format (auto-detected from extension if omitted): csv, json, ndjson, xml, yaml, xlsx, parquet
`mapping`	No	Mapping config as JSON string or path to mapping JSON file
`base_iri`	No	Base IRI for generated instances (default: http://example.org/data/)
`inline_mapping`	No	If true, treat mapping as inline JSON (default: false = file path)

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must fully disclose behavioral traits. It states parsing and loading but does not address whether existing data is overwritten, transactional behavior, error handling, or authorization needs. Incomplete for a data ingestion tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, highly efficient. Front-loaded with core purpose, followed by optional capability. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and 5 parameters (1 required), the description covers main functionality but lacks details on return behavior, persistence, or integration with ontology store lifecycle. Adequate but could be more complete for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds minimal context beyond schema (e.g., 'mapping config controls field-to-predicate mapping'), which aligns with schema descriptions. No significant new meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb (parse and load) and resource (structured data file into RDF triples in ontology store). It distinguishes from siblings like onto_import (which likely imports ontologies) and onto_load (loading existing triples) by specifying parsing from multiple formats and optional mapping.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like onto_import, onto_load, or onto_convert. The description does not mention when not to use it or provide explicit context for selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_lineageA

Get the compact lineage log for the current or specified session.

ParametersJSON Schema

Name	Required	Description	Default
`session_id`	No	Session ID to query (omit for current session)

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description implies read-only ('Get'), but without annotations this is insufficient. No mention of side effects or state changes, which is acceptable for a simple retrieval but could be more explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that clearly conveys the tool's purpose without any unnecessary words or information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema), the description provides enough information for an agent to use it correctly, though it could mention that it does not modify data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema description for session_id is sufficient; the description adds no additional meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'Get' and clear resource 'compact lineage log for the current or specified session', distinguishing it from sibling tools like onto_align, onto_apply, etc., which perform different operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implicitly guides when to use (when lineage log is needed) and how to specify session, but lacks explicit alternatives or exclusions. Still clear for a straightforward read tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_lintA

Check an ontology for quality issues: missing labels, comments, domains, ranges

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes	Path to RDF file to lint, OR inline Turtle content
`inline`	No	If true, treat input as inline content

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

While 'check' implies a non-destructive read operation, the description does not explicitly state that no modifications are made, nor does it mention any authentication or performance considerations. With no annotations, the description provides minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no redundant information. It is front-loaded with the verb and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description tells what the tool checks but does not describe the output format or whether it modifies the ontology. Given no output schema, some information about return values would improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already describes both parameters. The description adds general context about the tool's purpose (what issues it checks) but does not enhance the semantics of individual parameters beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's action ('Check') and resource ('ontology for quality issues'), listing specific issues (missing labels, comments, domains, ranges). This distinguishes it from sibling tools like onto_align or onto_convert.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, such as onto_lint_feedback. The description does not mention any prerequisites or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_lint_feedbackA

Accept or dismiss a lint issue to improve future lint runs. Dismissed issues are suppressed after 3 dismissals. Stores feedback for self-calibrating severity.

ParametersJSON Schema

Name	Required	Description
`entity`	Yes	The entity IRI that triggered the lint issue
`rule_id`	Yes	The lint rule ID (e.g. "missing_label", "missing_comment", "missing_domain", "missing_range")
`accepted`	Yes	true = this is a real issue, false = dismiss/ignore

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It reveals that dismissals are suppressed after 3 occurrences and that feedback is used for self-calibrating severity. This goes beyond basic action but omits details like persistence or immediate effect of acceptance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the action, then behavioral detail. No unnecessary words; highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple feedback tool, the description explains behavior (suppression threshold, self-calibration). However, it lacks mention of return value or confirmation, which would be helpful given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all parameters. The description adds no new meaning about parameters, merely aligning with 'accepted' via 'Accept or dismiss'. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Accept or dismiss a lint issue to improve future lint runs.' It specifies the action (accept/dismiss) and resource (lint issue), distinguishing it from sibling 'onto_lint' which runs lint checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage context (providing feedback for calibration) but does not explicitly state when to use this versus alternatives like 'onto_enforce_feedback'. No when-not or exclusions are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_loadC

Load an RDF file into the in-memory ontology store for querying

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to RDF file to load into the in-memory store

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It does not disclose side effects (e.g., overwriting existing data), memory implications, or access requirements. Minimal behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no extraneous text. It is concise, though it could benefit from additional structure (e.g., separated usage notes).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity (single param, no output schema) and the presence of many sibling tools, the description is incomplete. It lacks behavioral context (e.g., destructive behavior, memory limits) that is critical given no annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with the 'path' parameter described as 'Path to RDF file...' in both schema and description. The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool loads an RDF file into the in-memory store for querying. However, it does not differentiate from siblings like onto_import or onto_ingest, which may perform similar actions.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The description implies usage for loading files into memory but lacks explicit context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_lockA

Lock IRIs to prevent removal during plan/apply. Locked IRIs will show as violations in plan output.

ParametersJSON Schema

Name	Required	Description	Default
`iris`	Yes	IRIs to lock (prevent removal)
`reason`	No	Reason for locking

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses that locked IRIs prevent removal and appear as violations in plan output. Missing information on reversibility or side effects, but the main effect is clear.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with front-loaded purpose. No redundant words, every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should explain return values but does not. Captures key behavioral aspect (violations) but lacks details on reversibility, permissions, or what the function returns. Sibling context is clear but tool could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers both parameters with descriptions (100% coverage). Description adds context about purpose and outcome, but does not significantly enhance parameter understanding beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states action ('Lock IRIs'), purpose ('prevent removal during plan/apply'), and describes output behavior ('show as violations in plan output'). Distinguishes from siblings like onto_plan and onto_apply.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage before plan/apply, but no explicit when-to-use or when-not-to-use. No mention of alternatives or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_mapA

Generate a mapping config by inspecting a data file's schema against the currently loaded ontology. Returns a JSON mapping that can be reviewed and passed to onto_ingest.

ParametersJSON Schema

Name	Required	Description
`format`	No	Data format (auto-detected if omitted)
`data_path`	Yes	Path to sample data file to generate mapping for
`save_path`	No	Optional path to save the generated mapping config

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must cover behaviors. It mentions returning a JSON mapping but does not disclose if it modifies state (e.g., saving to disk), prerequisites (ontology must be loaded), or side effects. Partially transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no fluff. First sentence describes action and process; second sentence explains output and recommended next step. Highly efficient and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Adequately explains the tool's purpose and place in a workflow (generate mapping, then ingest). Lacks details about the output JSON structure, but given the tool's simplicity and schema coverage, it is sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions. The description adds marginal value (e.g., workflow hint about onto_ingest) but does not significantly enhance parameter understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Generate', resource 'mapping config', and process 'inspecting a data file's schema against the currently loaded ontology'. Distinguishes from siblings like onto_ingest and onto_align.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage: when you need a mapping config for data ingestion. Mentions output can be passed to onto_ingest, providing workflow context. Lacks explicit when-not-to-use or comparison to alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_monitorA

Run active monitoring watchers. Optionally add new watchers via inline JSON. Returns ok/alert/blocked status with details.

ParametersJSON Schema

Name	Required	Description	Default
`watchers`	No	Inline JSON array of watchers to add, or omit to just run existing watchers

TDQS

A3.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description reveals the return status ('ok/alert/blocked') and the ability to add watchers. However, it does not disclose behavioral aspects like side effects, destructive nature, or authentication requirements, which are important given the absence of annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with three short sentences that front-load the core purpose. Every sentence adds value with no redundancy or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no output schema, the description covers the main functionality and return type. It lacks details on JSON formatting for new watchers and precise return fields, but is otherwise complete enough for basic use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers 100% of parameters and already explains the 'watchers' parameter. The description merely echoes the schema's information without adding new semantic meaning, so baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the action ('run active monitoring watchers') and the resource, with optional adding of new watchers. It distinguishes itself from siblings like onto_monitor_clear by focusing on running and adding watchers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., onto_monitor_clear). There is no mention of prerequisites or scenarios where this tool is preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_monitor_clearA

Clear the monitor blocked flag, allowing apply operations to proceed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses the action (clearing a flag) and its effect (enabling apply operations), but lacks details on side effects, reversibility, or permission requirements. Without annotations, more behavioral context would be beneficial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one concise sentence that is front-loaded with the verb and resource. Every word adds value, with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no parameters and no output schema, the description adequately explains the core function and its immediate effect. However, it could be more complete by defining the 'monitor blocked flag' or prerequisites. Overall, it's sufficient for a simple operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema coverage is 100% trivially. The description adds semantic value by naming the 'monitor blocked flag', but does not elaborate on the flag's nature or scope. A baseline of 4 is appropriate given no parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Clear the monitor blocked flag') and the consequence ('allowing apply operations to proceed'). It distinguishes itself from sibling tools like 'onto_monitor' and 'onto_clear' by specifying the particular flag being cleared.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies that the tool should be used when the monitor is blocked and apply operations are hindered. However, it does not explicitly mention when not to use it or compare with alternatives like 'onto_clear' or 'onto_monitor'.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_planA

Terraform-style plan: diff current store against proposed Turtle. Shows added/removed classes/properties, blast radius, risk score, and locked IRI violations.

ParametersJSON Schema

Name	Required	Description	Default
`new_turtle`	Yes	New ontology as inline Turtle content

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It explains the tool's purpose and outputs but does not disclose whether it is read-only or modifies state, nor does it mention authentication or rate limits. The 'blast radius' and 'risk score' hint at analysis without side effects, but not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently conveys purpose, key outputs, and analogy. No wasted words. Front-loaded with the 'Terraform-style plan' concept.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema or annotations, the description adequately covers tool behavior and outputs (added/removed classes, blast radius, risk score, IRI violations). Missing details about output format or connection requirements, but sufficient for a plan tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only one parameter (new_turtle) with 100% schema coverage. Description mentions 'proposed Turtle' but adds no new meaning beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it performs a Terraform-style plan diffing the current store against proposed Turtle. It lists specific outputs: added/removed classes/properties, blast radius, risk score, and locked IRI violations. This differentiates it from siblings like onto_diff or onto_apply.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for planning before applying changes, but does not explicitly state when to use over alternatives or provide exclusion criteria. No guidance on prerequisites or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_pullB

Fetch an ontology from a remote URL or SPARQL endpoint and load it into the store

ParametersJSON Schema

Name	Required	Description
`url`	Yes	Remote URL or SPARQL endpoint to fetch ontology from
`query`	No	Optional SPARQL CONSTRUCT query (required if sparql=true)
`sparql`	No	If true, treat url as a SPARQL endpoint and run a CONSTRUCT query

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description must carry the full burden. It mentions fetching and loading, but does not disclose side effects like overwriting, merging, or required permissions. Lacks transparency on destructive potential.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence and front-loaded, but it is too brief given the tool has 3 parameters and multiple modes. More detail would improve usability without losing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Missing important context such as what 'load into the store' entails (replace, merge?), error conditions, and relation to other tools. No output schema, so return values are unexplained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter. The tool description adds no value beyond the schema, merely restating the purpose. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch' and the resource 'ontology', and specifies two modes (remote URL or SPARQL endpoint). It distinguishes from sibling tools like onto_import or onto_query by mentioning loading into the store.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives such as onto_import or onto_query. No mention of when not to use it or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_pushC

Push the current ontology store to a remote SPARQL endpoint

ParametersJSON Schema

Name	Required	Description	Default
`graph`	No	Optional named graph IRI
`endpoint`	Yes	Remote SPARQL endpoint URL

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, this description carries full responsibility for behavioral disclosure. It only says 'Push', implying a write operation, but provides no details on safety, authentication requirements, or whether data is replaced/merged.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words. It is concise but could be slightly more descriptive without losing brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description should provide more context about consequences, error handling, and success criteria. It is incomplete for a meaningful tool interaction.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters (endpoint and graph) are described in the schema with 100% coverage. The description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'Push' and specifies the resource: 'current ontology store to a remote SPARQL endpoint'. It clearly states the action and target, making the tool's purpose easy to grasp.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks any guidance on when to use or avoid this tool. There is no mention of alternatives like onto_pull or conditions for using onto_push, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_queryC

Run a SPARQL query against the loaded ontology store

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SPARQL query string

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description does not disclose key behavioral traits such as whether the query is read-only, authentication requirements, performance implications, or error handling. With no annotations provided, the description should cover these aspects, but it only states the basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that communicates the core purpose efficiently. It is front-loaded and contains no unnecessary words or details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, no output schema), the description is incomplete. It does not mention the format of the returned results, potential errors, or how to handle large query outputs. An AI agent would lack context on what to expect from the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema defines the 'query' parameter with a description ('SPARQL query string'), achieving 100% coverage. The description adds no additional information beyond the schema, so it meets the baseline but does not exceed it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('run a SPARQL query') and the target ('against the loaded ontology store'). It is specific and distinct from siblings that perform other operations, though it does not explicitly differentiate from similar query tools like onto_search or onto_stats.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The description does not mention any prerequisites, exclusions, or contexts where this tool is inappropriate. This leaves the agent without decision criteria for tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_reasonA

Run inference over the loaded ontology. Profiles: 'rdfs' (subclass, domain/range), 'owl-rl' (+ transitive/symmetric/inverse, sameAs, equivalentClass), 'owl-rl-ext' (+ someValuesFrom, allValuesFrom, hasValue, intersectionOf, unionOf), 'owl-dl' (Full OWL2-DL SHOIQ tableaux: satisfiability, classification, qualified number restrictions with node merging, inverse/symmetric roles, functional properties, parallel agent-based classification, explanation traces, ABox reasoning). Materializes inferred triples.

ParametersJSON Schema

Name	Required	Description	Default
`profile`	No	Reasoning profile: rdfs (default), owl-rl
`materialize`	No	If true (default), add inferred triples to the store. If false, dry-run only.

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so the description carries full burden. It describes that inferred triples are materialized by default and dry-run option, but does not detail performance implications or side effects like locking.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is informative and front-loaded with purpose, but slightly verbose in listing profiles; every sentence adds value, though could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains the primary outcome (materialized triples). It covers profiles and dry-run, but could mention prerequisites like an already loaded ontology.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers both parameters (100% coverage), and description adds extra meaning by explaining the default for materialize and detailing the capabilities of each profile beyond the schema's minimal description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Run inference over the loaded ontology' and enumerates specific reasoning profiles, distinguishing it from sibling tools like onto_query or onto_validate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for each profile (rdfs, owl-rl, etc.) and the materialize option, but does not explicitly state when not to use this tool or mention alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_rollbackB

Restore the ontology store to a previously saved version

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes	Version label to restore

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It states 'Restore' implying a mutation, but it does not explain whether it overwrites current state, requires authorization, or is reversible. The description is too brief to provide adequate transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, which is concise, but it sacrifices important context. While it is front-loaded, it lacks depth needed for a mutation tool. It earns a 3 as it is not overly verbose but could be more informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (restoring ontology store), the description is incomplete. It does not specify behavior like overwriting versus merging, success/failure conditions, or output. The single param 'label' is described in schema, but no return value or side effects are mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for the only parameter ('label'). The description adds no additional meaning beyond the schema's existing description of 'Version label to restore', so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Restore' and the resource 'ontology store', and specifies it restores to a previously saved version. This distinguishes it from sibling tools like onto_save (save) and onto_version (view versions).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing saved versions), the need for a lock, or situations where restoration may be inappropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_saveC

Save the current ontology store to a file

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Output file path
`format`	No	Format: turtle, ntriples, rdfxml, nquads, trig

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description bears full burden. It only states 'save', but does not disclose whether the operation is destructive, if it overwrites existing files, or any side effects on the ontology store. Minimal behavioral information.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words. However, it could be expanded with more context while remaining concise. No structure issues.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema and the description is very minimal. It does not mention return values, error conditions, or if the file is created/overwritten. Given the lack of annotations, more detail is needed for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% description coverage for both parameters (format and path), so schema already provides meaning. The description adds 'current ontology store' context but no additional semantics beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it saves the current ontology store to a file, using specific verb and resource. However, it does not differentiate from sibling tools like onto_export or onto_convert, which might have similar functionality.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like onto_load or onto_export. There is no mention of prerequisites, constraints, or typical use cases.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_searchA

Semantic search over the loaded ontology using natural language. Returns the most similar classes by text meaning, structural position, or both. Requires onto_embed to have been run first.

ParametersJSON Schema

Name	Required	Description
`mode`	No	Search mode: "text", "structure", or "product". Default: "product"
`alpha`	No	Weight for text vs structure in product mode (0.0-1.0). Default: 0.5
`query`	Yes	Natural language query
`top_k`	No	Number of results. Default: 10

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so description carries full burden. It discloses that it performs semantic search and returns similar classes, but does not explicitly state that it is read-only or clarify other behavioral traits like object modification or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences, front-loaded with core purpose. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description adequately covers tool behavior and return value ('most similar classes'), plus prerequisite. With no output schema, it provides sufficient context for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 100% coverage with descriptions for all 4 parameters. Description adds context about the embedding dependency but does not enhance parameter meaning beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'semantic search over the loaded ontology using natural language', specifying verb and resource. It distinguishes from sibling tools like onto_query and onto_reason by focusing on semantic similarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states prerequisite 'Requires onto_embed to have been run first', providing clear usage context. However, it does not mention when not to use this tool or suggest alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_shaclA

Validate the loaded ontology data against SHACL shapes. Checks cardinality (minCount/maxCount), datatypes, and class constraints. Returns a conformance report with violations.

ParametersJSON Schema

Name	Required	Description	Default
`inline`	No	If true, treat shapes as inline Turtle content
`shapes`	Yes	Path to SHACL shapes file OR inline SHACL Turtle content

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It accurately discloses the validation behavior and return value (conformance report with violations). However, it does not explicitly state side effects (e.g., no data modification) or error conditions, but the read-only nature is implied.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences: the first states purpose and scope, the second adds key details. No redundant or extraneous information. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the tool's action, constraints checked, and return type. Since there is no output schema, mentioning the conformance report is helpful. It could mention error handling or required state (loaded ontology), but it is adequate for a validation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%; both parameters have descriptions that explain their role. The description adds general context but no additional meaning beyond what the schema already provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Validate', the resource 'loaded ontology data against SHACL shapes', and specifies the constraints checked (cardinality, datatypes, class constraints). This provides a specific purpose that distinguishes it from generic validation tools like onto_validate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for SHACL-based validation by naming the constraint types, but it does not explicitly state when to use this tool instead of alternatives like onto_validate or onto_validate_clinical, nor does it mention exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_similarityB

Compute embedding similarity between two IRIs — returns cosine similarity (text), Poincaré distance (structural), and product score.

ParametersJSON Schema

Name	Required	Description	Default
`iri_a`	Yes	First IRI
`iri_b`	Yes	Second IRI

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of disclosure. It does not state whether the tool is read-only or has side effects. While it likely is a read-only computation, this is not explicitly communicated, leaving behavioral ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the action and return values. Every word earns its place; there is no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without an output schema, the description lists the three return scores, which is helpful. However, it does not explain what 'product score' means, nor does it mention prerequisites (e.g., that embeddings must exist). For a tool with no annotations and no output schema, the description is adequate but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both parameters described as 'First IRI' and 'Second IRI'. The description adds no additional meaning beyond the schema, such as expected format, origin, or constraints. Baseline 3 applies as schema already does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool computes embedding similarity between two IRIs and specifies the return types (cosine similarity, Poincaré distance, product score). The verb 'compute' plus resource 'embedding similarity' is specific and distinguishes it from sibling tools like onto_align or onto_diff.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives is provided. The description only states what it does, without mentioning prerequisites, when not to use it, or comparing to siblings like onto_align or onto_diff. This leaves the agent to infer usage from the name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_statsA

Get statistics about the loaded ontology (triple count, classes, properties, individuals)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description does not disclose behavioral traits such as performance implications, side effects, or limitations. For a statistics tool, it should mention if computation is resource-intensive or if results are cached.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence front-loads the action and outcome. No extraneous words; each element is essential.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple stateless retrieval with no parameters, the description is adequate. However, it does not specify the output format (e.g., JSON structure) or whether it reflects current state after recent changes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has no parameters, so schema coverage is 100%. The description adds value by enumerating the statistics returned (triple count, classes, etc.), which is not evident from the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Get statistics about the loaded ontology' and lists example metrics (triple count, classes, properties, individuals). This distinguishes it from sibling tools like onto_load or onto_apply.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly defines when to use this tool (to obtain ontology overview). Although no explicit comparison to siblings, the zero-parameter simplicity and clear outcome make usage obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_statusA

Returns health status of the Open Ontologies server

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. It states it 'returns health status', implying a read-only operation, but does not disclose any additional behavioral traits such as response format or potential side effects. Adequate for a simple status check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, no unnecessary words. Efficient and front-loaded with the key action and resource.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no parameters, no output schema), the description is sufficient. Could optionally mention expected response format, but not essential for understanding the tool's purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has zero parameters, so description adds no parameter details beyond schema. Baseline score of 4 is appropriate since there are no parameters to document.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description uses specific verb 'Returns' and identifies resource 'health status of the Open Ontologies server'. Clearly distinguishes from sibling tools which focus on specific operations like align, convert, or import.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives, but the purpose is self-evident as a health check with no parameters. Lacks mention of using it before other operations to confirm server status.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_validateA

Validate RDF/OWL syntax. Accepts a file path or inline Turtle content.

ParametersJSON Schema

Name	Required	Description	Default
`input`	Yes	Path to an RDF file OR inline Turtle content
`inline`	No	If true, treat input as inline content rather than a file path

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description covers input modes but omits side effects, auth needs, or return behavior. Validation is implied non-destructive but not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, 10 words, efficiently communicates purpose and input modes with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Lacks return value specification (e.g., validation success/failure, error details). With no output schema, agents need to infer output meaning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no new meaning beyond what the schema already provides (input types).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states verb 'Validate' and resource 'RDF/OWL syntax', distinguishing it from siblings like onto_lint, onto_shacl, and onto_dl_check which focus on different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage when file path or inline Turtle content needs syntax validation, but does not explicitly exclude alternatives or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_validate_clinicalA

Validate all class labels in the loaded ontology against clinical crosswalk data. Shows which terms match known clinical codes.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must convey behavior. It states validation and matching display, but does not disclose whether the tool is read-only, what happens if the ontology is not loaded or crosswalk data is missing, or any side effects. The description is somewhat transparent but lacks depth.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences with no redundancy. Every word adds value, clearly stating the action and outcome.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters, the description covers the core purpose and result. However, it lacks context on prerequisites (e.g., loaded ontology and crosswalk data) and output format. Complete enough for basic use but could be more thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, and schema coverage is trivially 100%. The description adds no parameter information, but none is needed. Per guidelines, baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the action ('Validate all class labels... against clinical crosswalk data') and the specific resource ('loaded ontology'). It also indicates what the output shows ('which terms match known clinical codes'), distinguishing it from sibling tools like onto_validate which does general validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case (clinical crosswalk validation) but provides no explicit guidance on when to use this tool versus alternatives like onto_validate or onto_crosswalk. No prerequisites, exclusions, or when-not-to-use information is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

onto_versionB

Save a named snapshot of the current ontology store

ParametersJSON Schema

Name	Required	Description	Default
`label`	Yes	Version label (e.g. "v1.0", "draft-2026-03-09")

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, and the description does not disclose behavioral traits such as whether existing labels are overwritten, whether the operation is reversible, or what the return value is. The agent gains minimal insight into side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no unnecessary words. It efficiently conveys the core action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter structure and lack of output schema or annotations, the description is adequate but not thorough. It does not mention the return value, potential conflicts with existing labels, or how the snapshot relates to other tools like onto_save.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter's intent is clear from the schema. The tool description adds no extra semantics beyond the schema; it only repeats the notion of a named snapshot.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool saves a named snapshot of the current ontology store, indicating a specific action and resource. However, it does not differentiate from sibling tools like onto_save or onto_rollback, which slightly reduces clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives such as onto_save, onto_load, or onto_rollback. The description lacks usage context or when-not-to-use conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

42 tool updatesv1.0.0Mar 13, 2026
- First observedonto_align
- First observedonto_align_feedback
- First observedonto_apply
- First observedonto_clear
- First observedonto_convert
- First observedonto_crosswalk
- First observedonto_diff
- First observedonto_dl_check
- First observedonto_dl_explain
- First observedonto_drift
- First observedonto_embed
- First observedonto_enforce
- First observedonto_enforce_feedback
- First observedonto_enrich
- First observedonto_extend
- First observedonto_history
- First observedonto_import
- First observedonto_import_schema
- First observedonto_ingest
- First observedonto_lineage
- First observedonto_lint
- First observedonto_lint_feedback
- First observedonto_load
- First observedonto_lock
- First observedonto_map
- First observedonto_monitor
- First observedonto_monitor_clear
- First observedonto_plan
- First observedonto_pull
- First observedonto_push
- First observedonto_query
- First observedonto_reason
- First observedonto_rollback
- First observedonto_save
- First observedonto_search
- First observedonto_shacl
- First observedonto_similarity
- First observedonto_stats
- First observedonto_status
- First observedonto_validate
- First observedonto_validate_clinical
- First observedonto_version

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored 2026-05-05 18:20 across 42 tools

Disambiguation5/5

All tools have clearly distinct purposes with detailed descriptions. The variety of operations (loading, reasoning, alignment, validation, feedback) are well-separated, and even similar-sounding tools like onto_validate, onto_shacl, and onto_validate_clinical are differentiated by their specific functions.

Naming Consistency5/5

All tools follow a consistent 'onto_' prefix with snake_case naming. Verbs are clear and descriptive (e.g., onto_load, onto_reason, onto_align_feedback). There is no mixing of conventions, making the toolset predictable and easy to navigate.

Tool Count4/5

42 tools is on the high side but justified by the comprehensive scope of ontology management (loading, reasoning, alignment, validation, versioning, monitoring). Some tools could be merged (e.g., feedback variants), but overall the count reflects the server's ambitious feature set.

Completeness3/5

The toolset covers many core ontology operations (load, reason, validate, align, version) but lacks fine-grained editing capabilities such as adding/removing individual triples or listing entities directly. The presence of feedback and monitoring tools suggests a mature system, yet basic CRUD operations are missing.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Meeba Brain A
io.github.meemoprasad
Repository knowledge graph MCP server for codebase understanding and debugging.
Code Analysis Developer Tools
51
tclp-mcp A
io.github.thechancerylaneproject
MCP server for The Chancery Lane Project's climate-aligned contract clause knowledge graph.
Legal & Compliance Knowledge & Memory
41
ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
Reasoning Commons
io.github.chenyuan35
AI Reasoning Cache & Consensus Layer with 11 MCP tools via Streamable HTTP.
AI & Machine Learning Knowledge & Memory Autonomous Agents
2

Related MCP Servers

Ontology MCP
Databases Agent Orchestration Search
bigdata-coss
A
license
C
quality
D
maintenance
A Model Context Protocol (MCP) server that connects GraphDB's SPARQL endpoints and Ollama models to Claude, enabling Claude to query and manipulate ontology data while leveraging various AI models.
Updated a year ago (2025-05-13 22:04 UTC)
28
3
MIT
Universal Ontology MCP
Knowledge & Memory RAG Systems Databases
seonwookim92
A
license
Not graded
quality
Not graded
maintenance
Enables AI assistants to navigate and populate complex ontologies by transforming unstructured data into structured, SHACL-validated knowledge graphs. It features semantic hybrid search and proactive schema guidance to help users build deeply linked, reasoning-ready data.
Updated 7 months ago (2026-02-11 12:50 UTC)
-
kg-mcp
Knowledge & Memory Databases RAG Systems
Kanne87
F
license
Not graded
quality
Not graded
maintenance
A Knowledge Graph MCP server optimized for LLM context efficiency through compact JSON and SQLite persistence. It enables full graph management including node/edge CRUD operations, full-text search, and subgraph traversal.
Updated 6 months ago (2026-03-14 20:06 UTC)
-
RDF4J MCP Server
Knowledge & Memory Databases Search
odysa
A
license
A
quality
D
maintenance
An MCP server that enables AI-powered exploration of RDF data and SPARQL querying via RDF4J. It provides tools for executing queries, searching knowledge graph resources, and retrieving schema summaries.
Updated 7 months ago (2026-02-07 17:57 UTC)
13
1
MIT

Appeared in Searches

OneKGPd Information and Resources