Ontonym

Build semantic search index

embed_memory

Idempotent

Build (or top up) the vector index a memory's semantic_search reads.

`semantic_search` matches against stored embeddings, so a memory that has
never been embedded answers every query with ZERO results — indistinguishable
from "nothing matches". Run this once per memory, and again after a large
ingestion, to make newly added objects findable by meaning.

Idempotent: entities already embedded for the current model are skipped
unless `force`. `kinds` defaults to ['object', 'class']. Requires write
scope.

RETURNS QUICKLY, and usually unfinished. Embedding is CPU-bound, so one
call spends a fixed wall-clock budget (~25s) and then reports what is
left in `objects_remaining` / `classes_remaining`. It is safe to call
again immediately to push it along; you do not have to loop it to zero,
because a background worker drains the same backlog on the server.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`force`	No
`kinds`	No
`memory`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description richly discloses behavior beyond annotations: idempotency semantics, force behavior, default kinds, write scope requirement, the fact that the call returns quickly but unfinished, the ~25s CPU-bound budget, remaining counts, and background worker draining. This goes far beyond the idempotentHint and destructiveHint annotations.

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 longer than typical but every section earns its place: purpose, failure-mode explanation, idempotency, defaults, permissions, async behavior, and retry guidance. It is front-loaded with the core action and structured so the operational warnings are easy to absorb.

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?

The definition provides everything an agent needs to both select and invoke the tool correctly: when to use, why missing embeddings cause empty results, parameter defaults, scoping requirements, asynchronous behavior, and what results mean. The output schema exists but the description even mentions the key output fields, making it fully self-contained.

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 description coverage is 0%, so the description carries the burden for parameters. It explains force (skip already-embedded unless set), kinds (defaults to ['object','class']), and memory implicitly as the target memory's index. Only the 'memory' parameter's format is not explicit, but the context is sufficient.

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 states a specific verb and resource: "Build (or top up) the vector index a memory's semantic_search reads." It clearly distinguishes itself from the sibling semantic_search by positioning this tool as the index builder that search depends on, so an agent can tell them apart immediately.

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?

It explicitly states when to run: "Run this once per memory, and again after a large ingestion." It also clarifies when repeated calls are unnecessary and that calling again immediately is safe, and that looping to zero is not required. This is actionable usage guidance beyond vague context.

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

All Ontonym tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?