Server Quality Checklist

Tool Scores

• omniseek_paper_recommendA
  4.2/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 behavioral burden. It discloses the underlying model (SPECTER + co-citation), that it surfaces very recent work outside the citation graph, and that results are ordered by S2 relevance and require re-judgment. It does not mention rate limits or error behavior, so it stops short of a 5.

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

  Conciseness3/5

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

  The key use case is front-loaded, but the description is repetitive: SPECTER/co-citation, the sibling contrasts, and 'very recent work' are each stated twice. The guidance could be condensed meaningfully without losing information.

  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 tool with no output schema, the description supplies a return JSON skeleton, ordering guidance, seed ID formats, and alternative routing. This is complete for normal use; the only clear gap is limit semantics and possible empty/error responses.

  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. It thoroughly explains 'ids': accepted formats, one-vs-many semantics, and the OpenAlex source_id pitfall. However, 'limit' is never described, leaving its effect on 'n' and result count to be inferred only from the schema default.

  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 use case: given a paper, get semantically similar papers via SPECTER embeddings. It explicitly contrasts this tool with omniseek_search (keyword) and omniseek_field_skeleton (citations), so an agent can clearly distinguish it from siblings.

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

  Usage Guidelines5/5

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

  It states exactly when to use it ('Use WHEN you have a paper and want more like it'), what inputs to pass (arXiv IDs/DOIs/S2 IDs), and when to choose alternatives: citation neighborhood -> omniseek_field_skeleton, keyword search -> omniseek_search. It also includes a concrete OpenAlex ID-format warning that prevents a likely error.

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

• omniseek_field_skeletonA
  4.6/5.0
  Behavior5/5

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

  With zero annotations, the description carries the full burden of behavioral disclosure, and it delivers extensively: it states the tool makes 'NO judgment,' auto-picks seeds, bails early with a PARTIAL map when the deadline hits rather than hanging, and warns about poisoned OpenAlex titles (the corrupted GPT-3 record example). It also reveals edge cases like 'contexts is empty when S2 never parsed the citing PDF' and its default sort-by-in_degree behavior.

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

  Conciseness3/5

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

  The purpose is front-loaded in the first sentence and the bolded section headers (SEEDS, SOURCE, BUDGET, etc.) make the long content skimmable. But the description is exceptionally long, with stylistic asides like 'YOU are the cartographer — do ALL the intelligence over this raw data' and emphatic flairs that add tone rather than facts; a tighter edit preserves the same information at roughly two-thirds the length.

  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 8 optional params, zero annotations, 0% schema coverage, and no output schema, the description is impressively complete: it spells out the full return structure, deadline/partial-result behavior, data-quality caveats, the gap-detection workflow (seed_ref_freq/seed_cite_freq), and the source-selection decision tree. The only real gaps are three parameters (fresh, max_nodes, citers_per_seed) that go entirely unexplained, though two of those are reasonably inferable from their names.

  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 — and it deeply explains query (auto-picks top-relevance seeds), seeds (OpenAlex work-ids as user-chosen anchors, preferred once you know the field), source (openalex vs s2 tradeoffs including arXiv coverage and influential/intent signals), and deadline_s (~25s default, partial-result behavior). However, fresh, max_nodes, and citers_per_seed receive no semantic explanation, and n_seeds is only implied, leaving several parameters undocumented in both the schema and the description.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line 'Map a research field's shape' pairs a specific verb with a clear resource, and 'use WHEN you need its citation neighborhood (foundational core by citations vs frontier by date)' states the exact trigger condition. It differentiates from siblings by routing co-authorship needs to omniseek_coauthors and framing its unique niche (citation neighborhood with in_degree signal) against the other omniseek tools.

  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?

  The description gives explicit when-to-use ('use WHEN you need its citation neighborhood... to cluster yourself') and when-not-to-use guidance ('For a young/hot field the best graph is often a human-curated survey/awesome-list, fetch that yourself instead'). It also names concrete alternatives (omniseek_read for verification, omniseek_coauthors for co-authorship) and gives source-selection criteria (openalex for established fields vs s2 for recent/arXiv-heavy ones).

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

• omniseek_curator_actA
  4.7/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 handles it well. It discloses side effects (adds candidate, records verdict, writes overlay row), mechanical safety gates ('MECHANICALLY REFUSES an admit on hard red-line', 'MECHANICALLY REFUSES a PRUNE'), reversibility ('REVERSIBLE overlay row', 'rollback_live'), and the fact that unknown verbs return an error dict. It also clarifies that wall_probe only surfaces render-derived facts and never admits, which prevents a dangerous misassumption.

  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 long, but it is a multi-verb dispatcher and nearly every line adds necessary invocation detail. The front-loaded opening states the tool's purpose immediately, and the verb-by-verb format is scannable. Some jargon and parentheticals (e.g., SSRF-pin proxy, M7, foundry-grade) add density, but they are meaningful for correct action selection rather than filler.

  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?

  This is a complex tool: 18 parameters, 10 distinct verbs, conditional requirements, state transitions, and no output schema or annotations. The description covers all verbs, their arguments, side effects, refusal conditions, and error behavior, and even describes return surfaces ('persist + return the packet', 'surfaced in the packet', 'returns an error dict'). Nothing essential for an agent to select and invoke the correct action is missing.

  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 schema provides no descriptions for any of the 18 parameters, but the description compensates comprehensively by mapping each verb to its required and optional parameters: submit requires name, urls, mode, domain, family; decide requires baseline_ref to admit; retire_live needs confirm; source_verdict takes prune_class and coverage_impact. It also explains parameter semantics such as mode enum values, confirm=False preview behavior, and the draft working-artifact structure. This far exceeds what the bare schema offers.

  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 clear directive: use this tool when acting on the source-curation protocol and performing a WRITE source-lifecycle action. It enumerates the exact verbs (submit, probe, decide, apply_live, etc.), each with a specific resource and effect, which fully disambiguates it from read-only siblings like omniseek_curator_view. This is a specific verb+resource statement, not a tautology.

  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 explicitly says when to use the tool ('Use WHEN acting on the source-curation protocol — WRITE a source-lifecycle action') and gives per-verb eligibility conditions, such as wall_probe being eligible on parked_p2 or an awaiting_verdict candidate, and stage_commit being for the non-auto subclass. It does not spell out explicit alternatives like 'use omniseek_curator_view for reads,' but the WRITE qualifier and sibling context make the boundary clear.

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

• omniseek_gatherA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description fully discloses behavior: execution is parallel, failures are independent, calls may continue as background threads after wait_s, warming status is reported, and signature mismatches produce hints. This goes well beyond what the bare schema could convey.

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

  Conciseness4/5

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

  The description is longer than average, but the length is justified by the orchestration behavior and return formats. It is front-loaded with the core purpose and uses labeled sections for calls, wait_s, and return value, though a few phrases like 'the agent decides WHAT to call (judgment)' add flavor but not essential information.

  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 complex tool with no annotations and no output schema, the description covers input format, constraints, timeout semantics, background execution, return shape, and error hints. An agent has enough information to invoke it 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 coverage is 0% and the schema is generic, but the description defines both parameters concretely: calls as a list of {tool, args} objects with a max of 10, and wait_s as a patience budget with a default behavior. The example makes the expected structure unambiguous.

  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 leads with a specific, action-oriented statement: 'Run N independent read-only eye tools IN PARALLEL, returning results in one response.' This clearly identifies the tool as a parallel orchestrator for read-only tools, and the example using omniseek_search plus the list of sibling read tools makes it distinguishable from single-call siblings like omniseek_read and omniseek_search.

  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 clear conditions for use: independent calls, read-only tools only, max 10, and it explicitly says dependent calls belong in a separate gather. It does not name a specific sibling as the alternative for single calls, but the separation guidance and read-only restriction provide enough context to choose correctly.

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

• omniseek_graphA
  4.7/5.0
  Behavior5/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, and it meets it thoroughly. It discloses read-only semantics, budget clamping with capped flags, fail-open error behavior, structural exclusion of judgment tier, reversible identity collapsing, and cold-start expectations. This is far beyond what annotations would normally provide.

  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 long, but the tool has a generic two-parameter ABI with an open family of views, so extensive enumeration is justified. Structure is strong: the trigger sentence comes first, sections are separated, and each view is named with its arguments and semantics. Some philosophical asides and redundancy could be trimmed, which keeps it from a perfect conciseness score.

  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?

  There is no output schema and no annotations, so the description is the only source of operational context. It covers all invocation paths, per-view outputs, cap behavior, error dicts, cold-start expectations, the live view catalog, and the relationship to omniseek_ruling. Nothing an agent needs to select and call this tool correctly is missing.

  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 input schema is extremely generic (view string plus arbitrary args object) with 0% description coverage, so the description must compensate entirely. It does: it enumerates every view, its exact parameter names, defaults, constraints, return behavior, and error cases. An agent can construct valid calls for find, stats, neighborhood, between, voices, since, and similar without any additional lookup.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence states exactly when to use the tool: to see how two entities connect or what OmniSeek knows around a paper, author, or entity. It explicitly positions the tool as a read-only projection of an accumulated evidence graph with typed edges, which clearly differentiates it from the write-oriented omniseek_ruling and the broader search/read tools.

  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 gives explicit when-to-use conditions ('Use WHEN you want HOW two entities connect...') and specifies that identity rulings are written via omniseek_ruling while this tool stays read-only. It also marks non-goals such as vec_thin not feeding search's recall. However, it does not systematically name all sibling tools as alternatives, so an agent must infer some routing boundaries.

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

• omniseek_sourcesA
  4.7/5.0
  Behavior5/5

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

  With zero annotations provided, the description carries the full burden of behavioral disclosure — and it is exceptionally thorough. It reveals that a bare call does NOT dump every facet (bounded orient), that facets arrive on demand, that near-misses return did_you_mean rather than silent empties, that check_health does a slow LIVE probe, and that count over-states coverage while backend_count is the honest figure. These are exactly the non-obvious traits an agent needs.

  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 long, but justifiably so for a tool with zero annotations, zero schema descriptions, and no output schema — it must carry the entire contract. It is well-structured and front-loaded: purpose first, then orient behavior, then each narrowing mode, then the return contract. A few phrases are flowery ('brain_orient's lesson', 'the full catalog of why-strings...') and could be trimmed, but nearly every sentence carries unique, non-redundant information.

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

  Completeness5/5

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

  Given the tool's complexity (5 optional parameters, two distinct return shapes, no output schema, no annotations), the description is remarkably complete. It covers all invocation modes, the full return contract for both bare and narrowed calls, edge cases (did_you_mean, explicit_only_reason presence), performance caveats (check_health slow), capability discovery, and honest counting semantics. Nothing an agent needs to call this tool correctly is missing.

  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 fully compensate — and it does. Every one of the 5 parameters (query, domain, region, verbose, check_health) gets rich semantics: domain filters with full descriptions and closed vocabulary, query does token-overlap with cross-lingual support, region filters with did_you_mean, verbose returns the full unfiltered list, and check_health has documented speed costs and a system block. This far exceeds the bare schema titles.

  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 verb and resource: 'List all sources — call this to ROUTE before searching.' This states the tool's function precisely and positions it distinctly from the 16 sibling tools as the pre-search discovery/routing tool, not a search or graph tool. The distinction is reinforced throughout with the orient vs. narrowed vs. verbose call modes.

  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 gives explicit when-to-use context: 'call this to ROUTE before searching' and explains each invocation mode (no-arg orient, domain= as 'the most RELIABLE router', query=, region=, verbose, check_health) with concrete guidance. However, it never explicitly names sibling alternatives or states when NOT to use this tool (e.g., 'use omniseek_search when you want actual search results'), so the exclusion is only implied.

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

• omniseek_institution_cohortA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries the full behavioral burden and does so richly: it discloses ranking by output at that institution in that field, the juniors-surface property, the all-fields fallback when concept is omitted, the recency effect of year_from, and the OpenAlex data limitation about no PhD-student flags.

  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 front-loaded with the primary use case and packs substantial guidance into two paragraphs plus a return shape. It is slightly redundant with repeated 'people-roster' phrasing and the niche 'SG/Canada cohort question' reference, but no sentence is purely filler.

  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?

  This tool has no annotations and no output schema, so the description must cover purpose, usage, parameter semantics, behavioral caveats, and return shape. It does all of this: return fields are listed, important failure-of-verification caveats are stated, and sibling drill-in tools are referenced. The only minor gap is the limit parameter, which is already self-explanatory from the schema default.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description must explain the parameters itself. It does this well for institution, concept, and year_from, with concrete examples like concept='machine learning'. However, the limit parameter is not mentioned in the description, relying entirely on its name/default in 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 opens with a specific verb-resource pair: producing the people-roster of a lab/department/university, and clearly frames the tool as answering the 'who's at this lab' question. It explicitly distinguishes itself from co-authorship tools by noting that same-lab, no-coauthorship is still a tie, so an agent can separate this tool from omniseek_coauthors.

  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?

  The description states when to use the tool, what optional scoping to provide (concept, year_from), and what not to expect: the roster is a starting point, not a verified lab-member list. It also names the downstream drill-in tools (omniseek_coauthors / omniseek_read), giving clear alternative/next-step guidance.

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

• omniseek_sensorA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description takes on full behavioral disclosure. It describes automatic scheduling with defaults (hourly | daily | weekly; unknown = daily), manual run behavior, diff against baseline, notification narrowing, absence detection, deletion semantics, and error returns for unknown actions or missing required args.

  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?

  Despite being long, the text is tightly organized with a front-loaded purpose statement, a clear 'ONE verb' framing, and bullet-per-action structure. Every sentence adds operational detail needed to invoke the tool correctly, so the length is justified.

  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 multi-action monitor tool with no output schema, no annotations, and a bare input schema, the description is complete: it covers all actions, required arguments, optional arguments, defaults, return shapes, and error behavior. An agent can determine how to create, list, delete, run, and configure notifications without external information.

  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 coverage is 0%, so the description is solely responsible for explaining the 9 parameters. It does so action by action: required args for create, list, delete, and run, plus optional behaviors for sources, schedule, notify, notify_if, notify_if_match, and detect_absence, and sensor_id usage.

  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 concrete verb-resource pairing: MONITOR a query over time and be told only what's NEW, i.e. standing queries with novelty detection. It also explains that `action` selects the sub-operation, making the tool's role distinct from one-off search or read siblings.

  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 explicitly states when to use the tool (when you want to monitor over time and see novelty), and it details each action's use case, including manual triggering vs automatic scheduling. It does not explicitly name alternatives or say when not to use it, so it stops one step short of a 5.

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

• omniseek_coauthorsA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and meets it: it discloses that co-authorship is reconstructed from PRIOR work, split IDs are merged, results are mechanical and non-interpretive, sub-community cooc is included, and 'degraded' means upstream lookup failure. This is far beyond a typical description.

  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 long and dense, but it is front-loaded with the core use case and uses bullets and a structured return summary. Some repetition exists (the prior-work reconstruction is mentioned twice), yet nearly every sentence carries operational value for a tool with no annotations.

  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?

  There is no output schema, so the description must explain return values and edge cases. It provides the full return shape, semantics for nodes/edges/bridges/cooc, the degraded flag meaning, and instructs how to harvest ids for further drill-down. For the tool's complexity, this is complete.

  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%, but the description compensates fully. It explains author inputs as names, ids, or '+'-joined ids for merged split identities; hints/papers as parallel disambiguation lists; and source via the openalex default and the 's2' alternative for juniors. Each parameter gains operational meaning that the schema lacks.

  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 concrete use case: 'WHO a researcher collaborates with — advisor + closest collaborators by joint-paper count, or how a paper's author group is connected.' This clearly states the verb, resource, and scope. It also distinguishes itself from WebSearch and names the sibling tool for the citation/influence layer, so an agent can tell it apart immediately.

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

  Usage Guidelines5/5

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

  The description gives explicit 'Use WHEN' conditions, explains the N=1 vs N>1 modes, tells the agent to pull names/ids from omniseek_resolve_identity, and explicitly routes to omniseek_field_skeleton for a different layer. It also tells the agent that an empty graph may be missing data to retry, not a real 'no collaborators' result.

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

• omniseek_readA
  4.9/5.0
  Behavior5/5

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

  No annotations exist, so the description carries the full burden — and it delivers extensively. It discloses auto-routing rules, the windowing/pagination protocol (truncated flag, bump start_char by returned_chars), the arXiv two-tier /abs vs /pdf behavior, the matched:false reason taxonomy (walled/empty/blocked), that export_media/ocr are IGNORED on the URL branch, and the honest caveat that OCR is mechanical transcription, not figure interpretation. This is exemplary behavioral disclosure for a dual-branch tool.

  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 long but earned: the tool is genuinely complex with two branches, five parameters, and no output schema. Markdown-style headers (URL BRANCH, DOCUMENT BRANCH, WHERE THE FILE LIVES, WHAT COMES BACK, THE IMAGE HALF) make it scannable. Minor redundancy exists — windowing is explained twice, once per branch — and some phrasing ('unchanged from before', 'be honest about it') adds color without information. Nearly every sentence earns its place, but a few could be tightened.

  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 complex auto-routing tool with 5 parameters, no output schema, and no annotations, the description is essentially complete. It documents both return shapes, error/edge cases (matched:false reasons, {source, error, inbox_files?}), the file-ingestion workflow (scp to inbox), caching, and parameter interactions across branches. An agent has everything needed to call this tool correctly and interpret its 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 fully — and it does. target's routing semantics (path vs extension vs URL), start_char/max_chars windowing with paging instructions, and the branch-specific behavior of ocr / export_media are all explained in detail. Every one of the 5 parameters gains meaning beyond its schema definition.

  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 clear verb+resource pair: 'Read text from any URL OR document FILE' and identifies itself as OmniSeek's single 'read this deep' verb. It is explicitly differentiated from siblings: omniseek_transcribe is called the 'document counterpart (speech)' and omniseek_view is positioned as the image-seeing tool. The auto-routing between URL and document branches is precisely scoped.

  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?

  Provides explicit when-to-use guidance: 'reads ONE specific URL you already have; to FIND open-web pages use WebSearch first, then omniseek_read to normalize the page (a common pairing)'. It also names alternatives for specific cases — omniseek_view for seeing figures, omniseek_transcribe for speech, and omniseek_search with CDP for walled sources. No ambiguity remains about which sibling to pick.

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

• omniseek_searchA
  4.9/5.0
  Behavior5/5

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

  No annotations are provided, so the description bears the full burden of behavioral disclosure. It thoroughly explains deduplication, ranking signals, cache semantics, staleness modes, deadline drops of slow sources, self-warming of cold walled sources, diagnostic payloads on empty/errored drills, and the side-effect-free cache_only pickup. It even covers edge cases like unknown staleness values and the cache key depending on limit, which is exactly the kind of behavioral nuance an agent needs.

  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 long, but it earns most of its length by covering three distinct call shapes, routing rules, and return variants. It is front-loaded with the core purpose and uses bolded headers and bullets to create navigable structure. Some measured-performance detail (e.g., ~16s, ~223 docs, +33% counts) is more than strictly necessary, which keeps it from a perfect conciseness score.

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

  Completeness5/5

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

  Given no output schema and no annotations, the description is remarkably complete. It documents the full return shape for the default ranked result, the raw one-source drill, and raw buckets, including _meta fields like excluded_relevant, deduped, timed_out, and diagnostic. It also covers the fire-then-collect workflow, staleness edge behavior, and relationship to sibling tools.

  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 every parameter must be explained in the prose. The description covers all nine parameters: query, raw, raw's interaction with sources, limit per source and in cache keys, wait_s as patience budget, staleness values and their semantics, semantic toggle behavior, full for whole content, and debug for telemetry. This fully compensates for the absent 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?

  Opens with a clear verb and resource: 'Search the curated sources. The default for best/latest on X.' It then distinguishes three explicit shapes (dispatch, raw one-source drill, raw buckets), so an agent can tell exactly what the tool does and how the core action branches. It also differentiates itself from siblings by naming omniseek_read for drilling into a chosen doc and omniseek_sources for the source map.

  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?

  Provides explicit routing: use raw=True with exactly one source for walled/CDP/slow sources, use broad buckets for many sources, and drop raw for the ranked list. It also says when NOT to infer absence of results ('a broad search that comes back without them is NOT evidence they have nothing'), explains fire-then-collect as the preferred pattern, and contrasts with WebSearch for open-web breadth. This gives clear when-to-use and when-not-to-use guidance.

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

• omniseek_statementA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description carries full behavioral burden and meets it: it explains that OmniSeek stores user judgment and projects it at read time, that the directed triple is the key and re-creating replaces the prior note, that type values are slugged, and that unknown actions and refused identity types return errors. It also discloses unusual behavior like read-side ambience on future search hits and hand-minted id fragmentation.

  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 long but front-loaded with purpose and usage, and the sectioned structure (value gate, type family, memory boundary, actions) makes it navigable. Some passages are philosophically elaborate and could be tightened, but most sentences earn their place given the tool's complexity and the absence of schema and annotations.

  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 tool with seven parameters, no annotations, and no output schema, the description is unusually complete: it includes action-specific return shapes, error cases, the 200-item list cap, replacement semantics, refusal routing to omniseek_ruling, and the read-side projection effect. An agent has enough to call the tool correctly and know what to expect back.

  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 comprehensively. It explains action=create/list/delete with required and optional parameters, note/doc roles, src/dst as any node id, type vocabulary and constraints, about/type filtering for list, and the similar_anchors result. Every parameter in the schema maps to meaningful semantic guidance.

  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 names a specific verb family ('record / list / retract typed relation statements') and a specific resource (directed typed relations between graph node ids). It explicitly frames itself as 'the general sibling of omniseek_ruling' and notes that identity types belong to omniseek_ruling, so an agent can distinguish it from the closest sibling without opening the schema.

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

  Usage Guidelines5/5

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

  The opening 'Use WHEN...' states the exact triggering condition. It gives exclusion guidance — mechanical facts belong to the M/A world, identity judgments belong to omniseek_ruling, prose belongs in notes/memory, and the tool is separate from read-only omniseek_graph. It also says 'Default to prose; the edge is an opt-in index,' making the when-not path explicit.

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

• omniseek_transcribeA
  4.9/5.0
  Behavior5/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 — and it delivers comprehensively. It discloses the tool's safety/private profile (free, keyless, private, cached forever), performance traits (SLOW first call on long items, fast slice startup with region-only download), cost semantics (segments adds VAD + re-transcribe pass; diarize is a SEPARATE heavier pass), accuracy limitations (Chinese-focused diarization, English not its target), the Whisper hallucination rationale, and the error return shape. Contradicts nothing.

  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 long but exceptionally dense — nearly every sentence carries a distinct fact, constraint, or heuristic, and it is front-loaded with the core purpose. It is well-structured with clear section headers (THE LONG-EPISODE PATTERN, return format). Some phrasing could be tightened ('nobody reads', the Whisper benchmark backstory), but the length is largely proportional to the tool's complexity: 7 params, zero schema descriptions, and intricate parameter interactions.

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

  Completeness5/5

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

  Given the context signals — zero annotations, zero schema descriptions, no output schema, 7 parameters with complex interactions — this description is complete. It covers the full return shape (success and error variants), all parameter semantics, performance expectations, known limitations (diarize zh-accuracy), and strategic heuristics (pin speakers=N when known, transcribe only judged slices, never broad sweeps). An agent has everything needed to select and invoke this tool correctly.

  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 is the only documentation — and it fully compensates. It explains all 7 parameters: url (source type), language ('' auto-detect, 'zh'/'en' skip detection), start/duration (seconds or MM:SS/HH:MM:SS, with concrete examples '1:02:30' and '12:00'), segments (per-VAD list, extra cost), diarize (speaker labels, cannot combine with plain segments), and speakers (pinning semantics, ignored unless diarize=True). Nothing is left undocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening sentence states a specific verb+resource+method: 'Transcribe the SPOKEN content of a video / podcast / audio URL via local SenseVoice ASR.' It distinguishes itself from siblings by explicitly naming the YouTube case ('youtube already returns its captions via omniseek_read — no ASR needed'), so the agent can tell it apart from omniseek_read and omniseek_search without opening schemas.

  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?

  Explicit when-to-use guidance is given: the 干货-in-audio case with concrete examples (bilibili 论文精读/方法论/读博/求职 talks, 小宇宙 podcasts, direct audio URLs). Explicit when-not-to-use is also given (YouTube → omniseek_read instead), plus a detailed long-episode pattern that routes through omniseek_search/omniseek_read for shownotes first and instructs never to transcribe a 2-3h episode whole. This is the gold standard for usage routing.

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

• omniseek_viewA
  4.9/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 of disclosing behavior. It does so comprehensively: return block shapes per kind, contact sheet fallback behavior, max_images caps, 30-minute video cap, text-format note, bilibili session sharing, and an honest 'nothing to show' error note. No contradictions exist.

  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 long but every section earns its place given three modes and ten parameters. It is front-loaded with a one-line summary, then routing, then per-kind parameter details, then return format. Headers and bullet-like lines make it easy to scan despite length.

  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 complex multi-mode tool with no output schema and no annotations, the description is remarkably complete. It covers all three input kinds, per-kind parameter behavior, return formats, fallbacks, limits, error handling, and relationships to sibling tools like omniseek_read and omniseek_transcribe. The only minor omission is contact_sheet's explicit role as a boolean flag.

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

  Parameters4/5

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

  Schema description coverage is 0%, so the description compensates by explaining target, kind, sections, names, max_images, render_pages, start/duration, and n in context. However, the contact_sheet boolean parameter is never explicitly defined as a parameter; it is only implied through phrases like 'you get a CONTACT SHEET.' This is a minor but clear gap.

  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 clear one-line statement of what the tool does: 'SEE with your own vision, IN-BAND — document figures, loose image URLs, or video frames.' It then breaks out three distinct modes (document, images, video) and explicitly contrasts with related tools like omniseek_read and omniseek_transcribe, so an agent can distinguish it from siblings.

  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?

  Extremely explicit routing rules are given for kind='auto' with file extensions and host names. It describes when to use the two-step process (omniseek_read first), when to use render_pages instead of sections/names, and when to pair with omniseek_transcribe for video. This is far beyond 'use when you need to view visual content.'

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

• omniseek_curator_viewA
  5/5.0
  Behavior5/5

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

  With no annotations at all, the description carries the full behavioral burden and meets it: it explicitly declares 'Never mutates', details the distinct behavior of each 'what' value, states what happens when no packet is built, and specifies that unknown values return an error dict listing valid values.

  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 long but earns its length: it covers three distinct views, parameter constraints, error behavior, and protocol sequencing in a scannable bullet format. The most important information is front-loaded and no sentence is wasted.

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

  Completeness5/5

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

  Given no output schema and no annotations, the description provides richly detailed context for every view, including the draft packet structure, the audit dossier contents, the absence of a verdict key, and the recommended follow-up call to omniseek_curator_act. This is complete enough for an agent to select and invoke the tool correctly.

  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% and there are no enums, yet the description fully documents all three parameters: 'what' with its three valid values, 'state' with the full allowed list, and 'candidate_id' as the sole selector for the packet view. It also explains how invalid values behave.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'READ curator state: queue | packet | audit' and names the exact protocol context. It also distinguishes itself from the mutating sibling omniseek_curator_act by explicitly saying it never mutates.

  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?

  The opening line gives explicit when-to-use guidance: 'Use WHEN running the source-curation protocol (judge the admission queue or a source audit)'. It also names the next-step alternative, omniseek_curator_act, for rendering verdicts after reading the audit view.

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

• omniseek_paper_enrichA
  5/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 behavioral burden and does so thoroughly. It discloses that the tool is keyless and mechanical, that it does not synthesize or extract figures, and it explains edge-case semantics such as retracted=None vs notices=[] and backend-unreachable behavior. It also clearly states what the return payload contains, including error entries for unrecognized ids.

  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?

  Despite being long, the description is tightly organized with front-loaded usage intent, bulleted per-id behaviors, and a compact return schema. Every sentence adds useful information, from identifier guidance to integrity semantics to explicit non-synthesis rationale. The structure makes the detail scannable rather than overwhelming.

  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 single-parameter tool with no output schema and no annotations, the description is complete: it covers valid inputs, per-field output semantics, error handling, backend failures, and downstream tool routing. An agent has everything needed to invoke it correctly and interpret results correctly.

  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 input schema only says ids is an array of strings with 0% description coverage, so the description must compensate. It does by specifying accepted identifier forms (DOIs and arXiv ids), giving concrete examples, explaining which fields from sibling tools to use, and explicitly warning against using source_id or OpenAlex W-id. This is far more than the schema alone provides.

  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 names a specific verb and resource: enrich a single paper with open-access PDF, integrity status, and citation count. It explicitly contrasts with omniseek_search / field_skeleton, which do not provide these signals cleanly, so an agent can distinguish this tool from its siblings.

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

  Usage Guidelines5/5

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

  It tells the agent exactly when to use the tool ('Use WHEN you need ONE paper's open-access full-text PDF...') and when not to, such as not using omniseek_field_skeleton to read a single node's count. It also advises enriching only a handful of papers rather than a whole map, and names omniseek_read as the follow-up for reading PDFs.

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

• omniseek_resolve_identityA
  5/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 behavioral burden and does so thoroughly. It states the tool NEVER silently picks, hint only re-orders and never filters, likely_same_person never auto-merges but surfaces a merge_token, and degraded indicates upstream failure rather than confirmed absence. These details go well beyond the minimum and directly prevent misinterpretation.

  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 long but appropriately sized for a complex disambiguation tool with four meaningful parameters, no annotations, and no output schema. It front-loads the core purpose and key safety behavior, then logically builds through parameter semantics, disambiguation flags, and failure semantics. Almost every sentence carries operational value.

  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?

  Since there is no output schema, the description documents the full return shape and explains each important flag (ambiguous, likely_same_person, degraded) with actionable consequences. It also connects the workflow to omniseek_coauthors and gives retry guidance for degraded upstream failures, making the definition self-sufficient.

  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 for all parameters. It adds exact meanings for hint (re-order only, never filters, example 'HKUST'), source ('auto', 'openalex', 's2' with fallback behavior), paper (arXiv id/DOI/title, resolves straight from the author list), and the required name (a PERSON's name). This is substantially richer than the bare input 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 leads with a specific verb and resource ('Resolve a PERSON's name to candidate author ids') and immediately distinguishes it from sibling tools: other OmniSeek tools keyword-search PAPERS, while this resolves an AUTHOR. It also states the workflow position as the shared front door for relationship layers, so an agent can clearly tell why this tool exists.

  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?

  The description explicitly contrasts this tool with paper-searching tools and instructs agents to use the returned id with omniseek_coauthors. It gives concrete selection guidance for the 'paper' parameter (common-name junior authors), explains the source options and their behaviors, and tells the agent how to handle ambiguous results.

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

• omniseek_rulingA
  5/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.