v0.7.3 - AnySearch plugin options example

This release adds a keyless plugin-options example so an installed plugin row shows the Options button in Magpie. It does not change search behavior, provider registration, keys or request defaults.

Plugin options example

• package.json now declares magpie.options for AnySearch:

  {
    "anysearch": {
      "format": "markdown"
    }
  }

• AnySearch works without a key. Its format already defaults to markdown, so saving the example changes no behavior.

• Magpie uses the example only to prefill the Options editor. Nothing is applied until the user clicks Save; before that the plugin still receives undefined options.

• No enable/disable, resultLimit or non-default provider settings are included, so the example cannot filter providers, cap host counts or alter request quality or cost.

• The example is metadata for the installed plugin row. It does not add keys, enable providers, or change anonymous access for AnySearch, Keenable, Parallel or TinyFish.

Documentation

• The Chinese and English READMEs now say the Options editor starts from the AnySearch example and takes effect only after Save.
• The CLI example now uses AnySearch instead of a key-required provider.

Validation

• npm run check: 21 search APIs, 380 tests across 28 files, 0 failures.

• npm run check:bun (Bun 1.4.4): 380 tests, 0 failures.

• npm run smoke:magpie with Magpie 0.1.3511: 21 APIs; registration, options, custom URLs, timeouts, errors, anonymous cooldown, keyed rotation and fallback, Coding Plan MCP lifecycle and site isolation pass.

• Isolated host check: magpie plugin options <path> reports:

  No options set. Its package suggests:
  {
    "anysearch": {
      "format": "markdown"
    }
  }
  

• npm pack --dry-run: 41 files; the package includes the entry, src/, docs/, both READMEs and the icon.

• Validation uses dummy keys, stubs and local mock services where applicable; no live keyed provider search, billing, quality or online rate-limit verification is claimed.

Full changelog: v0.7.2...v0.7.3

v0.7.2 - Restrict result URLs to http(s)

This release hardens result handling by restricting every returned search URL to an absolute http: or https: address. The plugin still registers 21 search channels; provider IDs, configuration names, credentials, endpoints and request behavior are unchanged.

Result URL policy

• Result URLs are now parsed and canonicalized before being returned. Non-web schemes such as javascript:, data:, file:, blob:, ftp: and mailto: are dropped.
• URLs containing embedded credentials, C0/C1 or bidi mark/embedding/isolate controls, line separators, or more than 8192 UTF-16 code units before or after canonicalization are dropped.
• Invalid rows are removed before the local result cap, so an unsafe row cannot consume a result slot.
• A non-empty result set whose URLs are all unusable now fails as a malformed payload and is not cached. An explicit empty array remains a valid empty answer.
• Dual-field providers prefer a usable link and otherwise fall back to a usable url (Metaso and the Coding Plan channels).
• Titles that are missing or whitespace-only fall back to the canonical URL.

Behavior notes

• Reachability is never checked and result URLs are never fetched. Loopback and private literal hosts remain allowed; this is not an SSRF layer.
• SerpApi now fails a non-empty all-invalid organic_results payload instead of returning an empty success.
• The policy applies uniformly to all REST providers and both Coding Plan MCP channels.

Validation

• 380 tests across 28 files pass.
• npm run check passed with all 21 search APIs registered.
• Release CI passed on Node.js 22, Node.js 24, Bun, and the Magpie host smoke job.
• A live anonymous AnySearch request returned five results, all absolute http(s) URLs.
• Validation uses dummy keys, stubs and local mock services where applicable; no live keyed provider search, billing, quality or online rate-limit verification is claimed.

Full changelog: v0.7.1...v0.7.2

v0.7.1 - Hardened search boundaries and response budgets

This release hardens the shared HTTP and MCP boundaries without adding new providers. The plugin still registers 21 search channels, and provider IDs, configuration names, credentials, endpoints, and result shapes are unchanged.

Reliability and security

• Ordinary REST responses now use a bounded streaming reader: 16 MiB (16,777,216 bytes) for successful bodies and 64 KiB (65,536 bytes) for failed-response bodies.
• The reader counts actual bytes after fetch decompression instead of trusting Content-Length. An oversized body is cancelled and fails without returning partial results or writing the cache.
• Oversized non-2xx bodies still preserve the numeric HTTP status and Retry-After metadata so Magpie can rest and rotate keys; 429 responses keep their retry hint.
• Empty queries are rejected before any request. Linkup, Metaso, Querit and other keyed channels trim surrounding key whitespace.
• All REST and stateless MCP requests reject HTTP redirects, including the previously inconsistent early-generation providers.
• Malformed result shapes now fail explicitly instead of silently caching an empty answer. Explicit empty arrays remain successful and keep the short empty-result cache.
• Upstream business diagnostics are bounded, including dynamic AnySearch, Querit and Moonshot error fields.
• MCP JSON-RPC responses keep the existing 10 MiB budget. Timeout classification now uses a structured internal error instead of matching server-controlled text.

Tests and documentation

• 371 tests across 28 files pass, including new coverage for REST byte budgets, split UTF-8 chunks, cancellation, status preservation and no-cache behavior.
• Release CI passed on Node.js 22, Node.js 24, Bun, and the Magpie host smoke job.
• The npm dry run includes 41 files and packages src/mcp/limits.mjs.
• Tests are discovered through scripts/test.mjs on both Node and Bun, avoiding Windows cmd glob limitations.
• Chinese and English technical references and the provider integration checklist document the new budgets and request constraints.

Notes

• Validation uses dummy keys, stubs and local mock services. No live keyed provider search, billing, quality, latency or online rate-limit verification is claimed.
• The REST limits are local defensive budgets, not upstream service limits. MCP and REST continue to use separate budgets.

Full changelog: v0.7.0...v0.7.1

v0.7.0 - Coding Plan search and MCP session architecture

This release adds Zhipu Coding Plan and Z.ai Coding Plan search over Streamable HTTP MCP, bringing the total to 21 search channels. It also separates MCP response parsing, search-result extraction, and session handling, with expanded automated verification and bilingual documentation.

New search providers

• Zhipu Coding Plan: China Coding Plan search via https://open.bigmodel.cn/api/mcp/web_search_prime/mcp, registered as magpie-websearch:zhipu-coding.
• Z.ai Coding Plan: International Coding Plan search via https://api.z.ai/api/mcp/web_search_prime/mcp, registered as magpie-websearch:zai-coding.
• Both providers require the corresponding site's Coding Plan key and consume shared plan credits. They remain separate from the existing Zhipu and Z.ai Standard REST providers, with independent credentials, configuration, endpoints, and caches.
• Search requests follow Magpie's requested result count and any explicit resultLimit. Optional recency, domain, and content-size fields are sent only when advertised by the server's tool schema; unsupported configured filters fail explicitly.

The Coding Plan providers are experimental. Real-account search and billing remain unverified on both sites, and Magpie's eligibility under the current client usage policy has not been confirmed. This project does not claim official Zhipu or Z.ai support for Magpie.

Reliability and architecture

• Complete MCP session lifecycle on result-cache misses: initialize, notifications/initialized, tools/list, tools/call, and best-effort DELETE. Cache hits return results without opening a session.
• Initialization, discovery, and tool execution share one timeout budget; cleanup has a separate one-second limit. JSON and SSE responses, protocol negotiation, session headers, and host cancellation are supported.
• Preserve HTTP refusal status and validated Retry-After metadata while withholding refusal bodies and redacting known credentials and session identifiers. Session requests reject redirects.
• MCP failures never automatically switch to metered REST or retry on the other site. Magpie can still try another explicitly configured provider using that provider's own credentials.
• Organize MCP modules under src/mcp/, with independent stateless and session clients sharing response decoding. Parallel and TinyFish retain their direct, stateless MCP calls.
• Share search-result extraction with explicit per-caller compatibility options. Coding Plan supports structured content, results / search_result arrays, and up to three JSON decoding layers without broadening Parallel or TinyFish's default behavior.
• Read the MCP client version from the installed package.json, keeping handshake metadata aligned with the package.

Documentation

• Update Chinese and English READMEs, technical references, provider guidance, and release checks for both Coding Plan channels.
• Clarify cache behavior, timeout boundaries, schema field gating, result URL filtering, and the distinction between provider isolation and Magpie's configured fallback.
• Add the README hero image and document MCP initialization metadata alongside the search-data privacy behavior.

Validation

• 329 tests passed on both Node.js 24.19.0 and Bun 1.4.4 across 26 test files.
• Isolated host checks passed on Magpie 0.1.3141, covering 21-channel registration, Coding Plan JSON/SSE sessions, schema-gated arguments, timeouts, key rotation, fallback, and site isolation.
• Release CI passed on Node.js 22, Node.js 24, Bun, and the Magpie host smoke job. Package dry-run checks include all MCP modules and both Coding Plan providers.
• Coding Plan validation uses dummy keys and local mock services; it does not establish real-account quota routing, billing, retrieval quality, or latency.

Full changelog: v0.6.1...v0.7.0

v0.6.0 - Six new search providers and bilingual documentation alignment

This release adds Perplexity, Bocha, Ollama, Jina, Kagi, and Serper, bringing the total to 19 search APIs. It also establishes full bilingual alignment across the documentation and configuration references, standardizes provider options ordering, and expands automated host verification.

New search providers

• Perplexity: Official standalone Search API (POST https://api.perplexity.ai/search), supporting web and fast search modes, recency filtering, country and language filters, and local code-point truncation.
• Bocha: China standalone REST search API (POST https://api.bochaai.com/v1/web-search), default snippet mode with explicit opt-in for generated summaries (summary: true), freshness filters, and structured business error handling (code, log_id).
• Ollama: Official cloud Web Search API (POST https://ollama.com/api/web_search) requiring an Ollama account API key, with configurable content length budgets (contentChars) and URL filtering.
• Jina: Dedicated Jina Search API (POST https://s.jina.ai/search), default snippet mode with optional full-text extraction (content: "full"), contentChars truncation, and gl/hl/location parameter forwarding.
• Kagi: Kagi Search API in public preview (POST https://kagi.com/api/v1/search), with Lens override support, recency filtering (day/week/month), region filtering, and 1024 local result capping.
• Serper: Alternative Google organic search (POST https://google.serper.dev/search), fixed wire num: 10, local result capping via maxResults, tbs time filtering, and isolated X-API-KEY authentication independent of SerpApi.

All new providers integrate with Magpie's credential management, search ordering, and on/off controls, supporting custom complete endpoint URLs and per-provider options.

Reliability and architecture

• Isolated credentials, endpoint routing, and per-provider caches across all 19 providers.
• Standardized Retry-After header parsing (delay-seconds or HTTP-date) and 429 key rest rotation across all newly added providers.
• Shared HTTP layer retains known HTTP status codes and retry metadata upon body consumption timeout or interruption, allowing Magpie to rotate to healthy keys.
• Independent options and environment variables per provider with full fallback behavior (explicit option → environment variable → default).

Documentation

• Complete bilingual alignment between Chinese and English documentation (README.md, README.en.md, docs/technical-reference.md, docs/technical-reference.en.md).
• Symmetrically aligned Table 6 configuration reference covering all 113 options across 19 providers in alphabetical order.
• Synchronized CLI management commands, provider protocols table, and Table of Contents across both languages.
• Updated integration roadmap and status in PROVIDERS.md and verification guidelines in RELEASING.md.

Validation

• 300 tests passed on both Node.js 24.19.0 and Bun 1.4.4 across 22 test files.
• Isolated host checks passed on Magpie 0.1.3041, covering registration filters, custom exact endpoints, timeouts, 429 cooldown, key rotation, and fallback.
• New providers were verified with dummy keys and local mock services. Successful searches, billing, account limits, and retrieval quality with real account keys remain unverified.

Full changelog: v0.5.0...v0.6.0

v0.5.0 - Five new search providers and improved reliability

This release adds Moonshot, Moonshot CN, Zhipu, Z.ai, and StepFun China, bringing the total to 13 search APIs. It also improves HTTP error handling, Unicode text truncation, test isolation, and bilingual documentation.

New search providers

• Moonshot / Moonshot CN: Standalone Basic search APIs for the international and China platforms, with snippet and full-text modes. Credentials, configuration, and caches are isolated between sites.
• Zhipu / Z.ai: Standalone search APIs for both platforms. Zhipu supports search_std, search_pro, Sogou, and Quark; Z.ai uses search-prime.
• StepFun China: Standalone REST search with optional programming, research, government, and business categories, plus snippet or full-text selection.

All new providers use Magpie’s credential management, search ordering, and on/off controls. They support custom complete endpoint URLs and per-provider plugin options.

Reliability and maintenance

• Preserve known HTTP status codes and retry metadata when reading an error response body fails or times out, allowing Magpie to continue key rotation.
• Cancel unread response bodies when returning a fixed HTTP 402 error, without waiting for cleanup.
• Preserve StepFun’s type and code identifiers before truncating long error messages.
• Share Unicode text truncation across adapters, preserving surrogate pairs and avoiding full-page array allocation.
• Improve provider names in configuration errors and reduce test dependencies on unrelated providers and registration counts.

Documentation

• Split and expand the Chinese and English technical references, covering defaults, environment variables, protocol limits, and verification records.
• Clarify the distinction between StepFun’s China REST API and its international Step Plan MCP endpoint. This release integrates China REST only.
• Add the LINUX DO friend link to both READMEs.

Validation

• 219 tests passed on both Node.js 24.19.0 and Bun 1.4.4.
• Isolated host checks passed on Magpie 0.1.3026, covering registration filters, custom endpoints, timeouts, key rotation, and fallback.
• New providers were verified with dummy keys and local mock services. Successful searches, billing, account limits, and retrieval quality with real account keys remain unverified.

Full changelog: v0.4.0...v0.5.0

v0.3.0 - Parallel search and exact endpoint architecture

Parallel is now available as magpie-websearch:parallel, with anonymous search through its hosted MCP endpoint and authenticated search through its GA REST API. Leave the key empty to search without an API key; a supplied key selects REST.

What's new in v0.3.0

Parallel Web Search

• Dual-mode access: Anonymous MCP (POST https://mcp.parallel.ai/mcp, tool web_search) and authenticated REST (POST https://api.parallel.ai/v1/search with x-api-key).
• Modes: Defaults to fast mode. REST supports fast, turbo, basic and advanced; non-fast modes require a key.
• Constraints & Excerpts: Enforces Parallel's 1–200 character keyword query limit, joins multiple excerpts with double linebreaks, respects contentChars (default 4000 code points, 0 keeps all), preserves publish_date as age, and applies the 20-result upstream cap.
• Fault-tolerance: Supports anonymous 429 cooldown with Retry-After, and keyed refusals never fall back to anonymous mode.

Exact Endpoint Resolution (WYSIWYG)

• Eliminated heuristic rewriting: Replaced searchEndpoint path-guessing logic with resolveEndpoint. Custom Base URLs are now treated as exact endpoints without appending /v1/search or modifying paths, eliminating proxy path pollution.
• All six providers (AnySearch, Keenable, Linkup, Parallel, Querit, TinyFish) now share a 100% symmetric, predictable endpoint model.

Shared MCP Transport

• Generalizes stateless single-tool MCP execution and structured result extraction into src/mcp.mjs.
• Removed legacy transitional files, unifying provider directory structure.

Verification

• All 94 automated tests pass on Node.js and Bun.
• Verified in Magpie 0.1.2901 sandbox: provider loading, registration filters, custom exact endpoints, timeout, 429 cooldown and fallback across all providers.

Full changelog: v0.2.1...v0.3.0

v0.2.1 - TinyFish anonymous and keyed search

TinyFish is now available as magpie-websearch:tinyfish, with anonymous search through its hosted MCP endpoint and authenticated search through its REST API. Leave the key empty to search without an API key; a supplied key selects REST.

• Support MCP JSON and SSE responses, cancellation and timeouts while reading streams, and anonymous HTTP 429 cooldowns.
• Add location, language, domain filters, search type and a local result cap. Paper search (research_paper) requires a key.
• Keep settings and caches isolated per plugin instance, endpoint, access mode, key and effective search parameters. A refused key does not fall back to anonymous access.
• Register all five providers by default while preserving the existing enable/disable filters.
• Scope the MCP transport to src/providers/tinyfish-mcp.mjs and update configuration, provider and release documentation.

TinyFish custom Base URLs are complete endpoints: no path is appended. Use an MCP endpoint without a key and a compatible REST Search endpoint with one. Leaving the address empty selects the corresponding official endpoint automatically.

Validation: all 74 tests pass on Node.js 24.19.0 and Bun 1.4.4. The real magpie 0.1.2897 host passes the smoke checks, including MCP JSON/SSE, REST GET, local caps, cooldown and fallback. Anonymous search was also verified against TinyFish's live endpoint. REST success with a real account key has not been verified; keyed requests and SSE parsing were tested against a local fake service. The anonymous quota scope and precise limits remain unverified.

v0.2.0 - Anonymous search and provider options

Search improvements

• AnySearch and Keenable now support anonymous search without an API key. Keenable automatically selects /v1/search/public; supplying a key uses the authenticated endpoint.
• Anonymous HTTP 429 responses start a cooldown for the affected API endpoint. The plugin respects Retry-After, uses 60 seconds when it is unavailable or invalid, and lets Magpie try another configured search API during the cooldown.
• Each provider accepts its own options, including result limits, timeouts and cache settings. Explicit options take priority over environment variables, while the optional enable and disable registration filters remain available.
• All four providers honor custom Base URLs, including path prefixes and full search endpoints.
• Search caches are isolated by endpoint, key and request parameters, including result count. Each plugin instance has separate settings and caches.

Plugin identity

• The plugin display name is magpie-websearch, with a new icon included in the npm package.
• Search entries use the (magpie-websearch) suffix in Magpie's GUI and CLI. Existing vendor IDs stay unchanged, so saved keys, switches and order continue to work.

Documentation and validation

• Updated configuration examples, anonymous-search instructions, provider naming rules and release documentation.
• The provider roadmap contains nine candidates that are absent from Magpie's reviewed built-in search APIs and provider presets, including Parallel and TinyFish.
• Added Bun checks and isolated Magpie host tests against the unpacked npm package.
• All 52 automated tests pass on Node.js 20.3.0, Node.js 24 and Bun 1.4.4. Host validation uses Magpie 0.1.2891 and local test endpoints, covering anonymous registration, custom URLs, timeout, cooldown and fallback.

Upgrade

magpie plugin update

To add anonymous search without a key:

magpie search add magpie-websearch:anysearch
magpie search add magpie-websearch:keenable

Linkup and Querit still require API keys. For an existing keyed entry, leaving the key field empty keeps the saved key. To switch it to anonymous mode, remove the search entry and add it again without a key, then restore any custom URL, order or on/off setting as needed.

Development commands require Node.js 20.3.0 or later; Magpie continues to run the plugin on its managed Bun runtime.

Full changelog: v0.1.2...v0.2.0