Skip to main content
Glama

omniseek_ruling

Create, list, or delete same_as/not_same_as rulings for graph node pairs to collapse or reject them in views. Verdicts persist as declarative state applied at read time.

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).

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. Dates show when Glama detected each change.

  1. First observedv0.2.0

TDQS

A5/5.0
Behavior5/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 does so thoroughly. It discloses that OmniSeek never makes a ruling itself, only stores user judgment as declarative state and applies it at read time. It also explains pair normalization, replacement semantics, the git-history audit trail, and error conditions, which goes well beyond typical tool descriptions.

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 dense but well organized: trigger, conceptual model, pair-key semantics, action contracts, and sibling separation. Every sentence earns its place, and the most important when-to-use information is front-loaded. The length is justified by the need to document a write tool with no annotations or output schema.

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 mutating tool with no annotations and no output schema, this description is complete. It covers all three actions, expected returns, error cases, overwrite/delete behavior, and the relationship to omniseek_graph. An agent has enough information to invoke all actions correctly and interpret results.

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 each action value, the verdict values, the optional note, and the src/dst pair key semantics. It also explains action-specific return fields such as replaced and deleted, making the parameters meaningful without schema help.

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?

States a precise trigger condition: use when two graph nodes are or are not the same person/entity and views should collapse them. The description clearly names the resource and operations: record/list/retract same_as or not_same_as rulings. It also distinguishes itself from omniseek_graph, so the agent can tell them apart.

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

Usage Guidelines5/5

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

Opens with an explicit 'Use WHEN' condition and closes with a clear separation argument explaining why this is not folded into omniseek_graph due to the read-only batching constraint. This gives concrete routing guidance for choosing this tool over the main graph tool. It does not compare directly to omniseek_resolve_identity, but the trigger condition is specific enough to route correctly.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Battam1111/omniseek'

If you have feedback or need assistance with the MCP directory API, please join our Discord server