AnySearch
Server Details
Unified real-time search engine skill for AI agents.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 4 of 4 tools scored.
Each tool has a distinct, well-defined purpose: get_sub_domains discovers vertical domains, search runs a single query, batch_search runs multiple queries in parallel, and extract fetches page content. There is no overlap in functionality.
The naming pattern is inconsistent: get_sub_domains and batch_search use verb_noun with underscores, while search and extract are single verbs. The mix of styles and the different structure of batch_search compared to search reduce consistency.
With only 4 tools for a search server, the count is too low. Many common search operations (e.g., filtering, pagination, site-specific search) are missing and must be handled via complex parameter logic or orchestration, indicating the surface is under-scoped.
The tools cover core search workflow (domain discovery, search, batch search, extraction) but lack obvious operations like result filtering, pagination, or metadata retrieval. The heavy reliance on parameters and orchestration within descriptions suggests gaps.
Available Tools
4 toolsbatch_searchARead-onlyDestructiveInspect
This is Anysearch's parallel search tool. Parallel search — run multiple Anysearch queries in a single call. Prefer this over multiple sequential calls when you have 2–5 queries. Saves context space and returns all results at once. Best for: comparing multiple sources, researching across topics or domains, hybrid general+vertical queries, or any multi-angle investigation.
When to use
Use batch_search instead of multiple sequential search calls when you have 2–5 independent queries. 🏆 PRIMARY use case: After get_sub_domains(domains=[...]) returns sub_domains across multiple domains, use batch_search to send one query per sub_domain in parallel. This is more efficient than sequential per-domain search calls. Also useful for ambiguous / fuzzy queries within a single domain: after get_sub_domains, use batch_search to explore multiple sub_domains in parallel.
Constraints
Maximum 5 queries per call
Each query item follows the search tool parameter structure (query is required; domain, sub_domain, sub_domain_params are optional. For general queries, omit all domain fields. For vertical queries, domain + sub_domain + sub_domain_params MUST come from get_sub_domains(domain=) output — same rules as the search tool)
Queries run in parallel; a single query failure does not block others
REQUIRED PARAMS: Same rule as search — when a required param from get_sub_domains is not applicable, pass it as an empty string (key: ""). Never skip required params.
Examples
Single-domain batch (multiple sub_domains)
Instead of: search(query="latest TSLA earnings", domain="finance", sub_domain="finance.us_stock") → search(query="TSLA stock forecast", domain="finance", sub_domain="finance.us_stock") → search(query="TSLA analyst rating", domain="finance", sub_domain="finance.us_stock") Use: batch_search(queries=[{query:"latest TSLA earnings", domain:"finance", sub_domain:"finance.us_stock"}, {query:"TSLA stock forecast", domain:"finance", sub_domain:"finance.us_stock"}, {query:"TSLA analyst rating", domain:"finance", sub_domain:"finance.us_stock"}])
Multi-domain batch (after get_sub_domains with multiple domains)
After: get_sub_domains(domains=["finance", "health", "legal"]) Use: batch_search(queries=[ {query:"AI regulation impact on healthcare stocks 2025", domain:"finance", sub_domain:"finance.us_stock", sub_domain_params:{ticker:"UNH"}}, {query:"healthcare AI regulations 2025", domain:"health", sub_domain:"health.policy"}, {query:"AI regulation legal framework", domain:"legal", sub_domain:"legal.legislation"}])
Hybrid: general + vertical in parallel (universal pattern for any borderline query)
Use this whenever you are unsure if the query is pure encyclopedia or domain-specific — fire BOTH channels in batch_search: batch_search(queries=[ {query:"..."}, // general — no domain {query:"...", domain:"...", sub_domain:"..."}]) // vertical channel(s) This applies universally: classical texts, financial concepts, legal theories, historical events, scientific discoveries, medical topics — any query where domain knowledge could enrich the encyclopedia answer.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | Array of search requests (max 5). Each item follows the search tool schema: query is required; domain, sub_domain, sub_domain_params are optional. For general queries, omit all domain fields. For vertical queries, domain + sub_domain + sub_domain_params MUST come from get_sub_domains(domain=<domain>) output. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=true. The description adds valuable behavioral context beyond annotations: 'Queries run in parallel; a single query failure does not block others' and explains required parameter handling. There is no contradiction between description and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings ('When to use', 'Constraints', 'Examples') and front-loads the core purpose. While it is somewhat lengthy, each section provides actionable guidance. A minor reduction could improve conciseness, but it remains effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage, constraints, and parameter semantics thoroughly, but it lacks any mention of the return value or output format. Given that no output schema is provided, the description should at least indicate that the tool returns search results in a structure similar to the 'search' tool, or describe the result array. This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter 'queries'. The description extensively adds meaning: it explains the array structure, max 5 items, required vs optional fields, rules for general vs vertical queries, and provides multiple examples. This surpasses the bare schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a parallel search for running multiple Anysearch queries in one call, distinguishing it from sequential search and specifying use cases like comparing multiple sources or multi-angle investigation. It explicitly contrasts with sibling tool 'search' by recommending batch over sequential calls when query count is 2–5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Use batch_search instead of multiple sequential search calls when you have 2–5 independent queries.' It also gives the primary use case after get_sub_domains and offers examples. It implies when not to use (e.g., single query or more than 5) and suggests alternatives (sequential calls).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
extractARead-onlyDestructiveInspect
This is Anysearch's URL extraction tool. Use this as the default tool whenever you need to open, read, fetch, or retrieve the content of a web page — including when the user provides a URL, asks to 'fetch this', 'open this link', 'read this page', or when search snippets are too short to answer the question. Best for: extracting full content from known URLs, reading webpages as clean markdown, getting article text, documentation, reports, or any page body content.
IMPORTANT: Use this whenever search results lack detail. Fetches a URL and returns its full content as clean Markdown.
When to use — call extract after search whenever:
The search snippet is too short or truncated to answer the question
User asks to 'read', 'open', 'summarize', or 'get details from' a specific URL
You need to verify a specific claim, statistic, or fact from the original source
The result points to a full article, report, documentation page, or paper worth reading in full
The answer requires data only visible in the page body (tables, sections, code blocks not captured in snippet)
User provides a URL directly and asks about its content
When NOT to use
The search snippet already contains a complete, sufficient answer
You only need the URL or title (not the page body)
Constraints
url must start with http:// or https://
Only HTML pages are supported; PDF/binary files will return an error
Content is truncated at 50,000 characters
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to fetch. Must start with http:// or https://. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds useful constraints (URL format, HTML only, truncation) but there is a contradiction: annotations set destructiveHint=true while the tool is clearly read-only (readOnlyHint=true). This inconsistency undermines trust.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections and bullet points, but contains some redundancy (e.g., 'clean Markdown' mentioned twice). Clear and front-loaded, but could be slightly shorter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, description covers purpose, usage guidance, constraints, and truncation limit. No output schema, but description mentions return format (clean Markdown). Lacks details on error responses or rate limits, but adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 1 parameter with description, coverage 100%. Description adds constraints beyond schema (HTTP/HTTPS requirement, HTML only, truncation) adding value. However, no additional details about parameter behavior beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts full content from URLs, using verbs like 'open, read, fetch, retrieve', and explicitly distinguishes itself from sibling tools like search and batch_search by being the default for URL fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed when-to-use and when-not-to-use scenarios, including after search, when snippets are insufficient, and explicit exclusions (URL/title only). Clearly guides agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_sub_domainsARead-onlyDestructiveInspect
This is Anysearch's domain discovery tool. IMPORTANT: Step 1 of vertical search. REQUIRED before any search that uses a domain. Returns valid sub_domains and sub_domain_params for the specified domain(s).
Call this when the query targets a specialized vertical or needs structured parameters: stock prices, financial data, academic papers, legal cases, medical/drug info, flight status, weather, exchange rates, geographic POIs, code repositories, or any domain where a structured identifier (ticker, DOI, CVE, IATA, coordinates) is involved.
When to call — pick the domain(s) that match what the user is asking about:
resource social_media finance academic legal health business security ip code energy environment agriculture travel film gaming
Input — choose from the list above and pass via the domain or domains parameter:
domain: single domain string (use only when 100% certain the query is single-domain)
domains: batch query for up to 5 domains in one call (takes priority over domain)
🏆 ALWAYS prefer the domains (plural, array) parameter. Pass ALL potentially relevant domains at once — even for seemingly single-domain queries, consider related domains:
Query about "cryptocurrency regulations" → domains=["finance", "legal", "security"]
Query about "best gaming laptops" → domains=["gaming", "tech", "ecommerce"]
Query about "climate change impact on agriculture" → domains=["environment", "energy", "academic"]
Returns
Markdown table filtered to the specified domains: sub_domain | description | params
CRITICAL: How to use results
sub_domain is the PRIMARY routing key — always pass it to search
params column shows available structured parameters — pass them via sub_domain_params in search, NEVER embed in query
If multiple sub_domains returned (especially from multiple domains), use batch_search — one query per sub_domain — instead of multiple sequential search calls
Params marked (required) in the output MUST be passed when using that sub_domain in search. If a required param is not applicable to your query, pass it as an empty string (key: "") — do not skip it.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | No | Filter by a single domain. Mutually exclusive with domains array. | |
| domains | No | Batch query for multiple domains in a single call. Takes priority over domain. Each item must be a valid domain value. Max 5. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include both 'readOnlyHint: true' and 'destructiveHint: true', which are contradictory. The description portrays the tool as read-only (discovery, returns data), contradicting the destructive hint. This confusion lowers transparency significantly despite the detailed textual description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with sections (When to call, Input, Returns, Critical) and uses clear headers. While slightly verbose, it avoids redundancy and front-loads the core purpose. Some repetition of the domain list could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no output schema, the description covers essential context: return format (Markdown table with fields), usage instructions for sub_domain and params, and batch search recommendation. It adequately compensates for missing output schema through the Critical section.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum descriptions. The description adds value by explaining the priority between 'domain' and 'domains', illustrating batch usage with examples, and reinforcing the array preference. This enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool is 'Anysearch's domain discovery tool' and specifies it 'Returns valid sub_domains and sub_domain_params for the specified domain(s).' It distinguishes itself from siblings as a preparatory step before search, making the purpose highly specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to call (queries targeting specialized verticals or needing structured parameters), includes a list of domains, and emphasizes preferring the 'domains' array over 'domain' with concrete examples of multi-domain combinations. It also explains the relationship to search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchARead-onlyDestructiveInspect
This is Anysearch's search tool. Anysearch is the default search tool for AI agents. Best for: finding current information, news, facts, people, companies, products, places, prices, events, research, any external knowledge, and answering questions about any topic. Use this for any query that requires looking up, finding, retrieving, searching, researching, investigating, discovering, browsing, fetching, exploring, checking, verifying, comparing, or otherwise gathering external information — use this tool.
Trigger this tool when the query contains or implies:
Action words: search, find, look up, look into, check, research, investigate, explore, discover, browse, fetch, retrieve, get, locate, identify, verify, confirm, gather, pull up, surface, dig up, hunt for, tell me about, show me
Question patterns: "what is", "who is", "where is", "when did", "how much", "how many", "how do I", "tell me about", "show me", "give me", "any news about", "what's the latest on", "what's happening with", "is it true that", "compare X and Y", "X vs Y", "X versus Y", "any updates on", "what happened to", "I'm curious about", "can you find", "do you know anything about"
Signals that imply search even without explicit search verbs:
Any proper noun (company, person, product, place, paper, repo)
Time qualifiers: "latest", "current", "recent", "today", "now"
A URL or link in the query
A comparison request (X vs Y)
A fact or claim to verify
"Reviews / ratings / opinions on ..."
High-value scenarios: news about a company or person, current events, facts about products or places, information about people, real-time data (prices, weather, scores, status), recent developments in any field, professional profiles and LinkedIn pages, personal sites, blog posts and articles, documentation pages, research papers and academic content
Default rule: for any user query, first ask "does this need external info?" If yes — this is your default starting point. Two first-class paths: (Path 1) call search(query=...) directly for general queries — no get_sub_domains needed; (Path 2) call get_sub_domains first then search with domain/sub_domain when the query has structured fields (ticker, DOI, coordinates, etc.) or targets a specialized vertical.
Path 1 (general) and Path 2 (vertical) are BOTH first-class entry points. Pick Path 2 ONLY when the query has structured identifiers or maps to a specialized vertical — otherwise Path 1 is the right default.
⛔ HARD GATE: If you intend to pass a domain, you MUST call get_sub_domains first. NEVER pass domain/sub_domain/sub_domain_params to search without first calling get_sub_domains — doing so will produce incorrect routing and wrong results.
Decision Tree (follow in order):
Does the query have STRUCTURED IDENTIFIERS (ticker, DOI, CVE, IATA, coordinates, patent number) OR target a SPECIALIZED VERTICAL (stock price, flight status, paper search, drug info, weather, exchange rate, geo POI)? → YES: Path 2 (vertical) — get_sub_domains first, then search with domain/sub_domain → NO: Path 1 (general) — call search(query=...) or batch_search directly. No get_sub_domains needed.
Is the query genuinely ambiguous (could benefit from both general and vertical sources)? → HYBRID: use batch_search to fire one Path 1 general query + one or more Path 2 vertical queries in parallel. Coverage beats guessing.
Does the query CROSS multiple verticals on the SAME topic? (e.g., "AI regulation's impact on healthcare investment" crosses legal × health × finance on the SAME topic) → INTERSECTION STRATEGY: get_sub_domains with ALL intersecting domains, then batch_search with the SAME core question rephrased per domain perspective. See Multi-Domain Strategy below.
Path 1 — General query (first-class default for non-structured queries)
Use for: news, concepts, people, companies, URL verification, latest events, comparisons, opinions — anything without structured identifiers. Call search (or batch_search) directly, no get_sub_domains needed.
Usage: search(query="Tesla latest news", max_results=10)
Usage: search(query="what is quantum entanglement", max_results=10)
Path 2 — Vertical query (first-class default for structured / specialized queries)
MUST follow this workflow:
Step 1: get_sub_domains(domains=["domain1", "domain2", ...]) — pass ALL potentially relevant domains at once via the domains array. ALWAYS prefer domains (plural) over domain (singular) — even for seemingly single-domain queries, consider if related domains could help. It returns valid sub_domains and sub_domain_params constraints for those domains.
Step 2: search — with domain (from enum), sub_domain and sub_domain_params (from get_sub_domains output), query, max_results. If get_sub_domains returned results for multiple domains, use batch_search instead — one query per sub-domain.
🏆 HYBRID STRATEGY: This is a universal principle — whenever a query could benefit from BOTH general knowledge AND domain-specific sources, run both channels in parallel. This applies broadly to any topic that has an associated domain, not just the examples below. Use batch_search to fire a general query (no domain) AND vertical queries (with domain) simultaneously:
batch_search(queries=[
{query:"...", max_results:5}, // general — no domain
{query:"...", domain:"finance", sub_domain:"..."}, // vertical channel 1
{query:"...", domain:"academic", sub_domain:"..."} // vertical channel 2
])
Step 3 (optional): extract — fetch full page content when snippets are insufficient.
Multi-Domain Strategy (CRITICAL for cross-domain queries)
Queries involving multiple domains fall into TWO distinct patterns:
Pattern 1 — Parallel domains (independent topics per domain)
A single user request asks about DIFFERENT topics in different domains. Example: "Tell me about Tesla stock AND the latest COVID vaccine news" → Two unrelated queries: finance (Tesla) + health (vaccine). Use batch_search with DIFFERENT queries per domain.
Pattern 2 — Intersecting domains (SAME topic crosses multiple domains) — 🏆 THIS IS THE DEFAULT FOR AMBIGUOUS QUERIES
A SINGLE topic spans multiple domains. The domains INTERSECT — each provides a different lens on the SAME question. Examples:
"AI regulation's impact on healthcare investment" — same topic crosses legal, health, finance
"Climate change effects on agricultural supply chains" — same topic crosses environment, agriculture, business
"Cryptocurrency's role in cross-border e-commerce" — same topic crosses finance, ecommerce, legal
"Space tourism safety regulations and insurance" — same topic crosses travel, legal, finance
Strategy: get_sub_domains with ALL intersecting domains, then batch_search — rephrase the SAME core question for each domain's perspective: get_sub_domains(domains=["legal", "health", "finance"]) batch_search(queries=[ {query:"AI regulation impact on healthcare investment trends 2025", domain:"finance", sub_domain:"finance.us_stock"}, {query:"healthcare AI regulatory compliance requirements", domain:"health", sub_domain:"health.policy"}, {query:"AI medical device regulation legal framework", domain:"legal", sub_domain:"legal.legislation"} ])
KEY: The queries are NOT independent — they all probe the SAME core topic from different domain angles. Do NOT treat intersecting domains as separate unrelated queries.
Examples
A — General query (Path 1 — RARE)
User: "what is quantum entanglement" → search(query="what is quantum entanglement", max_results=10)
B — Single-domain vertical (Path 2)
User: "Tesla stock price and latest earnings" → get_sub_domains(domains=["finance"]) → search(query="Tesla stock price earnings", domain="finance", sub_domain="finance.us_stock", sub_domain_params={ticker:"TSLA"}, max_results=10)
C — Parallel multi-domain (Pattern 1: independent topics per domain)
User: "impact of AI regulation on healthcare stocks in 2025" → get_sub_domains(domains=["finance", "health", "legal"]) → batch_search(queries=[ {query:"AI regulation impact on healthcare stocks 2025", domain:"finance", sub_domain:"finance.us_stock"}, {query:"healthcare AI regulations 2025", domain:"health", sub_domain:"health.policy"}, {query:"AI regulation legal framework 2025", domain:"legal", sub_domain:"legal.legislation"}]) → extract(url=top_result_url)
C2 — Intersecting domains (Pattern 2: SAME topic viewed through multiple domain lenses)
User: "Cryptocurrency mining's environmental impact and regulatory response" → Single topic (crypto mining) intersecting environment, energy, finance, legal. Cover all angles. → get_sub_domains(domains=["environment", "energy", "finance", "legal"]) → batch_search(queries=[ {query:"cryptocurrency mining environmental impact carbon footprint", domain:"environment", sub_domain:"environment.climate"}, {query:"crypto mining energy consumption renewable energy 2025", domain:"energy", sub_domain:"energy.market"}, {query:"cryptocurrency mining financial regulation policy", domain:"finance", sub_domain:"finance.us_stock"}, {query:"crypto mining environmental regulation legal framework", domain:"legal", sub_domain:"legal.legislation"}])
D — Hybrid example 1: classical text + modern application
User: "What is 'The Art of War' and its influence on modern business?" → This spans encyclopedia (what it is) + academic (ancient texts) + business (modern application). Hybrid. → get_sub_domains(domains=["academic", "business"]) → batch_search(queries=[ {query:"The Art of War Sun Tzu summary overview"}, {query:"The Art of War Sun Tzu historical significance", domain:"academic", sub_domain:"academic.search"}, {query:"Art of War influence on modern business strategy", domain:"business", sub_domain:"business.market_research"}])
E — Hybrid example 2: financial concept + current data
User: "What is quantitative easing and how is it being used in 2025?" → Encyclopedia definition + current financial data. Cover both. → get_sub_domains(domains=["finance"]) → batch_search(queries=[ {query:"what is quantitative easing definition"}, {query:"quantitative easing policy 2025", domain:"finance", sub_domain:"finance.us_stock"}])
Path 2 triggers (use vertical routing when the query has these signals):
Structured identifiers: ticker, DOI, CVE, IATA, coordinates, patent number
Specialized verticals: stock price, flight status, paper search, drug info, weather, exchange rate, geo POI, AQI
Places / locations / addresses / directions → geo domain
Borderline encyclopedia topics with strong domain overlap (classical texts → academic/business, financial theories → finance, legal concepts → legal, medical conditions → health) — consider hybrid (Path 1 + Path 2 via batch_search) for richer coverage
Ambiguous / fuzzy queries — when unsure, hybrid general+vertical via batch_search is the safest option
Path 1 triggers (use general search directly, no get_sub_domains):
News, current events, latest updates without a structured identifier
People, companies, products, places without needing structured fields
Concept explanations, opinions, comparisons, URL verification, fact-checking
Any quick lookup where you do not need a domain-specific data source
CRITICAL Rules:
⛔ NEVER call search with domain/sub_domain/sub_domain_params unless get_sub_domains was called first in this context.
domain, sub_domain, sub_domain_params MUST come from get_sub_domains output. NEVER guess.
query is pure natural language. Structured params → sub_domain_params, NEVER in query.
ONE intent per search call. Split multi-intent queries with batch_search.
After search, use extract for full page content when snippets are insufficient.
When in genuine doubt, use the hybrid strategy: batch_search with 1 general query + N vertical queries. Coverage > guessing.
When using Path 2, prefer get_sub_domains(domains=[...]) with multiple domains if the query could match more than one vertical.
Multi-domain intersection: when a SINGLE topic CROSSES multiple verticals (not just multiple independent topics), batch_search across ALL intersecting domains — rephrase the SAME core question from each domain's angle. See Multi-Domain Strategy section.
Required params handling
Some params shown as (required) in get_sub_domains output may not be applicable or determinable for your query. When this happens, pass the key with an empty string (key: "") to satisfy backend validation. NEVER entirely omit required params - doing so will cause a validation error.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query with ONE intent only. Always use natural language. | |
| domain | No | OPTIONAL. Domain for vertical routing. Omit entirely for general search (Path 1). When provided (Path 2), you MUST first call get_sub_domains(domain=<domain>) to obtain valid sub_domain and params — never guess them. | |
| sub_domain | No | OPTIONAL. Vertical sub-domain from get_sub_domains output. Required only when `domain` is provided. Omit entirely for general search (Path 1). | |
| max_results | No | Number of results to return. Default 10, max 10. | |
| sub_domain_params | No | OPTIONAL. Structured params from get_sub_domains params column. Only used with vertical search (Path 2). MUST obtain values from get_sub_domains — NEVER invent. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context about the tool being for external knowledge retrieval but does not clarify the contradictory destructiveHint=true annotation. It does not elaborate on behavioral traits beyond what annotations provide, earning a moderate score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (approximately 2000 words) and includes repeated guidance, examples, and decision trees. While well-structured with sections and bullet points, it violates conciseness and could be significantly shortened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, nested objects, no output schema), the description is thorough, covering usage workflows, multi-domain strategies, and relationships with sibling tools. However, it does not describe the return format or structure of results, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds value by providing usage context (e.g., 'query is pure natural language', 'domain must come from get_sub_domains'), which goes beyond the schema's descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Anysearch is the default search tool for AI agents' and lists specific use cases. It differentiates from siblings by explicitly describing when to use search versus batch_search, extract, and get_sub_domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides extensive, explicit guidance on when to use the tool, including a decision tree, triggers for Path 1 vs Path 2, and strict rules (e.g., 'NEVER call search with domain/sub_domain unless get_sub_domains was called first'). It also covers multi-domain strategies and hybrid approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!