Skip to main content
Glama

Search Within a Source

search_within
Read-onlyIdempotent

Semantic search INSIDE a fetched record. Pass the text you already pulled (e.g. a SEC 10-K body, an article, a long tool result) plus a natural-language query; get back the top-N passages with character offsets and similarity scores. Use when the record is too big to cram into the prompt — search_within saves context, returns only the passages that matter, and every passage carries an offset so the agent can verify a verbatim quote. Pairs with ask_pipeworx_grounded: fetch with the gateway, ground over the relevant passages instead of the whole document. BGE-base-en embeddings + cosine over 500-char overlapping windows; cap is 200K chars (longer inputs are truncated and flagged).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textYesThe document text to search inside (max ~200K chars).
limitNoMax passages to return (1-20, default 5).
queryYesNatural-language query — what passages do you want? E.g. "supply-chain risk", "fiscal year 2024 revenue", "drug interactions with warfarin".

TDQS

A4.8/5.0
Behavior5/5

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

Beyond annotations (readOnly, idempotent, etc.), the description discloses technical details: BGE-base-en embeddings, cosine similarity over 500-char windows, 200K char cap with truncation flagging, and passage offsets for verification. This adds substantial value.

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 concise and front-loaded, using 3-4 sentences to cover purpose, usage, and technical details. Every sentence adds value, though a slight reduction could improve conciseness.

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 no output schema, the description adequately explains return format: top-N passages with offsets and similarity scores. It also covers truncation behavior and pairing guidance, making it complete for a tool with 3 parameters.

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 covers all 3 parameters (100% coverage). Description adds helpful context: max 200K chars for 'text', natural-language examples for 'query', and default/range for 'limit'. This enhances understanding beyond schema.

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 performs semantic search inside a fetched record, with a specific verb 'search' and resource 'inside a source'. It distinguishes itself from siblings by mentioning alternative use cases and pairing with ask_pipeworx_grounded.

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?

Explicitly states when to use: 'Use when the record is too big to cram into the prompt' and provides alternatives by pairing with ask_pipeworx_grounded. This gives clear context for tool selection.

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

A3.7/5.0
Disambiguation3/5

Most tools are clearly distinct, but ask_pipeworx and ask_pipeworx_beta are currently identical, ask_pipeworx_grounded and deep_research overlap with the base router, and the polymarket_* family contains several scanning/arbitrage tools with fuzzy boundaries. The long descriptions help, but an agent could easily call the wrong variant.

Naming Consistency3/5

There are coherent clusters (pipeworx_*, polymarket_*, ask_pipeworx_*, bare Adzuna verbs), but the overall server mixes snake_case, bare nouns, compound names, and -_prefixed names without a unifying convention. Some tools like compare_entities, entity_profile, and scan_dependency follow a descriptive style that does not match the verb_ noun pattern used elsewhere.

Tool Count2/5

37 tools is well above the 25-tool threshold, and the server named 'Adzuna' includes far more than job-search functionality: prediction markets, memory, subscriptions, npm dependency checks, AI visibility probes, and llms.txt generation. The count feels like a bundled mega-platform rather than a focused job-data server.

Completeness3/5

For a job-search-focused server, the Adzuna tools cover search, categories, history, regional stats, salary histograms, and top companies, but there is no direct job-detail or application workflow. For the broader Pipeworx research surface, coverage is very thorough, so the main completeness problem is the lack of a clear unified domain rather than a specific missing operation.