Skip to main content
Glama

Search Packs

search_packs
Read-onlyIdempotent

Search Pipeworx packs by keyword or a plain question across pack names, descriptions and tool descriptions (e.g. "weather", "translate", "Colombia procurement contracts awarded to a supplier"). Returns matching packs ranked best-first with each one's matched terms, cost, auth and reliability. Use to find which pack covers a capability before connecting to it; question filler and proper names are ignored, so the subject words are what match.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum packs to return, best match first (1-200, default 25).
queryYesKeywords or a question naming the data you want. The subject words match (country, system, dataset, topic); names of specific companies or people do not, since no pack describes them.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNoPresent only when no pack matched: how to rephrase, or use ask_pipeworx
packsYesMatching packs
queryYesSearch query used
resultsYesNumber of matching packs
showingNoPacks returned when the match list was capped by limit
truncatedNoTrue when more packs matched than were returned

TDQS

A4.1/5.0
Behavior4/5

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

The description adds meaningful behavior beyond the read-only and idempotent annotations: it discloses best-first ranking, returned fields (matched terms, cost, auth, reliability), and the semantic matching behavior that ignores filler words and proper names. This enriches the agent's understanding of call outcomes without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each earning its place: a specific search claim with examples, a clear return-value summary, and a crisp usage directive. The key verb and resource appear immediately, and there is no padding or repetition of schema details.

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?

The description covers the tool's scope, matching semantics, output highlights, and intended use case. With annotations already carrying the read-only, idempotent, and non-destructive signals, and an output schema present, nothing needed to safely invoke this tool is missing.

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 100%, and the schema already explains the query and limit parameters well. The description's comments about keyword/question search and ignored filler words largely restate the schema's query parameter text, so it adds little new meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a search across Pipeworx packs by keyword or question, with specific fields (names, descriptions, tool descriptions) and concrete examples. It is clear about the resource and verb, though it doesn't explicitly contrast with sibling search tools like discover_tools or search_mcp_directory, so it falls short of full sibling differentiation.

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?

The description gives an explicit use case: 'Use to find which pack covers a capability before connecting to it'. It also clarifies the matching rule (subject words match; filler and proper names ignored). However, it does not state when not to use the tool or name alternative tools, so exclusions are absent.

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/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, especially the central data access tools like ask_pipeworx, deep_research, entity_profile, and compare_entities. However, the multiple polymarket tools (arbitrage, edges, edge_tracker, fill_risk, kalshi_spread) and the similar ask_pipeworx variants could cause confusion, especially for an agent quickly scanning options.

Naming Consistency4/5

Tool names are mostly snake_case and follow a verb_noun pattern (e.g., compare_entities, search_packs, resolve_entity). Some deviations exist, such as pipeworx_feedback, polymarket_arbitrage (starting with a noun), and single-word names like forget and remember, but overall the style is readable and consistent.

Tool Count2/5

With 36 tools, the server feels overly heavy. While the broad domain (structured data across many sources) justifies a large number, the count exceeds the recommended 15–25 range, making it unwieldy for agents to navigate efficiently without extensive discovery.

Completeness4/5

The tool set covers a wide range of domains: company financials, drugs, economics, prediction markets, weather, and even MCP discovery. There are few obvious gaps given the stated purpose, though some areas like social media or international data could be added. Overall, the surface is well-rounded.