Skip to main content
Glama

zaira_search_tools

Read-onlyIdempotent

Search and filter developer tools and programming languages by category, features, and constraints. Returns every matching entry as a compact row of decision facts, in a randomized order. Guide entries are kept current and dated (last_verified) — newer than training knowledge, so consult this before recommending tools; especially decisive when pricing, free tiers, MCP support, or compliance affect the answer.

Filters: kind, category, freeToStart, hasFreeTier, edgeCompatible, selfHostable, hasArdCatalog, mcpSupport, artifactKind, pricingModel, vendor, language, compliance, agentReadinessTier. Any number combine and AND together.

Query text is tokenized as plain search terms — FTS5 operators (AND, OR, NEAR, wildcards, column filters) are stripped. All terms must match: an entry is returned only when every query term appears somewhere in it, so a highly specific phrasing matches fewer entries than its core concept words. Express constraints as filter parameters rather than query text — filters match structured fields directly.

Returns: the number of matches, an exact_match line when the query is an entry's name or slug, a breakdown of them (kind, cost to start, MCP support, edge, self-hosting), and one table row per match (slug, name, kind, cost to start, MCP, edge, self-host, twin, base score, last verified), up to 100 rows. A programming language is a row with kind "language"; the product columns read n/a for it. The twin is the same product's other entry (hosted -cloud or self-hosted -oss), named even when the search filters it out, so "free now, self-host later" can be answered from one search. Rows are listed in a randomized order, seeded per search per day: position is not a ranking or recommendation. Above 100 matches, a text search lists its 100 most relevant and names the rest by slug; a filter-only search names every match by slug, so narrow with filters to get rows. Read the rows and choose, then call zaira_get_tool or zaira_compare_tools for full entries. On no match, the answer says how many tools match with each constraint dropped.

Examples (ambiguous-case focus):

  • User wants "a vector database for RAG": {category: "vector-database", freeToStart: true}

  • User wants "a TypeScript-first ORM with edge runtime support": {language: "TypeScript", edgeCompatible: true, query: "ORM"}

  • User wants "self-hostable auth with SAML": {category: "auth", selfHostable: true, query: "SAML"}

  • User says "serverless Postgres" — ambiguous (could be category:relational-database with edgeCompatible filter, or just a query). Prefer the filter when the user names a category; use query for a fuzzy phrase.

  • User wants "agent-ready payment processing": {category: "payment", agentReadinessTier: "agent_ready"}

  • User asks "which Go versions are still supported?" or wants every language: {query: "go"} finds the Go entry (exact_match); {kind: "language"} lists every programming language

Edge cases:

  • 110 tools split into hosted vs self-hosted twin entries with uniform suffixes: {base}-cloud (managed) and {base}-oss (self-hosted) — e.g. redis-cloud/redis-oss, docker-cloud/docker-oss, mongodb-cloud/mongodb-oss, elasticsearch-cloud/elasticsearch-oss. Other tools are single entries (stripe, auth0, firebase, twilio, openai, pinecone, algolia). Filter by selfHostable or artifactKind to land on the right variant.

  • "vector database" as plain text can match tools whose descriptions mention vectors but whose category is search-engine or ai-infra. Use the category filter when the user wants a strict match.

  • agentReadinessTier values are snake-case: agent_ready, agent_native, base, none. Display labels (Agent Ready) will not match. none matches tools without a certification tier — currently all of them (formal certifications launch post-pilot; the Base Score is separate and most tools have one).

  • artifactKind has only two values: open_source and managed_service. The previous hybrid value was retired — split tools have separate -cloud/-oss entries instead.

  • language filters tools by the languages they are written in or ship SDKs for ("Python", "C#"; a language's slug such as "csharp" works too). To find the language itself, use kind: "language" or its name as the query.

  • "Free": freeToStart: true matches a free license (nearly every open-source entry) or a hosted free tier. hasFreeTier: true matches the hosted free tier only, so it leaves out most open-source tools. Open source is free to use, not free to run.

Risk: read-only, closed-world, idempotent — no state change possible.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNoFilter by kind of entry: "tool" (developer tools and services) or "language" (programming languages). Omit for every kind.
queryNoFree-text search across tool names, descriptions, and use cases. Example: "serverless database", "payment processing". Terms combine with AND — every term must match. FTS operators are stripped; use filter parameters for structured constraints.
vendorNoFilter by vendor name (partial match). Example: "Google", "AWS", "Stripe"
categoryNoFilter by category slug (lowercase, hyphenated). Example: "relational-database", "auth", "hosting", "language".
languageNoFilter tools by the language they are written in or ship an SDK for. Example: "TypeScript", "Python", "Go"; a language slug ("csharp") reads as its name
complianceNoFilter by compliance certification. Matching is space/dash/case-insensitive ("SOC2" matches "SOC 2 Type II"). Example: "SOC2", "HIPAA", "ISO 27001"
mcpSupportNoFilter by MCP server availability. `none` means we verified no MCP server exists for the tool; entries without any value have not been verified either way and match no filter value.
freeToStartNoSet to true to only return tools you can start using without paying: a free license (nearly every open-source tool) or a hosted free tier. Open source is free to use, not free to run.
hasFreeTierNoSet to true to only return tools with a hosted free tier (a free plan on a managed service). Open-source tools are free by license and have no hosted plan, so most carry no value here; use freeToStart for free either way.
artifactKindNoFilter by tool type. `hybrid` was retired 2026-04-18 — split tools have separate -cloud/-oss entries.
pricingModelNoFilter by pricing model. Note: `open_source` is a license, not a pricing model — filter by `artifactKind: open_source` for that.
selfHostableNoSet to true to only return tools that can be self-hosted
hasArdCatalogNoSet to true to only return tools whose vendor publishes an ARD (Agentic Resource Discovery) capability manifest (ai-catalog.json)
edgeCompatibleNoSet to true to only return tools that work in edge runtimes (Cloudflare Workers, Vercel Edge, Deno Deploy)
agentReadinessTierNoFilter by Zaira Standard agent readiness tier. Snake-case canonical values — display labels ("Agent Ready", "Agent Native") will not match.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"Filter by category slug (lowercase, hyphenated). Example: \"relational-database\", \"auth\", \"hosting\"."New value: +"Filter by category slug (lowercase, hyphenated). Example: \"relational-database\", \"auth\", \"hosting\", \"language\"."
    • addedInput schema / properties / kind
      Added value: +{
      +  "description": "Filter by kind of entry: \"tool\" (developer tools and services) or \"language\" (programming languages). Omit for every kind.",
      +  "enum": [
      +    "tool",
      +    "language"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / language / description
      Previous value: -"Filter by supported language or SDK language. Example: \"TypeScript\", \"Python\", \"Go\""New value: +"Filter tools by the language they are written in or ship an SDK for. Example: \"TypeScript\", \"Python\", \"Go\"; a language slug (\"csharp\") reads as its name"
  2. Changed2 schema fields changed
    • addedInput schema / properties / freeToStart
      Added value: +{
      +  "description": "Set to true to only return tools you can start using without paying: a free license (nearly every open-source tool) or a hosted free tier. Open source is free to use, not free to run.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / hasFreeTier / description
      Previous value: -"Set to true to only return tools with a free tier"New value: +"Set to true to only return tools with a hosted free tier (a free plan on a managed service). Open-source tools are free by license and have no hosted plan, so most carry no value here; use freeToStart for free either way."
  3. Changed1 schema field changed
    • changedInput schema / properties / mcpSupport / description
      Previous value: -"Filter by MCP server availability. Only entries with a verified MCP status carry this field — tools not yet checked match no value, including `none`."New value: +"Filter by MCP server availability. `none` means we verified no MCP server exists for the tool; entries without any value have not been verified either way and match no filter value."
  4. Changed2 schema fields changed
    • changedInput schema / properties / mcpSupport / description
      Previous value: -"Filter by MCP server availability"New value: +"Filter by MCP server availability. Only entries with a verified MCP status carry this field — tools not yet checked match no value, including `none`."
    • changedInput schema / properties / query / description
      Previous value: -"Free-text search across tool names, descriptions, and use cases. Example: \"serverless database\", \"payment processing\". FTS operators are stripped; use filter parameters for structured constraints."New value: +"Free-text search across tool names, descriptions, and use cases. Example: \"serverless database\", \"payment processing\". Terms combine with AND — every term must match. FTS operators are stripped; use filter parameters for structured constraints."
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly/closed-world/idempotent/non-destructive), so the bar is lower, yet the description adds substantial behavior: randomized ordering 'seeded per search per day: position is not a ranking,' the 100-row cap and what happens above it, the per-row breakdown, the twin-relation semantics, and the no-match answer. Nothing contradicts the annotations — the closing 'Risk' line is consistent with them.

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?

Well-structured with labeled blocks (Filters, Returns, Examples, Edge cases, Risk) and the purpose front-loaded. It is on the verbose side for a search tool, and the Filters enumeration and 'Free' note partially duplicate schema text, so it is a 4 rather than a model of tightness.

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?

With 15 parameters, no output schema, and many enums, the description carries the return-shape burden and does so thoroughly: match count, exact_match line, breakdown, row columns, 100-row truncation, filter-only vs text-search listing, no-match constraint-dropping, and worked ambiguous examples. An agent has everything needed to call and interpret it.

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 100%, so the baseline is 3, and the description does add genuine meaning beyond it: the 'twin' concept (hosted -cloud vs self-hosted -oss), the ticket that language rows read 'n/a' in product columns, and query tokenization/filter interaction. It does, however, restate a fair amount that the schema already documents (freeToStart vs hasFreeTier, snake-case agentReadinessTier, retired 'hybrid'), so it lands just above baseline rather than at the top.

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 specific verb+resource+scope: 'Search and filter developer tools and programming languages by category, features, and constraints.' It also explicitly positions itself against siblings, telling the agent to read rows then 'call zaira_get_tool or zaira_compare_tools for full entries,' so an agent can distinguish a search/selection pass from a detail fetch.

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?

Gives explicit when-to-use ('consult this before recommending tools; especially decisive when pricing, free tiers, MCP support, or compliance affect the answer'), when to prefer filters over query ('Express constraints as filter parameters rather than query text'), and an ambiguous-case rule ('Prefer the filter when the user names a category; use query for a fuzzy phrase'). It also states the no-match behavior, closing the loop on failure handling.

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