Auto Ontology MCP

Overview Schema Source Related Servers Discussions Admin

Save a concept

save_concept

Idempotent

Create or update ontology concepts with definitions, markdown pages, synonyms, sources, and typed relations; missing targets become empty concepts to fill later.

Instructions

Create or update a concept: a Term with a definition, a markdown body (a wiki page) and typed relations to other Terms. Works on entity Terms too, to explain them. Targets that do not exist yet become empty concepts to fill in later.

Input Schema

Name	Required	Description
`body`	No	Markdown page that replaces the current body: what it is, how it works, examples, open questions.
`name`	Yes	Concept (Term) name, e.g. 'Spaced Repetition'. Any language.
`source`	No	Where this came from: an existing source id, or a new source to register (deduplicated by uri or title).
`status`	No	Certify only when the user confirms.
`locator`	No	Where in the source (page, chapter, timestamp).
`evidence`	No	Supporting quote.
`synonyms`	No	Other names to add.
`relations`	No	Typed links to other Terms.
`datasource`	No	Defaults to the knowledge store; pass another datasource to document its Terms.
`append_body`	No	Markdown appended to the current body (new notes, a new source's view).
`description`	No	One-sentence definition.
`remove_relations`	No	Links to remove.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 6, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=false. The description adds genuinely new behavioral context: this is an upsert, it implicitly creates empty concepts for missing relation targets, and it applies to entity Terms. It does not spell out overwrite semantics for the existing body, though the schema parameter text partly covers that.

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?

Three sentences, front-loaded with the core create-or-update action, then scope, then side effects. No filler, though the sentence about empty concepts could be folded into the first for even tighter packaging.

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?

With an output schema present, 100% schema description coverage, and rich annotations, the remaining burden on the description is small, and it covers the non-obvious parts: upsert semantics and implicit Term creation. Nothing essential for correct invocation is missing.

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 schema already documents all 12 parameters in detail. The description only adds a structural framing (definition, markdown body, typed relations) rather than parameter-level meaning, which is the expected baseline when the schema does the heavy lifting.

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 gives a specific verb pattern (create or update) and a resource (a concept: Term + definition + markdown body + typed relations), which clearly separates it from note- or record-oriented siblings. It also clarifies that entity Terms can be documented. It stops short of naming the nearest alternatives (update_term, save_glossary, define_entity) directly, so an agent must infer the boundary.

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?

Usage is only implied: the upsert framing and the statement that non-existent targets 'become empty concepts to fill in later' tell the agent this is a write that can also stub out missing Terms. There is no explicit when-to-use/when-not-to-use guidance versus update_term or save_glossary, and no prerequisite conditions are stated.

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