Skip to main content
Glama

omniseek_sources

List available sources and routing options, then narrow by domain, region, or query to identify the right source. Includes descriptions, credential requirements, and live health status.

Instructions

List all sources — call this to ROUTE before searching.

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

BOUNDED ORIENT: a bare (no-arg) call does NOT dump every source's facets. It returns the routing VOCABULARY (available_domains / available_regions with counts) + the capabilities verb index + source_names (the bare inventory) + counts, so the orient payload stays small no matter how far the roster grows (brain_orient's lesson). The per-source FACETS (kind / domains / regions / modes, needs_credentials, explicit_only, stability, health, ...) plus the prose description arrive when you NARROW or ask verbose — reach for them on demand: • domain="jobs" / "papers" / … → only sources whose domains facet contains it, WITH their full descriptions. domain= is the most RELIABLE router; the no-arg call returns available_domains (the full closed vocabulary + counts) so you can pick a valid token, and a near-miss (e.g. "careers") returns did_you_mean instead of a silent empty. • query="singapore visa" → TOKEN-OVERLAP over name + description + domains + regions + cross-lingual keywords, ranked best-first (multi-word- and English↔中文-safe), WITH descriptions. • region="sg" / "ca" / "cn" → only sources whose regions facet contains it (the no-arg call returns available_regions; a near-miss returns did_you_mean). Region narrowing matters when the deployment's source pack is geographic. • verbose=True → the full unfiltered list, WITH every description. check_health=True does a fresh LIVE probe of every source (slow) AND returns a system block: the recall-index health (indexed_docs / embedder_available / vec_embed_failures / last_write_age_s) plus the observation-journal durability head, materialization cursor, pending count, and failures. and the openalex_usage attribution (which component spent the shared daily budget + remaining).

The no-arg (orient) call also returns capabilities: the non-search VERB index (field_skeleton, coauthors, transcribe, …) so you discover the whole toolkit here, not only after loading a tool.

kind per source: lookup (query = search the venue) | stream (query = FILTER over a recent feed; nowcoder additionally adds a site search) | proxy (search-index venue: engine snippet, shared paced backend) | portal (single-URL fetch). explicit_only_reason says WHY a source stays out of the broad sweep; a reason containing "shared paced backend" means the source draws on the one web-search backend of section (10) in the server instructions.

Returns: {"count": N, "backend_count": M, "backend_breakdown": {...}, and EITHER

  • a BARE ORIENT: "source_names": [...] + "note" + available_domains + available_regions + capabilities; OR

  • a NARROWED (domain/region/query) or verbose call: "sources": [{name, backend, (description when narrowed/verbose), needs_credentials, explicit_only, explicit_only_reason? (present only when excluded; the full catalog of why-strings search's _meta.excluded_count no longer re-ships), param_hint? (the structured query a VERTICAL source wants — a stock code / ticker / author name — present only when the source declares one, so a named call is filled right the first try), stability, access_tier, health, health_as_of, kind?, domains?, regions?, modes?, (healthy, status if check_health)}]. (did_you_mean on a domain/region near-miss; system:{recall, openalex_usage, jobs:[{name, schedule, enabled, last_run, next_run, budget_s, desc}, ...]} when check_health — the background-job fleet.)}

count is the RAW source count; it over-states coverage when many logical sources sit on ONE upstream. backend_count is the distinct UPSTREAMS (the honest figure) and backend_breakdown names every upstream backing >1 source, e.g. {"openalex": 42} (40+ affiliation slices of one corpus + one API budget + one breaker = one backend, not 40 of coverage).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryNo
domainNo
regionNo
verboseNo
check_healthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.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 of behavioral disclosure, and it excels. It explains that a bare call returns a bounded orient (not all facets), that narrowed calls include descriptions, that check_health performs a slow live probe, and it details the distinction between count and backend_count. It also explains the meaning of kind and explicit_only_reason. All behaviors are explicitly documented.

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 well-structured with bullet points and clear sections (BOUNDED ORIENT, per-source facets, Returns, etc.). It is front-loaded with the primary purpose. However, it is verbose, containing extensive detail that could be trimmed for conciseness. Still, each section serves a purpose, and the structure helps an agent parse it. It earns a 4 rather than 5 due to 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?

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is remarkably complete. It covers all routing scenarios, return structures, and caveats (e.g., count overstates coverage). Nothing an agent needs to correctly call and interpret results is missing. It even explains the 'kind' per source and the param_hint mechanism.

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 has zero descriptions for parameters, so the description must compensate. It does so thoroughly: query= is described as token-overlap over multiple fields, domain= as a facet match with did_you_mean on near-miss, region= similarly, verbose=True as full unfiltered list, and check_health=True as a live probe plus system block. Each parameter's effect and return implications are explained in 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 opens with 'List all sources — call this to ROUTE before searching,' clearly stating the tool's purpose as a source router. It distinguishes itself from sibling search tools by positioning it as the pre-search routing step. The phrase 'call this to ROUTE' and the mention of returning available_domains/regions for token selection make the tool's role unambiguous.

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 instructs when to use the tool ('call this to ROUTE before searching') and details each parameter's effect: domain= for facet-based routing, query= for token-overlap search, region= for geographic narrowing, verbose=True for full list, and check_health=True for live probing. It also notes when to use the no-arg call versus narrowed calls, providing clear usage guidance and routing logic.

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