Web Search Neo
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| web_infoB | Read the contract, the page, the console, the network, or search/browser state. Called with no arguments it returns the whole contract, including recipes and
common mistakes, so no external skill file is needed. Every result (dict
payloads) also carries the current local date/time and UTC-offset region
under the top-level |
| web_actionA | Execute 1-32 ordered objects in actions, each with required canonical action from web_info(topic='actions'); other keys are its parameters (url, session_id, ...). type/name/tool/command/op/operation/method aliases are accepted; prefer action. Read web_info action_schema before unfamiliar actions or validation errors. fill uses fields={CSS_selector: value}. Use a unique session_id per task/agent; never close another agent's tabs. summary='min' (or "summary": "min" in one action) returns short results. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 2 tools
The split is essentially execute vs. read/inspect: web_action performs ordered browser/search actions, while web_info reads contracts, page/console/network state, and browser/search status. The two responsibilities are mostly distinct, though web_info's broad 'read the page/search state' scope could overlap with results returned by web_action.
Both tools use a consistent web_<noun> convention: web_action and web_info. The convention is not verb_noun, but it is predictable and uniform across the set.
Two tools is below the typical 3-15 range and feels thin, even though web_action is an intentional multiplexer handling many canonical actions. The design avoids tool explosion, but pushes discovery and complexity into arguments and the contract-reading flow.
A generic action executor plus a contract/state reader can plausibly cover browser/search lifecycle operations, including session use and inspection. However the actual action surface is hidden behind runtime discovery via web_info, so completeness is less self-evident from the exposed tools.