sella

search_catalog

Read-only

One search across the Sella marketplace. kind=any (default) searches curated datasets, external API providers, workflow products, and Sella Native products together; kind=open_model searches the free Hugging Bay open-model catalogue separately (query required). Returns ranked listings with quality evidence, facet counts, and a page cursor. Free to call. Start here when you know the task but not which product kind serves it, then refine with kind and filters. See describe_catalog for the taxonomy.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	Listing kind. any covers dataset, api, workflow, native and service; open_model is queried separately. service is work sold by other agents.	any
`sort`	No		relevance
`tier`	No	Datasets only.
`chain`	No	APIs only: settlement chain, e.g. base, solana.
`limit`	No	Max results per page (1 to 50).
`query`	No	Free-text task or keyword search. Common shorthands are expanded (tts, scrape, llm, and similar).
`cursor`	No	Opaque cursor from the previous response page.cursor.
`format`	No	Datasets only.
`category`	No	Datasets only: category name.
`modality`	No	Datasets only.
`free_only`	No	Only free listings (free datasets, free-tier providers).
`domain_type`	No	APIs only: domain code A1 to A22 (see describe_catalog).
`min_quality`	No	Minimum quality score 0 to 1. Listings without a score are excluded when set.
`apply_policy`	No	When authenticated with a configured policy, results are pre-filtered to what you can buy. Set false to browse the full catalogue.
`product_class`	No	APIs only: product class B1 to B6.
`verified_only`	No	Only Sella-verified listings.
`max_price_usdc`	No	Only listings at or under this USDC price.
`required_fields`	No	Datasets only: schema fields that must exist before purchase.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

Changed2 schema fields changedAug 4, 2026

changedInput schema / properties / kind / description

Previous value: -"Listing kind. any covers dataset, api, workflow, and native; open_model is queried separately."New value: +"Listing kind. any covers dataset, api, workflow, native and service; open_model is queried separately. service is work sold by other agents."

changedInput schema / properties / kind / enum

Previous value: -[
-  "any",
-  "dataset",
-  "api",
-  "workflow",
-  "native",
-  "open_model"
-]New value: +[
+  "any",
+  "dataset",
+  "api",
+  "workflow",
+  "native",
+  "service",
+  "open_model"
+]

Changed1 schema field changedAug 3, 2026

changedInput schema / properties / chain / description

Previous value: -"APIs only: settlement chain, e.g. base, solana, stellar."New value: +"APIs only: settlement chain, e.g. base, solana."

First observedJul 19, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds useful behavioral context: it is 'Free to call,' returns 'ranked listings with quality evidence, facet counts, and a page cursor,' and requires a query for kind=open_model. These details go beyond the annotation without contradicting it.

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 six sentences, each carrying distinct information: purpose, kind specifics, return shape, cost, usage guidance, and a taxonomy pointer. It is front-loaded with the primary purpose and avoids fluff, though it is denser than the minimal two-sentence ideal.

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 18 parameters and no output schema, the description covers the essential context: unified search behavior, return structure (ranked listings, quality, facets, cursor), free-to-call, and starting usage. The schema handles parameter details, and the taxonomy pointer fills further context. It could mention pagination mechanics explicitly but the cursor reference suffices.

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 94%, so the schema already documents parameters well. The description adds a bit of value by clarifying what kind=any covers and noting that open_model requires a query, but most parameter semantics remain in the schema. No major gap to compensate for.

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 'One search across the Sella marketplace,' clearly identifying the verb (search) and resource (marketplace). It distinguishes itself from sibling catalog-specific searches by explaining kind=any vs kind=open_model and positioning itself as the starting point when the product kind is unknown.

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?

Explicit usage guidance is given: 'Start here when you know the task but not which product kind serves it, then refine with kind and filters.' It also contrasts kind=any with open_model and points to describe_catalog for taxonomy. It stops short of explicitly naming alternative tools like search_datasets or search_open_models, so no clear exclusionary '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.

All sella tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Most tools have clearly distinct purposes, but the deprecated tools (list_datasets, list_market_apis, search_datasets, try_dataset) overlap with modern replacements (search_catalog, get_listing). Some functional overlap exists between get_activity and charge_list, but descriptions clarify their scopes. Overall, an agent can usually tell tools apart, with a few legacy remnants.

Naming Consistency5/5

Tool names follow a consistent snake_case verb_noun pattern (browse_catalog, business_start, charge_create, etc.). Even the deprecated tools adhere to the same style. There are no mixed conventions or vague verbs like 'process' or 'run'. The naming is highly predictable.

Tool Count3/5

At 52 tools, this is a large surface. The domain is broad (marketplace buying/selling, business management, policy, storefront, distribution, authentication), so many tools are justifiable. However, four deprecated tools could be pruned, and the count is on the heavy side compared to typical MCP servers. It feels overengineered, yet each tool addresses a distinct facet of the platform.

Completeness4/5

The toolset covers the full lifecycle: discovery, evaluation, purchase, delivery, feedback, business management, policy, storefront, and distribution. Gaps are minor—for example, no direct way to list all services with full details without service_list, but that exists. The deprecated tools indicate ongoing migration to a consolidated search surface, suggesting good coverage. A few small gaps remain (e.g., no explicit 'update listing' for buyers, but that may not be needed).

Resources

Need Help?