searchts

Overview Schema Source Related Servers Discussions Admin

login_signin

Sign in once in a browser window that opens for the target site and keep that login to get past a login wall when no usable browser session exists.

Instructions

Sign in once for a site, in a browser searchts opens, and keep that login. Nothing is copied from the user's own browser. This is the way past a login wall when the user has no browser session worth copying, or refuses to have one read. A login kept this way is not refreshed automatically, because there is no browser source to re-copy; when it nears expiry the user is told to run login_signin again. Requires the user to be at the machine: tell them a window will open, they sign in there and then CLOSE the window to finish. Opening that window is the approval; nothing else is asked. The call waits up to wait_seconds (default 180, 30 to 900) and keeps nothing if the time runs out or the window is closed without a sign-in. Raise wait_seconds only if the host allows tool calls that long. Returns JSON {host, kept, cookies, why}, or 'Error: ...' on failure. Update check: when a newer release exists, a successful result also carries 'update_available' plus, at most once per 24 hours, one line telling the agent. The check is one GET to the GitHub latest release of capad-xyz/searchts, at most once per 24 hours, cached in ~/.searchts/update-check.json, with a searchts User-Agent and nothing about the user. Nothing is installed or changed. SEARCHTS_NO_UPDATE_CHECK=1 turns the check and the note off.

Input Schema

Name	Required	Default
`url`	Yes
`browser`	No	chrome
`wait_seconds`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.23.0Oct 27, 2026
- addedInput schema / properties / wait_seconds
```
Added value: +{
+  "default": 180,
+  "title": "Wait Seconds",
+  "type": "integer"
+}
```
Addedv0.15.0Oct 13, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does it: the window opening is the approval, the user must be at the machine, closing the window finishes, timeouts keep nothing, and success/failure return shapes are given. It also discloses a side effect (the update check GET and its env-var opt-out) that an agent would otherwise be surprised by.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and usage are front-loaded well, but the final third is an extended update-check disclosure with paths, User-Agent details and an env var, which is tangential to signing in and inflates the text an agent must parse. The core sign-in behavior could be stated in about half the length.

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?

For an interactive login tool with no annotations, everything needed to invoke it safely is present: prerequisites, the human-in-the-loop flow, timeout semantics, and the return JSON. The output schema exists yet the description still names the result fields, so nothing essential is missing.

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 coverage is 0%, so the description must compensate. It fully documents wait_seconds (default 180, range 30-900) and its constraint about host call timeouts, but url and browser are never explained beyond what their bare names imply, leaving a gap for a 3-parameter tool.

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?

Opens with a specific verb+resource: sign in once for a site in a browser the tool opens, and keep that login. It explicitly distinguishes itself from the browser-session-copying alternative (grab_site) by stating nothing is copied from the user's own browser, so an agent can route correctly without opening schemas.

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?

States exactly when to use it: past a login wall when the user has no session worth copying or refuses to have one read. It also covers the re-run condition (a kept login is not refreshed, so near expiry the user must run login_signin again), which is a rare and useful lifecycle rule.

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

Deploy Server