Skip to main content
Glama

Search the catalog by job

search_catalog
Read-onlyIdempotent

looot: free full-detail catalog listing: 50 full rows by default. For a first look use search (10 short rows), then inspect; use this tool only for many full rows. A ranked full-text search of the data API catalog, with job expansion: a query matching a job's title or alias ("verify an email") returns every endpoint of that job across providers. Each item carries category, job (id, title), matchedBy (text|capability|tokens), mock (a demo provider, ranked last), verified, keyless, runnableNow, stats (30-day calls/successRate/p50Ms/sampleSize, empty answers count as success, null without evidence) and access: "runs_now" (keyless or a platform key exists), "needs_your_account" (connect your own account first) or "coming_soon" (cannot run yet: no platform key). capability is the job id, sourceCapability the raw registered slug, works {rate, runs, p50Ms, thin} (thin rows fill missing runs at the job average, which cheapest sorts on), credential whose key a run uses. expandedCapabilities lists matched job ids; pass one as filters.capability. When no endpoint does the named job ("weather"), items is empty, unsuppliedJobs names it and warnings has code "no_supply_for_job". If filters.maxPriceMicros removes every match, priceHint (code "price_above_max") names the cheapest. detail: "title" rows: endpointId, provider, name, capability, category, estimatedPrice, priceBasis, access, costPerSuccessUsd and async, plus works, sourceCapability and credential. limit caps a page at 200; page with offset and nextOffset. query is optional with a filter (filters: { category } browses). jobInputs fit job:<id>, not a pinned tool id. prefer (balanced default, cheapest, reliable, fastest) orders providers inside a job; facts on each full row says why. Field details: https://api.looot.ai/llms-full.txt.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
detailNo
offsetNo
preferNo
filtersNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnly/idempotent/non-destructive), and the description layers on substantial extra behavior: default 50 full rows, mock providers ranked last, `stats` semantics (empty answers count as success, null without evidence), the meaning of each `access` state, `warnings`/`priceHint` codes, and pagination via `offset`/`nextOffset`. This is far beyond what the annotations provide.

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 routing guidance is front-loaded, which is good, but the body is a dense wall of inline field documentation that partly duplicates the linked `llms-full.txt` reference. It earns much of its length given 0% schema coverage, but the structure is hard to scan.

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 complex, filter-heavy search tool with no output schema and zero schema descriptions, the definition covers return shape, empty-result behavior (`no_supply_for_job`), and price-filter edge cases (`price_above_max`). Only a few filter fields and the exact `stats`/`works` fields for non-title detail are left thin.

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 carries the full burden, and it mostly succeeds: it defines `limit` (200 cap), `offset` pagination, `detail: "title"` output fields, `prefer` values and its balanced default, and several `filters` fields including `capability`, `category`, and `maxPriceMicros`. A handful of filter fields (hidden, platform, provider, verified, includeUnavailable) are still left to the reader.

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 ('A ranked full-text search of the data API catalog, with job expansion') and immediately differentiates itself from the sibling `search` by row count and detail level. An agent can distinguish it from `search`, `inspect`, and `discover` without opening a 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?

Explicit routing guidance is given: 'For a first look use `search` (10 short rows), then inspect; use this tool only for many full rows.' It also explains that `query` is optional when a filter is supplied, and tells the agent to pass an id from `expandedCapabilities` as `filters.capability`.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources