Skip to main content
Glama
yinnho

AginxBrowser

by yinnho
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust

search

Read-only

Aggregate and deduplicate web results from Baidu, Bing, Sogou, WeChat, and Google, with optional full-content fetching for top results. Use it to find information online.

Instructions

Search the web across Baidu/Bing/Sogou/WeChat/Google (aggregated + deduped) and optionally fetch the top results' full content. Use when the agent needs to FIND information online - replaces a search API. Supports image search returning direct image URLs. Optional engines: ["baidu"]-style filter by engine name (invalid names error with the valid list; /doctor lists them with live health). Optional time_range day/week/month/year for news freshness (engines without dated results ignore it). Response carries engine_errors explaining any engine that contributed nothing (CAPTCHA suspension, transient failure).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qYesSearch query
enginesNoRestrict to these engine names (e.g. ["baidu"], ["sogou_wechat"]). Empty = all engines serving `categories`. Invalid names return an error listing the valid ones.
fetch_topNoFetch content for top N results
categoriesNoSearch categories (default: general)general
time_rangeNoFreshness window: "day" | "week" | "month" | "year". Honored by engines with dated results (e.g. bing_news filters by pubDate); others ignore it.
max_resultsNoMaximum number of results (default: 10)
max_chars_perNoMax characters per result content

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.1
    • removedInput schema / title
      Removed value: -"SearchParams"
  2. Changed2 schema fields changedv0.3.3-rc1
    • addedInput schema / properties / engines
      Added value: +{
+  "default": [],
+  "description": "Restrict to these engine names (e.g. [\"baidu\"], [\"sogou_wechat\"]).\nEmpty = all engines serving `categories`. Invalid names return an\nerror listing the valid ones.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • addedInput schema / properties / time_range
      Added value: +{
+  "default": null,
+  "description": "Freshness window: \"day\" | \"week\" | \"month\" | \"year\". Honored by\nengines with dated results (e.g. bing_news filters by pubDate);\nothers ignore it.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
  3. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true, so safety is covered. The description adds meaningful behavioral details beyond that: aggregation and dedup, engine-filter error behavior, engine_errors field explaining partial failures (CAPTCHA/transient), and time_range being ignored by some engines. This is valuable runtime behavior that the schema alone would not convey.

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 dense but front-loaded with the core action and ends with error-handling behavior. It is longer than ideal, and 'Optional engines: [...]' wording is slightly awkward, but every sentence carries information not present in the schema, so it earns its length.

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?

Given no output schema, the description helpfully explains engine_errors and image-search return behavior, filling an otherwise empty return-value story. It doesn't describe dedup mechanics or result shape in detail, but for a 7-parameter tool with full schema coverage, readOnlyHint, and error-behavior notes, it is reasonably complete.

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%, so the baseline is 3. The description does add a little cross-parameter meaning — e.g., engines work with `categories`, invalid engine names error with a valid list, and `time_range` is only honored by dated-result engines — but most parameter meaning already lives in the schema's property descriptions. It doesn't rise above baseline.

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 names a specific verb-resource pair ('Search the web'), enumerates the aggregated engines, and distinguishes itself from sibling tools like `fetch` and `click` by stating it replaces a search API and supports image search. This is a clear, specific purpose statement that differentiates it from the surrounding navigation and session tools.

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 explicitly says 'Use when the agent needs to FIND information online' and mentions fetching full content as an optional follow-on, which implies when `fetch_top` is the right parameter. It does not explicitly name sibling alternatives or state when not to use this tool (e.g., use `fetch` for a single known URL), so it loses a point on exclusions, but the core usage context is clear.

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

Deploy Server

Other Tools