Auto Ontology MCP

Overview Schema Source Related Servers Discussions Admin

Define or change an entity

define_entity

DestructiveIdempotent

Creates or updates a personal knowledge entity, adds typed columns for facts to count or filter, and deletes it when needed.

Instructions

Create an entity in the personal knowledge store (a Term with its own table), add columns to it as you learn more, or delete it. Column types: text, integer, number, date, datetime, boolean, ref: (a link that becomes a relationship). Every record also gets id, _source_id, _source_locator, _evidence, _note and timestamps.

Storing knowledge (Auto Ontology's model applied to personal knowledge):

Reuse before you create: search_ontology for the thing first. One Term per real-world kind of thing, named in the singular as people say it (Receipt, Book, Person, Workout).
Entities hold facts you will count, sum, filter or compare. Give columns snake_case English names and the right type (text, integer, number, date, datetime, boolean, ref:). Put the unit in the name or description (amount_krw, distance_km). Use ref columns for things that recur (merchant, author, place) instead of repeating text; add_records creates the referenced rows by name. Set keys when a natural identifier exists (isbn, receipt_no) so re-ingesting updates instead of duplicating.
Concepts hold meaning: a one-sentence definition, a markdown body (what it is, how it works, examples, open questions) and typed relations: is_a, part_of, has_part, instance_of, related_to, depends_on, causes, used_for, contrasts_with, same_as, example_of. A Term can be both: an entity with records and a body that explains it.
Provenance on everything: pass source={title, kind, uri, ...} (or a source id) and, per record, _locator (page, timestamp, line) and _evidence (the quote or number as written).
Never invent values. Leave unknown fields out; record ambiguity in _note.
Certified means a person confirmed it. New knowledge is draft; do not certify on your own.

Input Schema

Name	Required	Description
`keys`	No	Columns that identify a record (e.g. ['isbn']); re-adding updates it.
`name`	Yes	Entity (Term) name, singular, e.g. 'Receipt', 'Book', '운동 기록'.
`force`	No	Allow deleting an entity that still has records.
`table`	No	snake_case table name; required when the name is not English.
`delete`	No	Delete the entity (and, with force, its records).
`columns`	No	Columns to create or add. Existing columns keep their type.
`synonyms`	No	Other names, e.g. the user's language.
`description`	No	What one record is.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Nov 6, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description corroborates both (delete, and keys causing 're-adding updates instead of duplicating') rather than contradicting them. It adds real policy beyond the annotations: reserved id/_source_id/_evidence fields, ref columns materializing as relationships, 'Never invent values,' and 'do not certify on your own' — though it never warns that deletion with force is irreversible.

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 purpose sentence is well front-loaded, but the six numbered points are largely a general knowledge-modeling manifesto: point 3 is about concepts (save_concept's job) and point 4's per-record locator/evidence advice belongs to add_records. Roughly half the text does not earn its place in this tool's definition.

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 an 8-parameter, destructive, idempotent schema with full coverage and an output schema, the description covers naming, typing, keys, and provenance well enough to call correctly. The gap is the phantom `source` parameter and the missing note that force-delete is unrecoverable.

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, and the description does add value on keys (upsert semantics) and ref:<Entity> column types. But it also tells the agent to 'pass source={title, kind, uri, ...}' and to supply per-record _locator and _evidence — none of which are parameters of this tool, which has additionalProperties: false, so following that instruction would produce a call error.

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?

Opens with a specific triad of operations — create an entity (a Term with its own table), add columns, delete it — naming the concrete resource and its physical form. It implicitly separates itself from save_concept (which holds meaning, not countable facts) and from add_records, so an agent can pick the right tool without reading the schema.

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 routes the agent to a sibling first: 'Reuse before you create: search_ontology for the thing first,' and gives the entity-vs-concept decision rule. It stops short of saying when to call update_term instead of define_entity, or when a new column should become a separate entity, so one selection boundary is left to inference.

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