Skip to main content
Glama

ask_websearch

Research current facts, versions, pricing, releases, and open-source intelligence with live web search, returning a sourced, cited answer.

Instructions

OPT-IN web-search / OSINT research agent. Unlike every other ask_* tool (which is toolless and cannot browse), this one runs a model WITH live web search to research a question and return a sourced, cited answer — use it for current/'latest' facts, version/pricing/release lookups, who/what-is research, and open-source intelligence gathering. Pick the model with model: grok (grok-4.6 live search, the default — strong for current events, via the local grok CLI), a Claude model on your OAuth session — sonnet (claude-sonnet-5), opus48 (claude-opus-4-8), opus5, or fable — using native WebSearch/WebFetch, or gemini via the local agy CLI. All run on flat-plan sources (no per-token billing). Put any code/artifact the research is ABOUT in context. Returns a findings summary followed by a Sources: list. DISABLED by default: the operator must set ASK_FABLE_ALLOW_WEBSEARCH=1 (returns {"status":"disabled",...} otherwise). On grok and Claude the search-only boundary is a real tool gate; gemini is search-only for a different reason — agy's own headless permission policy denies page fetch, shell and file tools, and a denial aborts the turn, so that backend is told to use search_web only (use grok or a Claude model when the task needs page content). Requires the grok or agy CLI (for those models) or the Claude OAuth session (for the Claude models). Refuses tasks whose aim is genuinely harmful (attack development, de-anonymizing or surveilling a private individual); legitimate research on software, companies, CVEs, and public events is answered.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelNoWhich search-capable model runs the research. `grok` (grok-4.6 live search) is the default; `sonnet` / `opus48` / `opus5` / `fable` use Claude native WebSearch over the OAuth session; `gemini` uses the local `agy` CLI and is SEARCH-ONLY — agy's headless policy denies page fetch/shell/file tools and a denial aborts the turn, so that backend is told to use search_web only. Omit to use the ASK_FABLE_WEBSEARCH_MODEL default (grok).
contextNoOptional code, artifact, URL, or entity the research is ABOUT (e.g. a library, error text, CVE id, or organization).
trustedNoOperator-authorized. When true, the prohibited-use denylist runs in log-only mode: security vocabulary in the question AND in `context` is audited but does not block. Use for legitimate security-engineering work (PoC analysis, CVE research, binary hardening review) where the ask genuinely needs security terms. Takes effect ONLY when the operator has set ASK_FABLE_ALLOW_TRUSTED (env or config); otherwise the flag is ignored and the denylist still applies.
questionYesA web-search / OSINT research task — a question to research on the LIVE web (current facts, versions/pricing/releases, who/what-is, open-source intel).
context_refNoKey(s) of context saved with `context(op="write", …)` to pull in and prepend to `context` — paste a big context ONCE, reference it by key here. Missing keys are reported, not fatal.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.18.0
    • changedInput schema / properties / context_ref / description
      Previous value: -"Key(s) of context saved with `context_write` to pull in and prepend to `context` — paste a big context ONCE, reference it by key here. Missing keys are reported, not fatal."New value: +"Key(s) of context saved with `context(op=\"write\", …)` to pull in and prepend to `context` — paste a big context ONCE, reference it by key here. Missing keys are reported, not fatal."
  2. Addedv0.16.0

TDQS

A4.9/5.0
Behavior5/5

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

The description discloses substantial behavioral traits beyond the annotations: the tool is disabled by default and returns a status object unless ASK_FABLE_ALLOW_WEBSEARCH=1 is set; gemini is search-only due to agy's headless policy and a denial aborts the turn; the result format is a findings summary plus Sources list; and harmful tasks are refused. While annotations declare readOnlyHint=false and openWorldHint=true, the description adds the operational constraints and side-effect nuances that an agent needs.

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 and front-loaded with the core purpose, and every sentence carries useful information. However, it is a single long run-on paragraph with many parenthetical asides and some redundancy (e.g., gemini's search-only nature is explained both in the description and schema), which slightly hurts parseability. It earns high marks for content but not for concise structure.

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?

Given the tool's complexity — multiple backends, an opt-in configuration, CLI/OAuth requirements, and a refusal policy — the description covers all operational aspects an agent needs: prerequisites, model-specific behaviors, output format, disabled behavior, and safety restrictions. No output schema exists, but the description explicitly states the return shape, which is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches parameter meaning substantially. It explains which model is the default (grok), why gemini is search-only (agy policy denies page fetch and aborts on denial), how `context` is meant to hold the artifact being researched, and when `trusted` is honored (log-only denylist only when ASK_FABLE_ALLOW_TRUSTED is set). This goes well beyond the schema's own parameter descriptions.

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 opens by stating a precise verb+resource combination: an 'OPT-IN web-search / OSINT research agent' that runs a model with live web search and returns a sourced, cited answer. It explicitly distinguishes itself from every other ask_* tool by noting they are toolless and cannot browse, and enumerates concrete use cases (current facts, versions/pricing/releases, who/what-is, OSINT). This makes the tool's purpose unmistakable and clearly differentiated from its siblings.

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?

The description gives explicit when-to-use guidance: use for current/'latest' facts, version/pricing/release lookups, who/what-is research, and open-source intelligence. It also provides when-not-to-use and alternative selection: use grok or a Claude model when the task needs page content instead of gemini, and contrasts with all other toolless ask_* tools. The disabled-by-default note and required CLI/OAuth prerequisites further clarify invocation conditions.

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