Skip to main content
Glama

zaira_search_tools

Read-onlyIdempotent

Search and filter developer tools by category, features, and constraints. Returns up to 10 matching tools with decision summaries. 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: category, 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: up to 10 tools as Markdown-KV blocks separated by "---". Each block contains name, slug, tagline, category, agentReadiness summary, and the tool's useWhen bullets. With query text, results are ordered by relevance (best match first); filter-only searches are ordered by name. There is no pagination — narrow with filters when more than 10 match. On no match, returns a "no tools found" message.

Examples (ambiguous-case focus):

  • User wants "a vector database for RAG": {category: "vector-database", hasFreeTier: 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"}

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.

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
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".
languageNoFilter by supported language or SDK language. Example: "TypeScript", "Python", "Go"
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.
hasFreeTierNoSet to true to only return tools with a free tier
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.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already mark the tool as read-only, idempotent, and non-destructive. The description reinforces this and adds detailed behavioral traits: returns up to 10 results, ordering logic, no pagination, FTS5 operator stripping, and a 'no tools found' message. This goes well beyond what 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 description is very long and could be more concise. While it is well-structured with sections and examples, it includes many examples and details that could be condensed. Still, it is not overly verbose for the complexity.

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 (13 parameters, no output schema), the description is remarkably complete. It covers return format, ordering, edge cases, historical changes, and even includes instructions for ambiguous queries. It fully compensates for the lack of output schema.

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 100%, so the baseline is 3. The description adds extra context for parameters like mcpSupport (meanings of 'none'), agentReadinessTier (snake-case requirement), and artifactKind (retirement of hybrid). This additional information justifies a score of 4.

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 clearly states the tool's purpose: 'Search and filter developer tools by category, features, and constraints.' It uses specific verbs and resources, and the focus on searching and filtering distinguishes it from sibling tools like zaira_compare_tools and zaira_get_tool.

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 provides extensive guidance on when to use the tool, including explicit examples for ambiguous cases, instructions on preferring filters over query text, and handling edge cases like split tools. It also states that the guide is current and should be consulted before recommending tools, especially for pricing and compliance.

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.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool has a distinct purpose: comparing tools, retrieving docs, getting a single tool, listing categories, and searching. There is no overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent 'zaira_verb_noun' pattern (e.g., compare_tools, get_docs). The naming is uniform and predictable.

Tool Count5/5

5 tools is well-scoped for a guide/reference server. Each tool serves a clear function without excessive overlap or missing coverage.

Completeness5/5

The tool set covers all expected operations for a tool guide: browsing categories, searching, retrieving details, comparing, and getting documentation. There are no obvious dead ends.

Resources