Skip to main content
Glama
telly6

searchpin

web_search

Search the web via multiple engines including Baidu, Sogou, and Bing. Returns ranked titles, URLs, and snippets re-ranked by relevance using embedding similarity.

Instructions

Search the web via multiple engines (Baidu, Sogou, Bing CN, Bing Intl). Returns ranked titles, URLs, and snippets (no full page content — use web_fetch to get the full text of any result). Results re-ranked by embedding similarity — the top results are the most relevant.

Iterative search is normal: search → read → refine → search → read → synthesize. Search returns only titles + snippets. Read snippets to identify promising results, then call web_fetch to get full page content for the URLs that look most useful.

BEFORE FETCHING, READ THE SNIPPETS FIRST:

  • Search results come with title + URL + snippet only (no full content). Read snippets to decide which URLs are worth fetching.

  • Fetch only the 1-3 most promising URLs — do not blindly fetch everything. Each unnecessary web_fetch wastes 1-3s per call.

⛔ WHEN RESULTS LOOK WRONG, DO NOT GIVE UP — ITERATE IMMEDIATELY: If search results are all irrelevant (wrong topic, wrong domain, generic encyclopedia entries, piracy sites, brand pages, file format tools, or dictionary entries), DO NOT conclude the information is unavailable. The fix is almost always a query reformulation. The most common root cause is Bing's tokenizer splitting your query words into fragments that collide with unrelated content. Replace fragile/generic terms with INSEPARABLE identifiers — proper nouns, compound terms, subdomain names, or acronyms that the tokenizer CANNOT split. Then immediately re-search. Do not narrate the failure — just try a different formulation. The PRINCIPLE (not the specific domain) matters:

  • A law query: 'GDPR enforcement tracker 2026' not 'GDPR fine'

  • A car query: '全固态电池量产线' not 'solid state battery'

  • A finance query: 'USDJPY exchange rate' not 'yen dollar'

  • A programming query: 'rustc 1.87 changelog' not 'Rust release notes'

  • FOR CHINESE: no spaces around Chinese chars! '2026年新能源汽车补贴' ✓, '新能源汽车补贴 2026' ✗

SEARCH STRATEGY (patterns drawn from real-world use):

  1. DATE TERMS HIJACK QUERIES — Putting year numbers or month names ("2026年", "June") directly in query text often backfires: the engine weights them as the primary topic and you get calendar summaries or current-events roundups instead of your actual topic. PREFER the 'freshness' parameter to control recency — it filters by publication date without polluting the query text.

  2. SHORT COMMON WORDS COLLIDE — In Chinese, single characters that are also standalone dictionary headwords get tokenized independently and matched to dictionary/encyclopedia entries, regardless of surrounding context. In English, short common words that also name major products/services (credit card brands, consumer goods) cause the same problem. RECOGNISE THE PATTERN: if any word in your query could appear as a dictionary headword or a product name on its own, it WILL collide. Embed such terms inside longer inseparable compounds.

  3. LONG PROPER NOUNS ARE ANTI-NOISE ANCHORS — Full institutional names, drug trade names, legal case codes, product model numbers resist tokenizer fragmentation. They act as unbreakable signals that pull results toward the right topic. When a shorter query goes off-target, try a version built around a specific long-form name.

  4. LANGUAGE-SWITCH ESCAPES TOKENIZER TRAPS — When a Chinese query keeps hitting noise despite retries, switch the query to English. English-language media covers many China-specific topics, and the English tokenizer does not fragment CJK characters into dictionary entries.

  5. REPLACE THE ANCHOR — Adding another word to a noisy query rarely fixes it (the original offending token still dominates the ranking). Instead, restructure the query around a DIFFERENT anchor term entirely — a proper noun, a model number, or a multi-word technical phrase that the tokenizer cannot split.

  6. THE VOCABULARY BRIDGE — Chinese search engines match on LEXICOGRAPHIC (word-level), NOT semantic. The words you use MUST match how the target documents actually phrase things. This creates a critical gap:

  • User language (descriptive): 极端天气, 气候灾害, 高温热浪

  • Source language (operational): 暴雨橙警, 三级应急响应, 解除预警 These are two entirely different vocabulary systems and the engine CANNOT automatically map between them. When abstract category terms return only encyclopedia definitions and year-old retrospectives, switch to the OPERATIONAL terms that the institutions/sources themselves use — alert levels, government response codes, proper institutional names, numeric thresholds ("四十度"), or named entities ("台风蔷薇").

  • Abstract: '2026年极端天气气候灾害' → only dictionaries & retrospectives

  • Operational: '暴雨橙警 应急响应 中央气象台' → nmc.cn real-time alerts This is not a data-coverage problem. The documents exist in the index. They just use a different vocabulary than you searched for.

⚡ NUMERIC DATA CROSS-VERIFICATION:

  • When a critical number appears in one result, confirm it against at least one other source before accepting it as fact. Different aggregators can lag; conflicting values demand a third source.

⛔ DO NOT STOP EARLY — PERSISTENCE IS REQUIRED:

  • When a search returns 10 irrelevant results, that does NOT mean the information doesn't exist. It means the current query formulation failed to reach it. Real-world testing shows: the same engine (baidu/bing_cn) that returned 100% calendar-dictionary noise for '2026年极端天气' returned nmc.cn real-time severe weather alerts (rerank 0.908) when reformulated as '暴雨洪涝 应急响应 中央气象台 预警'.

  • Top-10 failure is a QUERY PROBLEM, not a content-availability problem. The valid pages are likely at positions 11-30, pushed out of view by noise that matched your abstract terms. Do not conclude 'information unavailable' from a failed top 10.

  • EXHAUST AT LEAST 3-4 DISTINCT STRATEGIES before any 'not found' verdict:

    1. Different vocabulary (descriptive → operational)

    2. Different language (CN ↔ EN)

    3. Different anchors (category term → proper name/number)

    4. Site-restricted search (site:target-source.tld)

  • Never stop after 1-2 rounds just because the first attempts returned noise. The difference between 'completely unsolvable' and 'fully answered in 1 round' is often a single query reformulation — changing '极端天气' to '暴雨橙警'.

CONDUCT ALL ITERATIONS SILENTLY: When you need multiple rounds of searching and fetching to gather information, run all iterations as tool calls without narrating each step in your reply. Present only the final synthesized answer to the user. Do NOT say things like 'let me search again' or 'I tried searching for X but got Y, let me try Z instead' — just do it and deliver the result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
queryYesSearch query keywords
topicNoSearch vertical. 'general' (default, web search) or 'news' (Bing News — prioritises recent articles from mainstream media; best for earnings, sports scores, political events, breaking stories). Also useful as an escape hatch: when 'general' returns Chinese dictionary entries for a query that should have news coverage, switching to 'news' can bypass the dictionary index entirely.
freshnessNoTime filter. One of: d (past day), w (past week), m (past month), y (past year). PREFER this over putting years/months in the query text — date words in queries get weighted as the primary topic and cause noise. This parameter filters by publication date without polluting the query. Omit for no filter.
max_resultsNoMax results to return (default 10, max 20). Controls output count only.
exclude_domainsNoDomains to filter OUT of results before re-ranking. Use when a previous search returned pages from a noise domain (e.g. a dictionary site, a brand page, a mirror). Example: ['zidian.gushici.net', 'hancibao.com']. Supply at runtime only — no permanent blocklist.
include_domainsNoLimit results to ONLY these domains (whitelist). Use when you want results from specific sources (e.g. ['docs.python.org', 'python.org'] for Python docs only). Applied before re-ranking. Empty/omitted = no restriction. Supplied by the LLM at runtime — no hardcoded list.
Behavior5/5

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

No annotations provided, but description fully discloses re-ranking by embedding similarity, multiple engines, tokenizer issues, noise causes, and the lack of full content. Also mentions numeric data cross-verification and failure handling.

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?

Very long but well-structured with sections, examples, and warnings. Each sentence adds value, though some repetition exists. Impressive detail without being bloated.

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?

No output schema but explicitly states returns titles, URLs, snippets. Covers edge cases, iteration strategies, query reformulation, and cross-verification. Highly complete for a complex search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but description adds significant meaning: explains topic parameter's use to bypass dictionary, freshness parameter's advantage over date terms, and real-world use cases for exclude/include domains.

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 clearly states the tool searches the web via multiple engines returning ranked titles, URLs, and snippets. Explicitly distinguishes from sibling web_fetch by noting it does not return full page content.

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?

Provides extensive guidance: iterative search strategy, when to fetch vs search, query reformulation patterns, language switching, and domain filtering. Explicitly contrasts with web_fetch and advises on when to use each.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/telly6/searchpin'

If you have feedback or need assistance with the MCP directory API, please join our Discord server