Skip to main content
Glama

defineEntityKind

Registers a new entity kind in the dynamic-ontology registry after an automatic semantic dedup check, reusing an existing kind or recording a close-match alias to prevent synonyms.

Instructions

Register a new entity kind in the dynamic-ontology registry — but first check whether an existing kind already covers the concept (introspect → entityKinds, or describeType). The built-in dedup check runs automatically: a near-identical kind returns status="reused" with the existing name so you avoid minting a synonym; a medium-similarity near-duplicate mints but records a SKOS closeMatch alias (response field closeMatch + similarity, internal URN maz:kind: added to sameAs). Because that dedup runs a semantic embedding pass over existing kinds, this call routinely takes a few seconds to return — that latency is expected, not a hang; do not abort or retry on a short timeout. Inputs: name (bare snake_case, no namespace), displayName, description (required for dedup), optional extends (parent kind — must be a core kind or an already-registered active kind; bare names resolve to their canonical registered form), sameAs (external vocabulary IRIs), propertySchema (JSON Schema for typed attributes). Appends an entityKindRegistered event; the dispatcher materialises it into entity_kinds and the render pipeline writes it to the git-synced ontology/ tree. Re-registering an existing user kind with force=true overwrites it. Attempting to modify a core kind, or extending an unknown/ambiguous parent, returns E_VALIDATION.

Input Schema

NameRequiredDescriptionDefault
nameYesBare snake_case kind identifier, e.g. vehicle. No namespace prefix — user: is added automatically. Must not start with core:.
forceNoBypass the reuse-before-mint dedup check and register unconditionally. Default false.
sameAsNoAlias/sameAs IRIs to canonical external vocabularies, e.g. ["schema.org/Vehicle", "wikidata:Q42889"]. Optional.
extendsNoParent kind name for single-inheritance subtype hierarchy (RDFS subClassOf). Must be a core kind or an already-registered active kind; a bare name (vehicle) resolves to its canonical registered form (user:vehicle) when unambiguous. E_VALIDATION when unknown or ambiguous. Optional.
previewNoWhen true, compute and return a plan of what this call would do (collapse, supersede, or mint) WITHOUT appending any event. The event log is unchanged. Use this to inspect impact before committing. Default false.
descriptionYesOne-sentence explanation of the kind. Used by the dedup check and agents.
displayNameYesHuman-readable label, e.g. Vehicle.
propertySchemaNoOptional JSON Schema (Draft 2020-12) for typed attributes. Compiled before registration; E_VALIDATION on compile failure.

Output Schema

NameRequiredDescriptionDefault
nameYesThe registered kind name, e.g. user:vehicle.
planNoPresent only when preview=true. Describes what the call would do without writing any event.
statusYesregistered = kind written as active; reused = existing near-identical kind returned instead of minting; proposed = kind queued for review in governed mode; preview = plan computed without writing any event (preview=true was set).
warningsNoNon-fatal advisory warnings. MAZ-KIND-001 = close match found; MAZ-KIND-002 = semantic dedup skipped; MAZ-SCHEMA-001 = supersede; MAZ-SCHEMA-002 = orphaned fields; MAZ-SCHEMA-003 = collapse.
closeMatchNoThe name of a closely related existing kind (skos:closeMatch semantics). Present when a medium-similarity near-duplicate was found during minting.
reusedKindNoThe existing kind name when status=reused. Absent otherwise.
similarityNoDedup similarity score (0..1). Present when status=reused or when closeMatch is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the automatic dedup pass (reused / closeMatch alias / maz:kind URN in sameAs), the expected multi-second latency with an explicit 'do not abort or retry' warning, the event-append plus dispatcher/materialisation and git-sync side effects, and the E_VALIDATION failure modes for core-kind edits and unknown parents.

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?

It is long, but front-loaded with the purpose followed by dedup, latency, inputs, side effects, and errors in a deliberate order. Nearly every sentence carries operational information; a couple of clauses (event appending plus materialisation plus render pipeline) could be tightened without loss.

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 eight parameters, nested propertySchema, an output schema, and a mutation with real side effects, the description covers prerequisites, latency, dedup outcomes, error codes, and reversibility (force overwrite) — nothing an agent needs to invoke it correctly is missing.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining name must be bare snake_case with no namespace, that description is required specifically for dedup, that extends must resolve to a core or active registered kind, and that sameAs is for external vocabulary IRIs. It adds real semantic framing beyond the property descriptions rather than repeating them.

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 opening clause states a specific verb and resource — 'Register a new entity kind in the dynamic-ontology registry' — and immediately names the siblings (introspect→entityKinds, describeType) that serve the alternative purpose. An agent can distinguish this from definePredicate/defineSchema/describeType without opening 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 Guidelines5/5

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

Explicitly instructs the agent to check for an existing covering kind first and names the two concrete alternatives (introspect → entityKinds, describeType). It also flags the preview parameter as the way to inspect impact before committing and force=true for overwriting, giving both when-to-use and when-not-to-mint guidance.

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