What can you do with this server?

This server provides a governed interface to a unified order management domain model (Customer, Order, Product, Note) with semantic read, write, and audit capabilities. * Read/Query: Search, fetch, and aggregate objects by fields (id, name, status, etc.). Traverse relationships: Customer↔Order, Order↔Product, Order↔Note. Results are scoped by visibility policies. * Write/Actions: Execute rule-gated operations: cancel_order (requires reason, rejects shipped orders with machine-readable errors), assign_order (assigns a pending order to a person), and add_order_note (creates a note linked to an order). Actions manage ontology-owned state and integrate with legacy systems where needed. * Audit: Access the append-only audit log of every action attempt (applied and rejected), filterable by action, status, or target. This is an unscoped administrative view. * Extensibility: Offers a consistent tool surface for AI agents, ensuring they operate under the same business rules, and unifies data from disparate legacy sources.

Operational Ontology

by gura105

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

English | 日本語

Operational Ontology

License: MIT

An operational ontology is a shared domain model built on top of the data of systems you don't own — objects, links, and actions — where reads traverse the model and writes are gated by actions that carry business rules, are audited, and propagate back to the systems of record that own the state they change.
A semantic layer lets you read your business. An operational ontology lets you run it.

Palantir Foundry's Ontology is one implementation of this pattern. This repository is another: a minimal reference implementation, small enough to read in one sitting. It exists to make the definition precise and runnable; it is not a framework. Fork it and reuse the ideas.

Quickstart

pnpm install
pnpm demo    # physical data → integrate → index → read → write → refusal → write-back
pnpm test    # the same behavior, as executable tests

The demo uses the scenario from the article this repository accompanies. A company acquires a competitor and inherits two legacy order systems with different schemas and status encodings. A few dozen lines of SQL and a small TypeScript mapping integrate them, and the ontology models Customer, Order, and Product on top — plus Note, a type that exists in no source system. The demo then shows:

a link traversal answering "which orders contain this product?" across both systems
assignOrder writing state that exists in no legacy system — edits can live in a layer above the sources
cancelOrder on a shipped order refused with SHIPPED_ORDER_CANNOT_BE_CANCELLED
cancelOrder on an open order succeeding, with the row in the legacy ERP actually changing
a re-index of the live legacy systems, where order data refreshes from the ERP while the assignment and notes — state the ontology itself owns — survive
every attempt, applied or refused, recorded in the audit log

https://github.com/user-attachments/assets/02bb8ca0-a476-4e33-b0ea-25c46c6e9dda

Related MCP server: ORMCP Server

The four properties

A system implements the pattern when all four properties hold. They constrain what must be true, not how to build it: outbox or webhook, SQL or search index, one store or many are all implementation choices. Treat them as shared vocabulary for discussing systems, not as a certification to pass.

Semantic objects and links. Business entities and their relationships are modeled explicitly, on top of physical data that existed first and that other systems own.
Action-gated writes. A business decision changes state only through a named action. There is no generic update path — not for a user, not for an application, not for an agent. State in this layer also changes for two other reasons, and neither is a loophole: re-indexing only replays what the sources already say, and schema evolution (under review) changes what can be said, not what is true. Any write that picks a business outcome is a decision, whatever the endpoint is named, and decisions go through actions.
Business rules at the action. Preconditions check domain invariants ("a shipped order cannot be cancelled") and refuse violations with machine-readable errors. They are not access control, and not UI validation. Every attempt, applied or refused, is recorded in the audit log.
Write-back to systems of record. The model declares, for every piece of state, which system owns it. There are three kinds:
- source-backed — state owned by an upstream system, such as an order's status mastered in the ERP. A change to it propagates back to that source as a governed, ordered side effect; the source stays authoritative.
- ontology-owned — state no source system has a column for, such as an assignee or a triage note. For this state the ontology's own store is the system of record, by declaration.
- derived — computed state such as aggregates and counts. It is never written.
What the property forbids is state with no declared owner: a local copy of source-owned data that is modified but never written back, or a write nobody can place. An implementation with no source-backed writes at all does not implement a smaller version of this pattern; it is an ordinary application with its own database.

A quick test: "Can you cancel an order from your semantic layer?"

If the answer is no, you have a read layer — useful, but a different thing.
If the answer is yes but no row in any system of record ever changes, you have a parallel database — also a different thing.
If it also cancels already-shipped orders without complaint, you have a write API; property 3 is the whole difference.

Why another word?

The pattern needs a name of its own because "ontology" already means too many things:

called an "ontology"	what it is	governed writes?
philosophical ontology	the study of what exists	—
formal ontology (OWL / RDF)	machine-reasonable semantics	no
knowledge graph	entities and relationships — writable as data, not as operations	no
AI context layer (the 2026 wave of "ontology"-branded platform features)	semantic grounding for AI answers	no
operational ontology (Foundry-style)	business domain schema + rule-carrying actions	yes

Each row is a legitimate tool, and the table is not a ranking. But the one property that changes what a layer can do — whether it accepts writes governed by business rules — cuts across the whole table and had no name of its own. This repository gives it one.

What an implementation declares

The four properties leave the mechanisms open, but some choices differ between implementations in ways users can observe. Those choices must be declared, not left silent. There are four:

Authority — which state is source-backed, which ontology-owned, which derived.
Failure semantics — what happens when write-back and the local commit disagree.
Re-indexing vs edits — whether ontology-owned state survives a refresh of the base.
Visibility default — what an object with no policy falls back to.

This repository's answers, in the same order. Ownership is declared in the model — owned marks ontology-owned properties, link types, or whole object types, and writeback: true marks an action's changes source-backed — and the runtime checks every edit plan against those declarations instead of trusting them (details). Write-back runs before the local commit, so if the source refuses, nothing changes here (see Failure semantics). Ontology-owned state survives re-indexing: edits live in an overlay that load() reapplies over the fresh base, and a re-index that would orphan an edit is refused whole. Visibility defaults to fail-open: no policy means visible to everyone (see the FAQ).

All four answers are also collected in one enumerable value, Runtime.declarations, so they can be read at runtime rather than trusted as prose. An implementation may answer all four differently and still be inside the pattern. If a product calls itself an operational ontology, ask for its four answers, not for a certificate.

For AI agents (MCP)

pnpm mcp     # serve the same ontology to agents over stdio

The MCP tool surface is generated from the model: search_order, traverse_customer_orders, cancel_order, read_audit_log, … — one tool per query shape and one per action. The tool surface is derived from the schema side; the calls act on the instance side. Two consequences:

There is no raw SQL tool. Agents get exactly the operations the model defines, and nothing else.
The same preconditions that gate humans gate agents. An agent that tries to cancel a shipped order receives { "error": { "code": "SHIPPED_ORDER_CANNOT_BE_CANCELLED", … } } — a machine-readable refusal it can read, recover from, and explain to its user.

Reads are scoped the same way. Every query runs as an actor — the identity on whose behalf the call is made — and visibility policies attached to the model decide which objects that actor can see. Agent sessions are no exception; the audit log is the one declared exception, an unscoped administrative view. Over stdio all callers collapse into one actor. OO_AGENT=<name> pnpm mcp names that actor, which is labeling, not authentication.

https://github.com/user-attachments/assets/28327062-e09f-4103-943e-434a0e55b327

Business rules live in the ontology, not in the prompt.

approach	reads	writes	rules enforced by
raw DB access (SQL tool / DB MCP)	tables	unrestricted `UPDATE`	nothing — the prompt, at best
semantic layer / metrics MCP	governed metrics	—	n/a (read-only)
API wrapper tools	endpoints	per-endpoint	each backend, inconsistently
operational ontology	objects, links, aggregates	named actions only	preconditions in the model, audited

The pattern

The model defines three kinds of types: object types, link types, and action types. At runtime their instances — objects, links, and applied actions — live in the store. The remaining two concepts connect the pairs: edits are the changes to objects and links that an action instance describes, and the audit log is where the action instances themselves are recorded. All five concepts are defined as data and interpreted by a runtime (src/core.ts):

const ontology = defineOntology({
  name: 'orders',
  objects: {
    Customer: defineObject({
      primaryKey: 'id',
      properties: { id: z.string(), name: z.string(), region: z.string() },
    }),
    Order: defineObject({
      primaryKey: 'id',
      properties: {
        id: z.string(),
        status: z.enum(['pending', 'shipped', 'cancelled']),
        total: z.number().int(), // minor units — money is not a float
        assignee: z.string().nullable(),
      },
      owned: { assignee: null },                       // the ontology's own state, declared
      source: 'north.tbl_order ∪ south.SALES_ORDER',   // physical data comes first
    }),
  },
  links: {
    customerOrders: defineLink({ from: 'Customer', to: 'Order', kind: 'one-to-many' }),
  },
  actions: {
    cancelOrder: defineAction({
      object: 'Order',
      targetParam: 'orderId',
      params: { orderId: z.string(), reason: z.string().min(1) },
      preconditions: [
        ({ object }) => object.status === 'shipped'
          ? reject('SHIPPED_ORDER_CANNOT_BE_CANCELLED', `order ${object.id} has already shipped`)
          : undefined,
      ],
      effects: ({ object }) => [modify('Order', object.id, { status: 'cancelled' })],
      writeback: true,
    }),
  },
})

Because the definition is a plain value, it can be enumerated, diffed, and versioned; the MCP tool surface above is derived from it mechanically.

Runtime.execute() is the only operational write path the API exposes. Every call, applied or refused, creates one action instance and records it in the audit log. The steps always run in this order:

validate the parameters
evaluate the preconditions
run the effects function, which returns an edit plan and performs nothing itself
dry-run the whole plan through the same code the commit uses, then roll it back
check the plan against the authority declarations
write back to the systems of record
commit the edits and the audit entry in one transaction

This closure is a contract on the API, not a privilege boundary: the runtime lives in its caller's process, and code that holds the database handle itself can bypass the gate (details). load() is separate infrastructure: it re-indexes the sources — replay, not decision — and is not a user API.

Reads carry identity too. Every search / get / traverse / aggregate runs as an actor, and an object type may attach a visibility predicate — row-level security in its minimal form, stored in the model like everything else. A hidden object is indistinguishable from a nonexistent one, both for reads and as an action target.

Edits are data as well: modify, create, and link / unlink. Actions can therefore change link instances, not just properties. Link types are schema and do not change here; the links themselves are instances, and they change only through actions — cardinality included: the runtime refuses a link that would give an order two customers. "Reassign this order to another customer" is an unlink plus a link, applied atomically under the same preconditions as everything else. Creation goes through the same gate: the demo's addOrderNote creates an ontology-owned note and links it to its order in one atomic plan. Deletes are out of scope in this version (see Status); changing the model itself — new object types, new link types — is schema evolution (see the FAQ).

The model is data rather than classes for a practical reason. class Order { cancel() {} } cannot be enumerated into agent tools, shared across applications, or inspected at runtime without an added reflection layer, and its signature says nothing about preconditions. A class-based domain layer is private to one application; the point of this pattern is a domain layer that is shared.

The type/instance split is a general one — formal ontology calls the sides TBox and ABox — and it is no part of what makes the pattern; as an anatomy of it, though, it works well. Foundry uses the same phrasing for all three pairs — object type and object, link type and link, action type and action: the former is a "schema definition", the latter its individuals. The schema side — the type definitions plus the authority declarations (owned / writeback) and visibility — is a plain value that lives in git, readable at runtime as Runtime.declarations and as the MCP tool surface, and not changeable there. The instance side lives in the store and changes only through actions. Restated in this vocabulary, the four properties all govern the instance side. An authority declaration is a schema-side statement of who holds the truth of a piece of instance state, and that answer decides the state's write path: write-back concerns only the state whose declared owner is upstream. That the edit vocabulary — modify / create / link / unlink — is all instance operations states the same split structurally: no edit changes the schema. Property 2's "schema evolution changes what can be said, not what is true" is this distinction in other words (querying applied actions as instances is in the FAQ).

Where this sits

Three layers. This repository implements the middle one only.

Upstream contract (with the data platform): integrated physical data is a given. Pipelines, dataset transactions, and rollback belong to the data platform.

Downstream contract (with the systems of record): write-back is a governed side effect, not a distributed transaction (see below).

One consequence separates this pattern from query-side layers: a layer that only answers queries can stay virtual, but a layer that accepts writes must own state. Edits exist here before — or instead of — the systems of record (assignOrder writes ontology-owned state no legacy system has a column for), so the ontology keeps its own store and its own audit log. What this repository does not own is the indexing machinery that makes reads fast at enterprise scale: incremental indexing, adjacency indexes, search backends. That is how Foundry serves billions of objects; it belongs to an implementation of the layer, not to the pattern.

Failure semantics

What the pattern requires. The pattern does not prescribe a consistency mechanism between the ontology and the systems of record; distributed transactions, ordering contracts, outboxes, and reconciliation jobs are all implementation choices. It does require the failure behavior to be declared, because unlike an internal mechanism, failure behavior is observable: users can watch the systems diverge. Divergence you can reason about is an engineering problem; divergence discovered in production is an incident.

What this implementation declares. The WritebackAdapter runs before the local commit — the ordering of Foundry's write-back webhooks (one of Foundry's two modes; the other runs side effects after the edit). Two consequences:

If the system of record refuses, nothing changes in the ontology.
The reverse failure remains possible: the adapter succeeded and the local commit failed. When that happens the systems have diverged, and reconciliation is up to the operator. Palantir's webhook documentation acknowledges the same gap in Foundry's write-back mode.

Three details bound that risk (full mechanics): nothing invalid ever reaches a system of record, because the whole edit plan is dry-run through the commit's own code before the adapter runs; the audit log records the full plan for both failure directions, as reconciliation material; and "every attempt is audited" means every attempt this runtime observed to completion. Within its own store the runtime is transactional: an action's edits and its audit entry commit atomically in a single SQLite transaction, and rejected attempts are logged too.

Preconditions and freshness. Guaranteed: preconditions hold against the ontology store — the last indexed snapshot plus applied edits. Not guaranteed: the write-back step does not re-verify invariants at the source, so if a source changes behind the ontology's back, the invariant may no longer hold there. Narrowing that gap is the adapter's choice — conditional write-backs, compare-and-set, re-verification at the source. The demo adapter does this: a guarded UPDATE lets the ERP refuse a stale cancellation.

Concurrent edits. Guaranteed: this implementation is a synchronous single-writer — actions execute one at a time, serialized by the runtime — and the runtime refuses to run inside a caller-opened transaction, so a committed-and-audited action cannot be silently rolled back after success was reported. Not guaranteed: the WritebackAdapter interface is synchronous, and a real networked write-back breaks the serialization; an implementation that goes there must declare what replaces it. The rest of the store's boundary is a declared contract, not a defended one: rules and the adapter must not touch the ontology store, because no in-process check can stop code that holds the database handle (details).

Re-indexing vs edits. The store holds a base indexed from the sources plus the edits actions have made on top, and sources keep changing, so every implementation must decide what a re-index does to edits. Here — Foundry's shape, minimized — a snapshot may only supply source-backed state; edits to ontology-owned properties survive via an overlay reapplied over the fresh base; ontology-owned types and links are untouched by load() altogether. A re-index that would orphan an ontology-owned edit is refused whole, leaving the previous state standing: that is a reconciliation decision, and the runtime does not make reconciliation decisions silently. The full rules — including deletes meeting surviving edits, and partial snapshots — are in the implementation notes.

Non-goals

Scope is frozen for v0 so the reference implementation stays small enough to read in one sitting:

No UI builder. Applications consume the ontology; they are not part of it.
No pipeline framework. Integration is a prerequisite; the demo uses plain SQL.
No indexing infrastructure. Naive queries are fine at demo scale; scale is a property of implementations, not of the pattern. Result sets are unbounded in v0.
No federation. One ontology is one bounded context. Who owns the model when there are several is a real question, and unaddressed in v0, like schema evolution.
No link properties or composite keys (yet). The demo's order-line quantities deliberately stay in the data layer; whether they become a first-class OrderLine or properties on the link is a decision for the next version.
No OWL/RDF. Academic ontologies are semantic-only — no actions. A different tool for a different job.
No general authorization system. The pattern-level part is here: identity flows through every call (the audit log's administrative view is the declared exception) and visibility attaches to the model. The mechanism — groups, attributes, policy languages, cell-level security, propagation — is a policy engine's job.
No npm package. Fork it; don't depend on it.
Not a Foundry alternative. Foundry implements all three layers, vertically integrated; this repository names and demonstrates the middle one.

Prior art

Palantir Foundry Ontology — the implementation this pattern was distilled from, including its semantic/kinetic vocabulary, action types, write-back webhooks, and Ontology MCP. This repository describes the pattern independently of any vendor.
DDD, CQRS, event sourcing — the parts are deliberately old: entities, aggregates, commands, guarded state transitions, append-only logs. What is new is the placement: the domain layer lifted out of a single application, put on top of other systems' data, and shared by many applications and agents.
Semantic layers (dbt, Cube, AtScale, …) and knowledge graphs / OWL / RDF — governed reads without governed writes; the adjacent categories this pattern is defined against.
"Operational ontology" — the phrase itself has prior use. Academic ontology engineering has used it with unrelated meanings, and Vladimir Kozlov's 2025 LinkedIn essays (a definition, a Foundry walkthrough) applied it to the same lineage described here: Foundry-style models that carry actions, not just semantics. FSTech, a Brazilian consultancy, has published an Operational Ontology Framework (Portuguese-first, since early 2026) that applies the phrase to an adjacent but different concern — governance principles for stateful AI agents (Data + Logic + Action plus session-state artifacts) — where write-back means persisting durable state between sessions, not writing to systems of record. What this repository adds is a testable boundary — the four properties, write-back and audit included — and a reference implementation of it.

FAQ

Isn't this just CRUD with validation? The parts are familiar; the configuration is not. CRUD validation lives inside one application, on tables that application owns. Here the model sits on data other systems own, is shared by every consumer (UIs, scripts, agents), closes every write path except actions, audits every attempt, and writes accepted changes back to the systems of record. The closest existing description is a CQRS command layer extracted from the application and placed over someone else's data.

Isn't a knowledge graph writable too? Yes. SPARQL UPDATE can set status = 'cancelled', and a WHERE clause or a SHACL shape can make it conditional. Both sides are there too — a schema and instances. What is missing is the third pair: action types with their instances. What a triple store does not provide as one first-class unit is the rest of the contract: a named business operation, a machine-readable refusal, an audit trail of attempts, and write-back to the system of record. The difference is not capability — all of this can be built on a triple store — but what comes named, governed, and first-class out of the model.

Why not OWL/RDF? Those model what things are (semantic). Half of this pattern is what you can do (kinetic): actions, preconditions, audit, write-back. A reasoner cannot cancel an order.

Why TypeScript definitions instead of YAML? Because business rules are code, and rule-expression languages embedded in YAML tend to grow into ad-hoc rule engines. TypeScript object literals keep the model enumerable while the rules stay ordinary typed code. (The typing covers the language, not yet the model's own schema — see Status.) Structure as data, rules as functions — the same split Foundry makes between Ontology Manager and Functions.

What about transactions and rollback? Three domains, three answers. Dataset versioning and rollback belong to the data layer (in Foundry: catalog transactions and branching). Atomic application of an action's edits belongs to this layer (implemented here as a real SQLite transaction). The consistency mechanism for cross-system write-back is implementation-defined; the pattern requires it to be declared, and this implementation declares write-back-first ordering (see Failure semantics).

What about permissions and security? Three different things hide in that question:

Authentication is outside the pattern: an identity arrives already established. Here actor is a self-declared string — this implementation demonstrates placement, not protection.
Authorization: its placement is part of the pattern — policies attach to object types and actions and bind every consumer's reads and writes, the way Foundry counts dynamic security among the Ontology's kinetic elements. Its mechanism (groups, attributes, policy languages, cell-level security, propagation) is implementation-defined.
Preconditions are neither: they are validity, not permission.

The distinction matters to agents, which recover differently from each:

visibility — you can't see it
permission — you can't do it
precondition — nobody can

(Foundry blends permission and validity in its action submission criteria and still conforms; the separation is a recommendation, not a requirement.)

Two design choices follow. preconditions is a required key, and an empty list is an explicit decision: gated writes are the core of the pattern, so "no conditions" must be stated, not defaulted. visibility is an optional key, because whether authorization exists at all is implementation-defined; an object without a policy is visible to everyone (fail-open). A reference implementation without authentication cannot be meaningfully fail-closed, so it does not pretend to be. Foundry's baseline is the opposite — discretionary grants expand access from zero, and mandatory markings deny on top. A fail-closed deployment starts by making visibility required, and also needs real authentication, action permissions, and scoped audit access underneath. One more declared surface: the audit log read API is unscoped — an administrative view where visibility filtering does not apply.

What about Foundry's Functions and derived properties? Foundry counts three kinetic elements: actions, functions, dynamic security. Function-backed actions are already inside this pattern — preconditions and effects are ordinary code that describes changes; effects return an edit plan and perform nothing themselves, and side effects belong to the adapter. Read-time computation — derived properties, query functions — is deliberately outside: the pattern's distinguishing half is governed writes, not computed reads. Dynamic security is the permissions story above.

What if an agent retries? This implementation has no idempotency keys. A retried cancelOrder is refused by its own precondition (ORDER_ALREADY_CANCELLED) — natural idempotency via the rules, not a guarantee — and a retry that interleaves with write-back can double-apply the side effect at the source. If your actions are not naturally idempotent, an invocation id in the params (audited like everything else) is the minimal starting point: it buys correlation, and actual deduplication needs a uniqueness check on that id. Idempotency is implementation-defined, and worth declaring, because agents do retry. There is a structural reason underneath: an action instance is individuated by its occurrence, not by its arguments. The same parameters submitted twice are not one attempt repeated but two instances — which is why the audit log cuts one entry per attempt, and why an idempotency key is a device that grafts value identity onto an action that natively has only event identity.

Could past actions be queried like objects? They could — Foundry demonstrates it: its action log materializes each submission as a [LOG] object linked to every object the action edited, so applied actions join the graph as searchable, traversable, aggregable instances. This implementation keeps the audit log outside the object graph, and the reason is contracts, not modesty. Three of the log's contracts resist objectification: it records rejected and crashed attempts, which commit nothing; its write must never fail — a value it cannot encode becomes a placeholder, the opposite contract to schema validation, which refuses; and the runtime writes it directly, not through an action, so entries as ordinary objects would need a declared exception to property 2. If a future version wants queryable action instances, the open path is projection, not replacement: treat the audit log as one more source — owned by the runtime, replayed by indexing — and derive action-instance objects from it. Derived state is never written, so immutability comes for free, and the log stays the substrate underneath. Foundry's own architecture agrees: the [LOG] projection exists alongside platform audit logging, not instead of it.

How does the ontology itself change? Schema evolution — new object types, changed properties, retired links — is real and out of scope here, like federation. Foundry has versioning and proposal machinery for it, and the academic field studies it as ontology evolution. What this repository contributes is the precondition for evolving safely: the model is a plain value, so it can be diffed, versioned, and reviewed like any other code. This layer therefore has two channels of governance: instance changes are governed at runtime, by actions and the audit log; schema changes are governed at development time, by diffs and review. The schema has no address in the store — code is the only place it persists — and that is a choice, not a limitation: versioning and approval are delegated wholesale to git. If schema governance ever moves to runtime, the open path is lowering structure into data, not lowering rules into data; rules stay code. Domain modeling is not a one-shot step; the model keeps being re-fit to the business.

Bring your own frontend? Yes. The application contract is two kinds of calls — queries (search/get/traverse/aggregate) and execute(action) — the same for humans and agents, and every call is made as an actor. A dashboard uses the first; a "cancel" button uses the second. Rules follow the model, not the frontend.

Status

v0.2 — reference implementation. This version removed mechanisms that enforced vows beyond the four properties — canonical-form storage checks, foreign-transaction detection, targetless actions, property-mirrored links, deletes — and replaced them with declared contracts, keeping the runtime readable in one sitting. Nothing in the four properties was lost.

Current limitations, which are also the worklist for the next version:

A plan that changes both source-backed and ontology-owned state is refused whole; per-edit routing is future work.
Creation is limited to ontology-owned types; source-backed creation carried by write-back is not demonstrated yet.
No deletes.
No link properties or composite keys.
Rule contexts are not fully typed.
Nested properties are not validated strictly.

The mechanics behind this implementation's declarations are in the implementation notes. Built and verified with Node 24, better-sqlite3, zod 4, MCP SDK 1.29.

MIT © gura105

Available Tools

19 tools

add_order_noteB

File a triage note against an order. Writes are gated: if a business rule rejects this call, the error is machine-readable ({ code, message }) and the attempt is recorded in the audit log.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`author`	Yes
`noteId`	Yes
`orderId`	Yes

TDQS

B3.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and discloses important behavioral traits: writes are gated by business rules, errors are machine-readable with a { code, message } shape, and attempts are audit-logged. It stops short of describing success responses or permission requirements, but adds meaningful safety and error 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?

Two sentences, front-loaded with the core action, and every clause earns its place by adding error behavior and audit context. No fluff or redundancy.

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?

For a write operation with no annotations and no output schema, the description should compensate by explaining params and success behavior. It covers error handling but leaves essential invocation details undocumented, making the tool only partially self-explanatory.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain any of the four required parameters (orderId, noteId, text, author). The schema only provides types and minLength, leaving the agent without semantic meaning for any field.

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 a specific verb 'File' and identifies the resource 'triage note against an order', clearly distinguishing it from sibling tools like cancel_order or get_note. The purpose is immediately understandable.

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 given on when to use this tool versus alternatives such as search_note or read_audit_log. The description implies its use when adding a note to an order but does not state exclusions or prerequisites.

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

aggregate_customerA

Group Customer objects by a property, counting each group and optionally summing a numeric property. Query-time aggregation — nothing is precomputed.

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No
`group_by`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

The description adds the key behavioral insight that 'nothing is precomputed', but it does not explicitly state that the operation is read-only or describe what happens with filters. Since no annotations are provided, the description carries this burden, but it is only partially met.

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 fluff. It communicates the core action and a critical behavioral trait efficiently.

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?

With no output schema and no annotations, the description is incomplete. It does not specify the return format or how the optional sum is configured, and it does not explain the role of the filter parameter. The description covers the basic grouping idea but leaves significant operational details ambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate for parameter meaning. It explains that grouping is done 'by a property', but the 'optionally summing a numeric property' feature has no corresponding parameter in the schema, leaving agents confused about how to invoke it. The description adds minimal value for the existing 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 verb 'Group' with the resource 'Customer objects', and specifies the actions 'counting each group' and 'optionally summing a numeric property'. This distinguishes it from sibling search/get tools and other aggregate tools by explicitly scoping to Customer objects.

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 aggregating customer data and notes 'Query-time aggregation', but it does not explicitly state when to use this versus search_customer or other aggregate tools, nor does it mention alternatives or exclusions.

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

aggregate_noteB

Group Note objects by a property, counting each group and optionally summing a numeric property. Query-time aggregation — nothing is precomputed.

ParametersJSON Schema

Name	Required	Description	Default
`filter`	No
`group_by`	Yes

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 must carry the transparency burden. It discloses the query-time nature and counting/summing behavior, but leaves return format and the numeric property trigger unspecified, and omits read-only/safety details.

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 the scope and resource stated immediately. The additional 'query-time' clause provides useful context without bloat.

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?

With no output schema and no documentation of the filter parameter or grouping output shape, the description is incomplete. The ambiguous 'summing a numeric property' is especially problematic for an agent needing to invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description only vaguely references 'a property' for group_by and omits the filter parameter entirely. The mention of 'optional summing a numeric property' introduces a capability not reflected in the schema, misleading the agent.

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 verbs 'Group' and 'counting' to state the aggregation operation on Note objects. It clearly distinguishes from sibling search/get/traverse tools by targeting aggregation specifically.

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 through the aggregation purpose but does not explicitly name alternatives or exclusions. The 'Query-time aggregation' clause hints at a differentiation from precomputed data, but there is no direct when-to-use guidance.

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

aggregate_orderA

Group Order objects by a property, counting each group and optionally summing a numeric property. Query-time aggregation — nothing is precomputed.

ParametersJSON Schema

Name	Required	Description	Default
`sum`	No
`filter`	No
`group_by`	Yes

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It adds one useful trait ('Query-time aggregation — nothing is precomputed'), but it does not state whether the operation is read-only, describe the response format, mention performance considerations, or note any required permissions. This gives some transparency but not enough for a 4.

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 two sentences long, front-loaded with the core action ('Group Order objects by a property'), and the second sentence adds a distinct behavioral note about query-time computation. Every word earns its place, 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?

The tool has three parameters including a nested filter object and no output schema. The description covers the core grouping and summing behavior but gives no guidance on how to use the filter or what the result structure looks like. While adequate for a basic sense of the tool, it leaves gaps for an agent aiming to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It explains the conceptual meaning of grouping and summing, but it omits the 'filter' parameter entirely and does not enumerate which property values are valid for group_by beyond what the schema enums already provide. This is only partial compensation for the undocumented 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 uses a specific verb ('Group') and resource ('Order objects'), clearly distinguishing this aggregation tool from sibling search/get tools. It further specifies the output behavior (counting each group, optionally summing a numeric property), making the purpose unmistakable.

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 states this is a query-time aggregation and that nothing is precomputed, implying it should be used when live aggregated data is needed. However, it does not explicitly name alternative tools (like search_order or get_order) or provide exclusion criteria, so it falls short of fully explicit when/when-not guidance.

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

aggregate_productA

Group Product objects by a property, counting each group and optionally summing a numeric property. Query-time aggregation — nothing is precomputed.

ParametersJSON Schema

Name	Required	Description	Default
`sum`	No
`filter`	No
`group_by`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries the transparency burden. It adds a meaningful behavioral detail: 'Query-time aggregation — nothing is precomputed' implies real-time results. However, it does not disclose other aspects such as read-only nature, performance implications, or output constraints.

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 compact sentences, front-loaded with the main action and optional modifier. No filler or repetitive information; every word contributes to understanding.

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 a nested filter object, no output schema, and no annotations, the description gives a general sense of the output (group counts and optional sum) but omits filter semantics and result format details. It is adequate for the core aggregation but lacks completeness for advanced usage.

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 description explains the role of group_by ('by a property') and sum ('summing a numeric property'), which complements the schema's enums. But it does not mention the filter parameter at all, leaving that aspect to the schema. Since schema description coverage is 0%, the description only partially compensates.

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 a specific verb+resource: 'Group Product objects by a property' and explains the counting and optional summing. This uniquely identifies the tool's function and distinguishes it from similar tools targeting other resources like Customer, Order, or Note.

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 communicates the core use case: query-time aggregation for grouping/counting/summing. It does not explicitly exclude cases or compare with search_product or other aggregate tools, but the resource-specific wording makes when to use it clear.

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

assign_orderA

Assign a pending order to a person for fulfilment. Writes are gated: if a business rule rejects this call, the error is machine-readable ({ code, message }) and the attempt is recorded in the audit log.

ParametersJSON Schema

Name	Required	Description	Default
`orderId`	Yes
`assignee`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations provided, the description takes on the transparency burden. It discloses that writes are gated by business rules, that rejections return a machine-readable error object ({ code, message }), and that attempts are recorded in the audit log. This adds meaningful behavioral context beyond a mere 'assign' statement, though it stops short of detailing all side effects (e.g., order status change) or authentication requirements.

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 two sentences long, front-loaded with the core purpose, and contains no filler. Every sentence adds value: the first identifies what the tool does; the second explains write gating and error behavior.

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 two-parameter mutation tool with no output schema, the description covers the essential parts: the operation, the pending-order constraint, and error/audit behavior. It does not explain the success return value or permissions, but these gaps are less critical given the simplicity of the tool and the existing details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero description coverage (0%), so the description must compensate. It only paraphrases the parameters: 'pending order' implies orderId, and 'person' implies assignee, but it does not explain the expected format of assignee (e.g., user ID, email) or any other constraints beyond the schema's minLength:1. This is insufficient for full 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 action ('Assign'), the target ('a pending order'), and the recipient ('a person for fulfilment'). It is distinct from sibling tools like cancel_order, get_order, and search_order, which perform different operations on orders.

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 specifies the usage context: assigning a pending order to a person for fulfilment. It does not explicitly mention when not to use it or compare to alternatives, but the context is clear enough for an agent to identify this as the correct tool for assignment operations.

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

cancel_orderA

Cancel an order. Shipped orders cannot be cancelled. Writes are gated: if a business rule rejects this call, the error is machine-readable ({ code, message }) and the attempt is recorded in the audit log.

ParametersJSON Schema

Name	Required	Description	Default
`reason`	Yes
`orderId`	Yes

TDQS

A4.1/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 and discloses important behaviors: writes are gated, errors are machine-readable with code and message, and attempts are audited. It also notes the shipped-order restriction, though it omits what happens on success (e.g., resulting order status) or whether cancellation is reversible.

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 two sentences long, front-loaded with the main action, and every phrase contributes value. The gating and audit information is concise and packed with necessary context.

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 absence of annotations and output schema, the description covers the essential behavior, an exception, error format, and audit trail. It stops short of describing the success response or the effect on the order, but for a cancellation tool this is quite complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only implicitly references orderId via 'Cancel an order' and does not explain 'reason' at all. The purpose of the reason parameter is left entirely to inference, and its format or validation is not mentioned.

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 'Cancel' with a clear resource 'order', and immediately adds a key constraint ('Shipped orders cannot be cancelled'), making the tool's purpose unambiguous and distinct from sibling tools like assign_order or add_order_note.

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 an explicit when-not condition for shipped orders, which helps agents avoid misuse. It does not name alternative tools, but the cancellation action is unique among siblings, and the gated-write behavior implies that business rules will be checked.

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

get_customerA

Fetch a single Customer by primary key (id).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A3.8/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 behavior such as what happens when the ID is not found (e.g., null vs error), authentication requirements, or return format. The description only restates the basic fetch operation without adding behavioral context beyond what the name and schema imply.

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 is front-loaded with the verb and resource. Every word contributes, with no redundant details 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 simple single-record fetch with one parameter, the description adequately explains what the tool does. The lack of output schema and annotations is mitigated by the simple nature of the tool, though it could benefit from noting not-found behavior or return structure.

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 description coverage is 0%, but the description compensates by clarifying that 'id' is the primary key. This adds meaningful semantic context to the otherwise bare string parameter, though it does not detail format or constraints.

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', the resource 'Customer', and the method 'by primary key (id)'. This distinguishes it from sibling tools like search_customer and aggregate_customer.

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 you have a specific customer ID and need a single record, but it does not explicitly state when to use this over alternatives like search_customer. No exclusions or comparison to siblings are provided.

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

get_noteA

Fetch a single Note by primary key (id).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

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 the full burden. It conveys a read-only fetch action, which is transparent, but does not disclose behavior for missing ids (e.g., error or null) or any other side effects. It adds no extra behavioral traits beyond the basic 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action, resource, and lookup method.

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 get-by-id tool with one parameter and no output schema, the description is sufficiently complete. It covers the action and key identifier, though it omits error handling details. Given the low complexity, this is adequate.

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 0% and the schema only defines 'id' as a string. The description adds that 'id' is the primary key, which is a small semantic addition. However, it does not provide format, examples, or constraints, leaving room for ambiguity.

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 fetches a single Note by its primary key (id). It uses a specific verb ('Fetch'), specifies the resource ('a single Note'), and defines the lookup method ('by primary key'), distinguishing it from search or aggregate alternatives.

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 you have a specific id and need exactly one Note. However, it does not explicitly mention when not to use it or name alternatives like search_note, even though sibling tools exist. The context is clear but lacks explicit exclusions or alternative guidance.

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

get_orderA

Fetch a single Order by primary key (id).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

A4.2/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 that this is a read-only fetch operation via the verb 'Fetch' and that it returns a single Order. However, it does not mention error handling, authentication requirements, or the structure of the returned object, leaving notable behavioral 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?

The description is a single sentence that is front-loaded with the verb and purpose. There is no waste, and every word contributes to understanding the tool.

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 simplicity of a get-by-id operation, the description covers the core behavior well. However, the lack of an output schema or error behavior leaves some ambiguity about what is returned when the id is valid or not found. Still, it is reasonably complete for a tool of this complexity.

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 provides only a bare 'id' string with no description, so the description compensates by clarifying that 'id' is the primary key of the Order. This adds semantic meaning beyond the schema, though it does not provide details on format or constraints. For a single parameter, this 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 uses a specific verb 'Fetch' with the resource 'Order' and explicitly states 'by primary key (id)', which clearly defines the type of access. This distinguishes it from siblings like search_order, which searches rather than fetches by exact id.

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 phrase 'by primary key (id)' gives clear context that this tool should be used when the exact id is known. It does not explicitly name alternatives or exclusions, but the purpose clarity implies the appropriate use case without ambiguity.

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

get_productB

Fetch a single Product by primary key (id).

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes

TDQS

B3.3/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 of behavioral disclosure. It indicates a read operation through 'Fetch' but gives no details on error behavior (e.g., missing id), return structure, or whether the product exists. This is 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence that directly communicates the tool's purpose without any filler. Every word contributes to understanding what the tool does.

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 get-by-id tool with one parameter and no output schema, the description covers the core function adequately. However, without annotations or output schema, it leaves the return shape and not-found behavior unspecified, making it minimally complete but not fully self-sufficient.

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 0%, but the description adds the semantic meaning that 'id' is the primary key, which is not present in the schema's raw type definition. It does not provide formats, examples, or related lookup guidance, so it only partially compensates for the schema's lack of descriptive detail.

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 the specific verb 'Fetch' and clearly identifies the resource ('a single Product') and the lookup mechanism ('by primary key (id)'). This distinguishes it from sibling tools like search_product (searching) and aggregate_product (aggregation), as well as from get_order/get_customer/get_note by naming the resource.

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 search_product for filtered lookups or clarify that this tool requires a known primary key. Usage context is only implied by the wording, not explicitly stated.

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

read_audit_logA

Read the append-only audit log: every applied and rejected action, with actor and params. This is an unscoped administrative view — entries are not filtered by visibility (fail-open, declared).

ParametersJSON Schema

Name	Required	Description	Default
`action`	No
`status`	No
`target`	No

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the log is append-only (immutability), contains both applied and rejected actions with actor/params, and is explicitly fail-open and unscoped, which are critical behavioral traits. This is strong transparency, though it omits concerns like pagination or permissions.

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 short sentences, front-loaded with the main purpose, then a key caveat. 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?

The description gives a good high-level overview but lacks details on filter semantics, return structure, and access controls. Given the absence of an output schema and annotations, these gaps reduce its completeness, though the tool is relatively simple.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the meaning of the 'action' or 'target' parameters or how they interact with the log. Only 'status' is partially clarified by the phrase 'applied and rejected'. This is insufficient compensation for the missing schema descriptions.

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 'Read the append-only audit log: every applied and rejected action, with actor and params', which clearly identifies the tool's function and distinguishes it from sibling tools focused on orders, customers, and products. The 'unscoped administrative view' phrase further clarifies its role.

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 communicates that this is an unscoped administrative view, implying it is for admin-level audit use where visibility filters are bypassed. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusionary guidance.

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

search_customerB

Search Customer objects (A customer of the merged company). All filter fields are optional and match by equality. Results are scoped by the model-attached visibility policy for this session.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`name`	No
`region`	No

TDQS

B3.4/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 useful behavioral traits: 'All filter fields are optional and match by equality' and results are 'scoped by the model-attached visibility policy'. However, it does not describe the return format, pagination, or behavior when no filters are supplied, leaving 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?

The description is two concise sentences with no unnecessary words. The action and resource are front-loaded, and the behavioral details are efficiently conveyed.

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 tool with three optional parameters and no output schema, the description covers the key semantics: optional equality filters and visibility scoping. It does not explicitly state that it returns a list of Customer objects, but the verb 'Search' implies a list. Given the low complexity, it is fairly complete, though explicit mention of the return structure would improve it.

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 0%, so the description must compensate. The statement that all filter fields are optional and match by equality adds meaning beyond the bare property names. However, it does not elaborate on each field beyond its name, and no additional details like allowed formats or examples are provided.

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 ('Search') and the resource ('Customer objects'), and adds context that a customer is 'of the merged company'. It clearly differentiates from other search tools by resource name, but does not explicitly contrast with siblings such as get_customer or aggregate_customer.

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 given about when to use this search tool versus alternatives like get_customer or aggregate_customer. The only usage-related information is about filter optionality and equality matching, which pertains to parameter usage, not tool selection.

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

search_noteA

Search Note objects (A triage note — state no source system has a table for). All filter fields are optional and match by equality. Results are scoped by the model-attached visibility policy for this session.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`text`	No
`author`	No

TDQS

A4/5.0

Behavior4/5

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

With no annotations provided, the description carries the burden and provides useful behavioral details: filters match by equality, all fields are optional, and results are scoped by the visibility policy. This goes beyond a bare 'Search' statement, though it does not cover return format or pagination.

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 three concise sentences with no fluff. The first defines the resource, the second explains filter behavior, and the third discloses visibility scoping. Every sentence adds value.

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 lacking an output schema, the description covers purpose, resource definition, filter semantics, and security scoping. It does not mention return type or pagination, but for a simple search with three optional string filters, this is reasonably 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 0% and parameters are described only by name (id, text, author). The description adds that all filters are equality-based and optional, which is useful but generic. Field-specific semantics are not expanded upon, though property names are self-explanatory.

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 searches Note objects and defines what a Note is ('A triage note — state no source system has a table for'), distinguishing it from siblings like get_note or aggregate_note. The verb 'Search' is specific and matches the tool's name.

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 through 'All filter fields are optional' but does not explicitly state when to use search_note versus alternatives such as get_note for fetching by ID. No exclusions or alternative tools are mentioned, so guidance is only implicit.

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

search_orderA

Search Order objects (A sales order, unified across both legacy systems). All filter fields are optional and match by equality. Results are scoped by the model-attached visibility policy for this session.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`total`	No
`status`	No
`assignee`	No
`sourceId`	No
`sourceSystem`	No

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that filter fields match by equality and that results are scoped by a visibility policy—both non-obvious behaviors. It does not explicitly state read-only status, but 'Search' implies a non-mutating operation. This is good but not complete, as it omits potential details like pagination or result shape.

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 and front-loaded with the core purpose. It uses three short sentences that each add value: purpose, filter behavior, and visibility scoping. No redundant or fluff content appears.

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 search tool with no output schema and no annotations, the description covers essential aspects: what is searched, how filters work, and a crucial session-scoping detail. It does not mention return format or pagination, but the tool name and typical search semantics make these less critical. Given the low complexity of the parameters, this is reasonably 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 description coverage is 0%, so the description must compensate. The statement 'All filter fields are optional and match by equality' adds meaningful behavior about how parameters work. However, it does not explain the semantics of individual fields beyond their names, leaving the agent to infer meaning. This is adequate but not thorough.

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 function with a specific verb+resource: 'Search Order objects'. The parenthetical 'A sales order, unified across both legacy systems' adds valuable context that distinguishes it from other order-related tools like get_order. This is a precise and unambiguous purpose statement.

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 alternative search/get tools. There is no mention of alternatives like get_order for fetching a single order, or any scenario-based recommendations. The only usage-related information is that filters are optional and equality-based, which is more about parameter behavior than usage context.

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

search_productA

Search Product objects (An item from the ERP item master). All filter fields are optional and match by equality. Results are scoped by the model-attached visibility policy for this session.

ParametersJSON Schema

Name	Required	Description	Default
`id`	No
`name`	No
`stock`	No

TDQS

A3.6/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It discloses important behavioral details: results are scoped by the model-attached visibility policy, and filters match by equality. However, it doesn't mention potential limits, ordering, or return format, which would improve transparency for a search 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?

The description is two sentences long, front-loaded with the core purpose, and every sentence adds value. It avoids repetition and is appropriately sized.

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 search tool with three optional filters and no output schema, this description provides the essential information: what it searches, how filters work, and session scoping. It doesn't explain pagination or result limits, but these are not necessarily critical for this tool's usage. Overall, it is sufficiently complete for most use cases.

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 schema has three parameters (id, name, stock) with no individual descriptions, so the description's statement that all filters are optional and match by equality adds meaningful collective semantics. It does not, however, provide per-parameter details beyond types already in the schema, so overall parameter guidance is moderate.

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 searches for Product objects from the ERP item master, using a specific verb ('Search') and resource ('Product objects'). While it doesn't explicitly differentiate from sibling tools like get_product or aggregate_product, the name and scope make its purpose unambiguous.

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 that all filter fields are optional and match by equality, giving clear context on how to use the search. However, it does not provide explicit guidance on when to choose this tool over alternatives like get_product (for single fetch) or aggregate_product (for analytics), so usage guidance is implied rather than explicit.

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

traverse_customer_ordersA

Traverse the Customer → Order link "customerOrders" (one-to-many). direction=forward: pass a Customer pk, get linked Order objects. direction=reverse: pass a Order pk, get linked Customer objects.

ParametersJSON Schema

Name	Required	Description	Default
`pk`	Yes
`direction`	No		forward

TDQS

A4.2/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 core traversal behavior and direction semantics but does not mention pagination, ordering, error handling, or explicit read-only guarantees. It is functional but lacks richer 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?

Two compact sentences cover purpose and direction logic with no redundancy. The most important information (link and direction) is 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?

For a simple traversal tool with no output schema, the description adequately explains inputs and expected results. It lacks details on result format or edge cases, but the core usage is well covered.

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 provides only types and an enum, but the description adds crucial meaning: pk's role depends on direction, and direction determines traversal direction. This significantly clarifies parameter usage 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 traverses the Customer → Order link 'customerOrders' (one-to-many), with explicit direction semantics. It distinguishes itself from sibling traversal tools by naming the specific relationship.

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 direction-specific instructions (which pk to pass and what objects are returned), effectively guiding when to use it. However, it does not explicitly mention alternatives or exclusions (e.g., when to prefer direct get/search tools over traversal).

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

traverse_order_notesA

Traverse the Order → Note link "orderNotes" (one-to-many). direction=forward: pass a Order pk, get linked Note objects. direction=reverse: pass a Note pk, get linked Order objects.

ParametersJSON Schema

Name	Required	Description	Default
`pk`	Yes
`direction`	No		forward

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations provided, the description carries the burden of behavioral disclosure. It explains the core behavior (pass pk, get linked objects) and mentions the one-to-many nature, but doesn't cover edge cases like empty results, error handling, or whether the operation is read-only. This is adequate but not rich.

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 two sentences, highly concise, and front-loaded with the link name and relationship. Every word contributes to understanding the tool's purpose and usage, with no filler or redundancy.

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 2-parameter traversal with no output schema, the description covers the essential usage and behavior. It lacks explicit details about return format or error behavior, but 'get linked Note objects' reasonably implies the response. Overall, it's nearly complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds significant meaning to both parameters: it clarifies that pk is the Order or Note primary key depending on direction, and explains the effect of choosing 'forward' vs 'reverse'. This goes well beyond the raw schema, which only provides a generic 'pk' and an enum.

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 traverses the Order→Note link 'orderNotes', a one-to-many relationship, and explains both directions. This distinguishes it from sibling traversal tools like traverse_customer_orders or traverse_order_products by naming the specific entities and link.

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 provides explicit instructions for both directions: forward requires an Order pk, reverse requires a Note pk. This gives clear context on when to use each mode, though it doesn't explicitly mention alternatives or when not to use the tool.

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

traverse_order_productsA

Traverse the Order → Product link "orderProducts" (many-to-many). direction=forward: pass a Order pk, get linked Product objects. direction=reverse: pass a Product pk, get linked Order objects.

ParametersJSON Schema

Name	Required	Description	Default
`pk`	Yes
`direction`	No		forward

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden but covers only the core traversal behavior. It explains how the direction parameter changes the result but does not mention return format, error handling, or whether it is read-only.

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 two compact sentences, front-loading the purpose and then providing direction-specific details. Every sentence adds clear value with no redundancy.

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 low complexity (2 params, no output schema), the description adequately covers the main use cases and expected result types. It omits edge cases like missing records or response structure but remains sufficient for a straightforward traversal 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?

Schema coverage is 0%, so the description must compensate. It effectively explains the meaning of direction (forward/reverse) and the role of pk dependent on direction, which goes well beyond the raw schema. It could add detail on pk format but is substantially helpful.

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 traverses the Order → Product many-to-many link 'orderProducts', with direction-specific behavior. This specific resource and action distinguish it from sibling traversal tools like traverse_customer_orders and traverse_order_notes.

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 explains both forward and reverse usage with concrete examples (pass Order pk or Product pk). It provides clear context for when to use each direction, though it does not explicitly contrast with alternative traversal tools.

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.

19 tool updatesv0.1.0Aug 1, 2026
- First observedadd_order_note
- First observedaggregate_customer
- First observedaggregate_note
- First observedaggregate_order
- First observedaggregate_product
- First observedassign_order
- First observedcancel_order
- First observedget_customer
- First observedget_note
- First observedget_order
- First observedget_product
- First observedread_audit_log
- First observedsearch_customer
- First observedsearch_note
- First observedsearch_order
- First observedsearch_product
- First observedtraverse_customer_orders
- First observedtraverse_order_notes
- First observedtraverse_order_products

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Scored 2026-08-01 14:55 across 19 tools

Disambiguation5/5

Each tool targets a distinct resource and action: search/get/aggregate per entity, traversal per relationship, and order-specific write operations are clearly separated. No two tools overlap in purpose.

Naming Consistency5/5

All tool names follow a consistent verb_noun (or verb_noun_noun for traversals) snake_case pattern, e.g., search_customer, get_order, aggregate_product, traverse_order_notes. No mixed conventions.

Tool Count4/5

19 tools is slightly above the typical 3-15 range, but the scope spans four entity types plus traversal and audit log, so the count is justified and not bloated.

Completeness4/5

The read/search/aggregate/traverse surface is comprehensive, and order lifecycle operations (cancel, assign, add_note) are covered. Missing create/update/delete for some entities, but this appears intentional given the operational focus.

Maintenance

ActivityMaintained

ResponsivenessResponsive

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Maplith AOAuth
com.maplith
Data-ontology maps of your business systems, served to AI agents over MCP.
Data Platforms Knowledge & Memory
131
Supero B
io.github.supero-platform
Build multi-tenant apps over MCP. Schemas, CRUD, deploys — access control enforced server-side.
Cloud Platforms Developer Tools Databases
641
Algenta MCP Server B
io.github.thyn-ai
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Data Platforms Search RAG Systems
1402
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

Related MCP Servers

open-ontologies
Knowledge & Memory Databases Developer Tools
fabio-rovai
A
license
A
quality
A
maintenance
AI-native ontology engineering MCP server for OWL/RDF/SPARQL. Validate, query, diff, lint, version, and govern knowledge graphs via Oxigraph triple store.
Updated 6 days ago (2026-09-05 19:02 UTC)
42
479
MIT
ORMCP Server
Databases Developer Tools
SoftwareTree
F
license
Not graded
quality
B
maintenance
ORMCP Server is a database-agnostic MCP server that exposes relational databases as governed business objects (Customers, Orders, Products) for AI agents via ORM abstraction — instead of raw SQL or schema access. Works with any JDBC-compliant database (PostgreSQL, MySQL, Oracle, SQL Server, SQLite, and more). Reduces LLM token consumption by 60-70% through semantic data abstraction.
Updated a month ago (2026-08-14 22:06 UTC)
6
-
MCP API Tool Demo
Customer Data Platforms Search
jordansilly77-stack
F
license
Not graded
quality
B
maintenance
Demo MCP server that exposes order and customer data as read-only tools for AI assistants, simulating a business API or internal data source.
Updated 3 months ago (2026-06-26 04:55 UTC)
-
Orion CLI
Command Line Developer Tools
GoPlasmatic
A
license
Not graded
quality
A
maintenance
CLI + 46-tool MCP server for the Orion declarative services runtime — build and operate REST/Kafka services, manage workflows, channels, connectors, traces, and backups.
Updated 2 months ago (2026-07-19 06:36 UTC)
5
Apache 2.0