Skip to main content
Glama

omniseek_ruling

Record, list, or delete same-entity rulings between two graph nodes, controlling whether views collapse or separate them. Apply your verdict to resolve duplicate identities.

Instructions

Use WHEN two graph nodes ARE (or are NOT) the same person / entity and you want views to collapse them — record / list / retract same_as | not_same_as rulings (the one judgment channel the graph's working policy applies).

Fully-qualified MCP name: mcp__omniseek__omniseek_ruling (server name is omniseek; there is no omniseek-eye server).

OmniSeek never MAKES a ruling; it STORES yours as declarative state and APPLIES it at read time (the sensors.json precedent: judgment persisted as config OmniSeek executes mechanically). A ruling says "these two graph nodes ARE / are NOT the same entity"; omniseek_graph's working and exploratory policies then collapse (or reject) that pair when projecting a view. The pair is the KEY: it normalizes to src < dst, re-creating a pair REPLACES the prior verdict (declarative state, not a log; git history is the audit trail).

action picks what to do: • action="create" (src, dst, verdict="same"|"not_same"; optional note) -> record the ruling. Returns {created: true, ruling, replaced} (replaced=true if it overwrote a prior verdict for the pair). A bad verdict / empty or identical endpoints -> {"error": ...}. • action="list" -> {rulings: [{src, dst, verdict, note, ruled_at}], count}. • action="delete" (src, dst) -> {deleted: true/false} (false if no ruling existed for the pair).

This is a SEPARATE tool from omniseek_graph (not an omniseek_graph action) because omniseek_graph is batchable in omniseek_gather ONLY because it is read-only; folding a write into it would let the gather whitelist write. Unknown action -> {"error": ...}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dstNo
srcNo
noteNo
actionYes
verdictNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description fully carries the behavioral burden and does so impressively. It discloses that OmniSeek never makes rulings but stores them declaratively, that pairs normalize to src < dst, that re-creating a pair replaces the prior verdict, and that git history is the audit trail. It also details per-action behavior and error cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The description is dense and front-loaded with the use case and core semantics. The fully-qualified MCP name paragraph and the extended separation rationale add useful context but go slightly beyond what is strictly necessary, keeping this from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 5-parameter tool with no output schema and no annotations, the description is complete. It covers all actions, return shapes, replacement semantics, error cases, and the relationship to graph policies, so an agent can invoke the tool correctly without additional documentation.

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?

Schema description coverage is 0%, so the description must compensate, and it does. It defines the action values ('create', 'list', 'delete'), verdict values ('same' | 'not_same'), the required operands for each action, the optional note, pair normalization, and error conditions like bad verdicts or empty/identical endpoints.

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 opens with a specific trigger ('Use WHEN two graph nodes ARE (or are NOT) the same person/entity...') and a specific operation ('record / list / retract same_as | not_same rulings'). It clearly names the resource (rulings) and explicitly separates itself from omniseek_graph, so an agent can distinguish it from siblings without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

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

It gives an explicit when-to-use condition and explains why this write operation is deliberately not part of omniseek_graph, which is strong routing guidance. It does not explicitly compare against sibling tools like omniseek_resolve_identity, so not a perfect 5, but the trigger and separation rationale are clear.

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