Skip to main content
Glama

searchCatalog

Search the catalog for entities (services, domains, teams, resources), ranked by relevance. This is the primary way to find entities. Put search text in query (plain words work; AND/OR/NOT supported). Scope with types (e.g. service, domain, team); owners to get everything a team owns, including its sub-teams; domains to get everything within a domain, including its sub-domains; or catalog (a catalog slug). Returns a lean result per entity (cid, tag, type, name, description, owners, status); use getEntityDetails for the full record of a single entity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo0-indexed page number.
queryNoRelevance search text. Plain words work; AND/OR/NOT supported.
typesNoRestrict to entity types, e.g. service, domain, team, resource.
ownersNoOwner team tags. Returns entities owned by these teams, including their sub-teams.
catalogNoCatalog slug. Scopes the search to that catalog's entities.
contextYes Explain why you're invoking this tool now and how its output will be used. Then state how this call supports your *overall objective* and fits into your broader plan across all tool calls (e.g., why this tool vs. others, and what step it unblocks). Never share any personal details or sensitive information.
domainsNoDomain tags. Returns entities in these domains, including their sub-domains.
pageSizeNoResults per page, 1-100.
includeArchivedNo

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses relevance ranking, supported query operators (AND/OR/NOT), scoping semantics, and the lean result structure. However, it omits behavior around includeArchived (archived excluded by default), and doesn't clarify whether query is optional, so some behavioral details remain implicit.

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?

Four sentences, all purposeful: states purpose, query syntax, scoping options, and return format with alternative. No fluff, though slightly longer than minimal.

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 9-param search tool with no output schema, the description explains the return fields and directs to getEntityDetails for full records, which is complete for a list/search result. It lacks explicit mention of pagination behavior and archived handling, but schema covers page/pageSize defaults. Overall adequate for invoking the tool correctly.

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 89%, so baseline is 3. The description repeats schema details for query, types, owners, domains, and catalog without adding new syntax or semantic details beyond the schema. It adds practical context (e.g., 'put search text in query') but doesn't compensate for the undocumented includeArchived param.

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?

Description states 'Search the catalog for entities (services, domains, teams, resources), ranked by relevance.' This is a specific verb+resource+scope, and explicitly distinguishes itself as 'the primary way to find entities,' also pointing to getEntityDetails for full records, differentiating it from sibling list/detail tools.

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?

Description says 'This is the primary way to find entities' and explicitly directs to 'use getEntityDetails for the full record of a single entity.' It also provides alternative scoping methods. This gives clear when/why guidance relative to siblings.

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

C2.7/5.0
Disambiguation2/5

Several tools have overlapping or unclear boundaries, notably getEntityDescriptor and listEntityDescriptors share identical descriptions, and getEntityDetails may be confused with them. This ambiguity could easily lead an agent to select the wrong tool for a catalog lookup.

Naming Consistency3/5

Most tools follow a camelCase getXxx/listXxx pattern, but there are clear exceptions like query_docs and get_more_tools that use snake_case, and the verb set includes get, list, query, and search. The mixed conventions are still readable but not fully consistent.

Tool Count2/5

With 31 tools, the surface feels oversized, especially considering the redundant descriptor tools and the meta-tool get_more_tools. The scope is broad but could benefit from splitting into separate servers for catalog, metrics, and other functions.

Completeness2/5

The tool set is almost entirely read-only (get/list/search/query) with no create, update, or delete operations, despite descriptions mentioning 'manage your service catalog'. This leaves significant lifecycle gaps and prevents full catalog management workflows.

Resources