What can you do with this server?

Open Ontologies MCP server lets you manage the full ontology lifecycle: load, query, reason, validate, align, monitor, and version RDF/OWL data. * Load, import, convert, save, clear, pull/push RDF/OWL and structured data (CSV, JSON, XML, YAML, XLSX, Parquet, PostgreSQL schemas). * Run SPARQL queries and inspect ontology stats, status, history, lineage, and saved versions. * Reason with RDFS, OWL RL, OWL RL ext, and OWL DL/SHIQ tableaux; materialize inferred triples. * Validate RDF/OWL syntax, lint quality issues, run SHACL validation, and enforce design patterns. * Align ontologies, collect alignment feedback, diff versions, detect drift, and enrich classes with clinical crosswalks. * Look up clinical crosswalk mappings (ICD10, SNOMED, MeSH) and validate clinical labels. * Search semantically with embeddings and compute text/structural similarity between IRIs. * Plan, lock IRIs, apply, monitor, and rollback ontology changes Terraform-style. * Ingest and map data, extend via ingest→SHACL→reason pipeline, and import PostgreSQL schemas as OWL.

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

One triple. Nothing added, nothing removed, blast radius zero. 901 consequences that were not there before.

$ printf 'load base.ttl\nplan proposed.ttl\n' | open-ontologies batch -
#   the whole change:  ex:hasParent rdfs:domain ex:Person

added_classes         0
removed_classes       0
blast_radius          0 triples affected
risk_score            low
                      ────────────────────────────────────────────
conservativity        not_conservative_under_rule_table
new consequences      901          rule table owl-rl, in 0.04s

Each number from a shape diff tells you that this change is safe. But the change gave a new type to each individual that the property already had. The tool closes this gap. A text diff cannot show you the gap. The change is one correct line, and the text diff is one line long.

Then give the reviewer the proof. The run writes a certificate. A different person re-verifies months later. That person needs no instance of this software and no network. The command is oo-cert asserted.tsv derivations.tsv. The exit code is 0, and the theorem OOCert.certificate_sound covers the result.

The checker also refuses a forged proof. Write a false conclusion into the derivation file. The same checker exits 1 and names the rule that does not hold. This is the red edge in the figure above. This refusal, and not the headline, is the part that survives examination.

This is not an ontology editor. Use Protégé to draw class hierarchies. You run Open Ontologies on the change, before the change goes to production.
The tool is like Terraform, and this is on purpose. But the plan is semantic, not syntactic. A text diff is git diff, and you have git diff already.

You do not need a JVM. You do not need Protégé. The engine speaks MCP to Claude, to Cursor, and to other clients of that protocol.

See the engine at work

Three triples go in, and three triples come out. A person asserted only that ex:Northwind is in a sanctioned jurisdiction. The engine derived the need for enhanced due diligence. A different person can check that derivation. That person does not have to trust you, or this engine, or the model that wrote the ontology.

Watch the last seconds. Somebody forges one conclusion, and leaves the two premises exactly as they were. The same checker refuses the conclusion and names the rule. oo-horn printed each line in that terminal for the fixtures in tests/fixtures/horn/supplier/. A test runs the checker again. The test fails if the figure and the checker do not agree.

Related MCP server: Universal Ontology MCP

With a proof, and without a proof

	An ordinary reasoner	Open Ontologies
The answer	`Northwind needs enhanced due diligence`	the same answer
Why the answer holds	"the reasoner says so"	a certificate that names each rule and each premise
Who can check the answer	a second implementation can agree, and some reasoners give an explanation. No verified checker accepts either one	anybody, with a checker that shares no code with the engine
If the engine has a defect	a second implementation can disagree. Then you know only that one of the two is wrong	the checker refuses the answer, exit 1
If a person edits the output	you cannot find the edit	the checker refuses it, and names the line and the rule
If a rule was yours, not the standard's	the report is the same	a different verdict word, and a test holds that word
What an auditor receives	a screenshot	a file that the auditor can check again
Guarantee on an unsatisfiability answer	asserted	none, and the tool says so

If the tool measures a property, the tool says measured. If a prover gives an opinion, that opinion never takes the vocabulary of the checker. Read what the tool proves, and what it does not prove.

What the tool does

Capability	What you get
Reason over OWL and RDFS	Materialised inferences and a derivation certificate that a proved checker accepts
Use your own rules	SWRL, RIF Core or a Horn table, evaluated, with a verdict word that says the rules were yours
Validate against SHACL	A report from an evaluator with a measurement against the W3C suite, not an assertion of success
Ask if something is satisfiable	A finite model, replayed and checked, and not only a yes
Ask if something is inconsistent	A refutation, if one is certifiable. If not, an honest opinion from the engine
Retrieve a slice for RAG	Entailment preservation for each claim, because 99% coverage can still lose 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
Give the problem to a prover	TPTP, CLIF, SMT-LIB and LADR from one translation. The tool names and counts what it cannot export
Work from an assistant	An MCP server, so Claude or Cursor operates all of it in conversation

Run the checker yourself

The repository holds the three files. The output shows only the important fields.

$ 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 important one. The inference is the same. But you wrote one of the rules. Thus the rule is an assumption that the certificate carries, and it is not a fact that the certificate establishes. The verdict word changes. A test fails if that word 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"]

Run the tool on your own ontology

The repository ships those fixtures. Now do the same steps with a file that you write. These steps take one 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 go in, and three triples come out. The cup is a Coffee. The cup is a Drink. Espresso is a subclass of Drink. Each RDFS reasoner can do this much. The directory that the run wrote is the difference.

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 tell the checker a lie. Keep the premises, and forge one conclusion. The forged conclusion says that 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>"]}

The exit code is 1. The output gives the number of the bad line. It names the rule. It also shows the premises, so that you can see that the premises do not support the conclusion.

What the proof contains

The proof is two tab-separated files. For the run above, the two files are 1.3 KB. asserted.tsv holds your claims:

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

derivations.tsv holds one line for each step. Each line gives the rule, then the conclusion, then the premises for that conclusion.

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 full proof. It needs no model, no network and no vendor.

A checker reads each line. For each line, the checker derives the conclusion again from the premises of that line, under the rule that the line names. The checker then confirms that each premise is asserted, or that an earlier line concluded it. Anybody can write such a checker. This checker has a soundness theorem.

Who checks the certificate, and when

The certificate is a file. Thus the person who holds the file can check it, at any time that they choose.

Who	When	What they run
You, in the loop	at each run, before you trust an answer	`lake exe oo-cert`, next to the reasoner
A reviewer	when a change lands	the same command in CI, on the artefact that the run wrote
An auditor, months later	long after the engine moved on	the same command, on the archived files
A different agent	when it receives a claim from an agent that it does not trust	the same command, before it acts on the claim

The tool streams nothing, and the tool calls no home server. The engine and the checker share bytes on a disk, and they share no protocol. This is what makes the last two rows possible. An auditor who checks a claim next year needs the two files and a Lean build. That auditor does not need an instance of this software.

The certificate records a digest of the assertions that the run used. The file asserted.sha256 holds that digest, next to the two other files. A holder of a store runs certificate-check <dir>. The command reads the digest, computes the same digest from the store, and reports whether the two agree.

That answer has a limit, and the command states the limit. A digest binds a certificate to bytes. It does not bind a certificate to a state of the world. A store that changed and then changed back gives the same answer. The type-level form of this work is decision 0010, and that work is open.

One case needs a word, because you will meet it. reason writes its inferences into the store by default. A check after such a run finds more triples in the store than the certificate lists. The report names that cause, and it does not call the store a different graph. It says different graph only when a triple in the store is not a conclusion of the run.

Two defaults can cause you trouble. First, storage is in-memory, unless you set OPEN_ONTOLOGIES_STORAGE_MODE=persistent. Thus a load and then a reason starts from an empty store, and certifies nothing. The tool gives a warning, and you can miss that warning easily. Second, --data-dir is a flag and not an environment variable. Thus a demonstration without that flag writes into ~/.open-ontologies, next to your real work.

The discipline behind this work has a cost, and the discipline has earned that cost: what the rules are, and what each rule caught.

Three claims that used to travel on trust

Three claims, each one checked against a real run

A crosswalk states a match type. Nothing checked that statement. The engine now reasons over each side alone. It compares what each side entails, through the mapping itself. It then reports the tightest match type the evidence supports.

An exactMatch that the entailments do not support comes back downgraded. The report gives the reason. It also names every term the crosswalk does not carry. That second list is the one that disappears from most crosswalk files. The output is valid SSSOM, so your tools read it today.

A second question is sharper than a downgrade. The engine carries the translated claims into the target and reasons again. A clash means the target denies what the mapping carried in. That is a disagreement, and a person must settle it.

Contexts can disagree. Birds fly. Penguins are birds, and penguins do not fly. One graph that holds both is inconsistent, and this engine finds the clash. Each module reasons alone instead. A fact earns "true everywhere" when k modules of n entail it.

A number can now carry a certificate. oo-matcert recomputes a matrix product from the definition. It prints MatCert.mul_of_check when it accepts. Integers only, and that is the condition for the sentence to hold. Freivalds costs less and gives a probability, so it stays an opinion with its bound printed. Floating point reports a tolerance, because a proof over the real numbers says nothing about IEEE-754.

open-ontologies batch plan.json   # crosswalk-certify, modules --threshold k, matcert

What the tool proves

You ask	You get back	Checked against
Reason over OWL	A derivation certificate	`OOCert.certificate_sound`
Reason with rules that you wrote	A certificate, and a different verdict word	`OOCert.horn_certificate_sound`
Is this satisfiable	A finite model	`Dl.satisfiable_of_checkModel`
Is the model of a solver 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	Preservation for each claim	`OOCert.certificate_sound`

A retrieval slice with 99% coverage can lose the one triple that an answer needs. A slice with 60% coverage can keep each claim that matters. Coverage is a proxy, and the proxy rises as the slice grows.

Thus a retriever that you tune on coverage learns to fetch more, and not to fetch the correct triples. Entailment preservation is the property that you want. The tool can decide that property here, and it gives one certificate for each claim. See decision 0007.

A measurement of the loss is the second-best answer. The best answer is a subset that can lose nothing. onto_module_extract computes such a subset. It computes a syntactic locality module over a signature. Each entailment of the full ontology over those terms is also an entailment of the subset.

That guarantee is a theorem of Cuenca Grau, Horrocks, Kazakov and Sattler, JAIR 31 (2008). The tool CITES that theorem, and no machine checks it here. No file under lean/ is about locality, and the report says exactly that.

The report names no theorem of this project. It offers a measurement instead. It reasons over the ontology and over the module to a fixpoint. It then reports each conclusion over the signature that the module does not reach. On the pizza ontology of this repository, the module is 238 of 1,345 axioms.

The run lost zero conclusions out of 2,583 differences. onto_conservative_check uses the same machinery for the lifecycle. It answers one question: does the addition of these axioms change any consequence over the names that the ontology already used? See decision 0011.

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

For Intel macOS, for native Windows and for other systems, read docs/quickstart.md and docs/windows.md.

The serve command starts an MCP server. That server speaks JSON-RPC on stdin and stdout. Thus, at start, the server looks as if it stopped, while it waits for a client. This behaviour is correct. From a terminal, use the CLI subcommands instead, for example open-ontologies validate <file.ttl>.

Connect the tool to Claude

For Claude Code, add this block to ~/.claude/settings.json. For Claude Desktop, add the block to ~/Library/Application Support/Claude/claude_desktop_config.json:

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

Start the client again, and the onto_* tools are available. For Cursor, for Windsurf, for Zed and for VS Code, read docs/quickstart.md.

Stars

What the box contains

One loop: plan a change, apply the change, watch for drift, certify what the engine derived, and rollback when the change was wrong. That loop is the whole of this front page, and that loop is the purpose of the tool.

The other parts have their own documentation and their own code. They are alignment, embeddings, PDDL planning, clinical crosswalks, the plugin marketplace and CIVeX. docs/tool-reference.md lists them one time, and this page does not list them. A large list of features is not the argument.

Some tools need an optional Cargo feature, and they return an error without that feature. Four tools need embeddings. Two tools need plugins. Two tools need postgres or duckdb. The published binaries and the GHCR image use the default feature set. Thus they do not carry those eight tools.

The Python package open-ontologies-lite also reasons now. It reasons in pure Python, and it needs no Rust toolchain. The same Lean binaries check its certificates. The package is a second engine. The lack of trust in that engine costs nothing, because the warrant was never in the engine.

tools/horn_differential.py runs both engines and the Lean checker over each RDF document in the repository. The two engines are not independent. They run the same algorithm over the same rule table, and the comments in the Python cite the Rust by file and by line. Thus their agreement is strong evidence against a transcription error, and it is almost no evidence 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 at each run. docs/lean-certificates.md also states the caveat as a limitation.

With those parts, the repository holds a marketplace of 33 standard ontologies, clinical crosswalks, semantic embeddings and a lineage audit trail. It also holds a desktop Studio, with a virtualized ontology tree, an AI chat panel and an inspector in the style of Protégé. You need no JVM. You need 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 and Lean boundary: what it proves, and what it costs	docs/aeneas-boundary.md
Which gates a green CI tick ran	docs/ci-gates.md
First-order export, TPTP and Common Logic	docs/first-order-export.md
Each reasoning system, and why the project used or refused it	docs/reasoning-systems-inventory.md
Design decisions, one rule for each 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 has an MIT licence, and it keeps that licence. The engine does not give you a place for the evidence. You need a place that keeps certificates. You need a review of each change to an ontology, before that change ships. You need an auditor who can check an answer again, months later, with no installation.

We build tesseractsemantics.com for that purpose. If a wrong answer from your ontologies has a cost, a conversation is worth your time.

Stack

Rust edition 2024, one binary, no JVM. Oxigraph 0.5 for RDF and for SPARQL 1.1. rmcp for MCP over streamable HTTP. SQLite for state, for lineage and for feedback. Lean 4 v4.33.1 for the checkers, core Lean only, no Mathlib.

Tauri 2, React 19 and Tailwind 4 for the Studio. The full table is 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 holds machine-readable metadata. It also operates the "Cite this repository" button of GitHub.

Language of this page

This page follows the writing rules of ASD-STE100 Simplified Technical English. The rules are one idea for each sentence, the active voice and simple tenses. A descriptive sentence has a maximum of 25 words. A paragraph has a maximum of 6 sentences. The same term always keeps the same meaning.

tests/readme_simplified_english_test.rs measures those rules. That test fails the build if this page breaks them. The same test holds the translated page to the structure of this one.

The official STE dictionary of approved words is a licensed document, and this project does not hold a copy. Thus this page claims the writing rules only. It does not claim approved-word compliance. The technical names and technical verbs of this domain stay in use. Examples are ontology, triple, reason and certify. STE permits such terms for a technical domain.

License

MIT. Fabio Rovai maintains this project at Tesseract Semantics. If this project 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

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

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
61
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 8 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 7 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 8 months ago (2026-02-07 17:57 UTC)
13
1
MIT

Appeared in Searches

OneKGPd Information and Resources