superagents-lab/dsh-s1

dsh-s1

Native s1 tools for the DeepSeek Harness (DSH).

Unlike the MCP server (search1api-mcp, a generic bridge that surfaces as mcp__search1api__*) or the CLI skill (which teaches the model to shell out to s1), this package registers first-class DSH tools named s1_* — same layer as read, bash, subagent, workflow. Calls run in-process against the official @search1api/client SDK.

Tools

Not yet implemented: s1_screenshot (needs DSH attachment/image support) and s1_deepcrawl (long-polling task).

Skill

The package also bundles a s1 skill (ctx.skills.register), which teaches the model how to pick the right tool and tune parameters — quick lookup vs deep research, source/recency signals, Chinese-query engine choice, and when to follow a search result with s1_crawl. It is registered with the tools and can be disabled independently via skill: false.

Architecture

@search1api/client  (official SDK, in-process)
        │ import
dsh-s1              (Cordis plugin: name/inject/apply)
        │ loaded by the `s1-tools` row in cordis.patch.yml
ctx.tools.register(defineTool({ name: "s1_search", ... }))
        │
DSH model sees `s1_search` as a native tool

The package is both the bundle (its dsh.bundle.patch → cordis.patch.yml) and the plugin (its main entry exports name/inject/apply). The patch inserts a single loader row that references the package itself:

- insert:
    - id: s1-tools
      name: 'dsh-s1'

Install into a DSH profile

First publish (or npm link / local path) the package, then:

dsh plugin --profile web add dsh-s1

For a local checkout, use a path spec (the plugin command anchors relative paths to your invoking directory):

cd /Volumes/More/Products/search1api/ecosystem/dsh-s1
npm run build                      # produce lib/index.js + lib/index.d.ts
cd ~/.dsh
dsh plugin --profile web add file:/Volumes/More/Products/search1api/ecosystem/dsh-s1

dsh plugin reconciles dsh.profile.bundles: because this package declares dsh.bundle.patch, it is appended to the profile’s bundle stack automatically.

Authentication

The SDK reads its key lazily, so a missing key fails the tool call (not plugin activation). There is exactly one credential variable:

export S1_KEY=...

OAuth (roadmap — not implemented yet)

s1’s API accepts Authorization: Bearer <token> for both an API key and an OAuth access token, so the transport layer is token-agnostic. The OAuth flow (browser login, PKCE, token storage, refresh) currently lives only in search1api-cli (s1 login + auth.ts); @search1api/client does not yet expose it. The DSH plugin will support OAuth by reusing or sinking that flow, rather than re-implementing it — tracked separately from this skeleton.

Config

Development

npm install
npm run typecheck
npm run build