How to Give Your Favorite AI Agent Live Google Search with PrismCrawl

An AI agent can write a launch plan, compare products, research competitors, or summarize a market in seconds. But unless it has a live search tool, it is still reasoning from whatever happens to be in its model context. Ask about a product released this morning or a search result in a specific country and the agent has two bad options: guess, or admit it cannot check.

PrismCrawl fixes that gap with a simple tool your agent can call. Send a search query to the API and get live Google or Bing results back as structured JSON: titles, snippets, URLs, ranks, and SERP features. No browser session, proxy rotation, CAPTCHA handling, or search-page parser in your agent loop.

This guide builds the integration once, then shows how to connect it to practically any agent.

The pattern works with almost any agent

Most agent systems expose tools in one of three ways:

Function calling: you describe a function and its arguments; the model decides when to call it.
MCP or another tool protocol: a small server exposes the search function to compatible clients.
Workflow actions: a visual agent builder sends an HTTP request and passes the response to the next step.

The adapter changes, but the underlying contract does not:

User question
    ↓
Agent decides it needs current information
    ↓
search_web({ query, country, language, freshness })
    ↓
PrismCrawl returns ranked, structured search results
    ↓
Agent compares sources and answers with links

That separation is useful. PrismCrawl handles search retrieval; your agent handles query planning, source selection, and synthesis.

Step 1: Create one small search wrapper

Create a PrismCrawl account, copy your API key from the dashboard, and store it in an environment variable. Do not put the key in a prompt, browser bundle, or source control.

Here is a compact TypeScript wrapper:

type SearchOptions = {
  query: string;
  country?: string;
  language?: string;
  freshness?: "day" | "week" | "month";
};

const freshnessFilters = {
  day: "qdr:d",
  week: "qdr:w",
  month: "qdr:m",
} as const;

export async function searchWeb({
  query,
  country = "us",
  language = "en-US",
  freshness,
}: SearchOptions) {
  const response = await fetch(
    "https://YOUR_PRISMCRAWL_BASE_URL/v1/google/search",
    {
      method: "POST",
      headers: {
        "content-type": "application/json",
        "x-api-key": process.env.PRISMCRAWL_API_KEY!,
      },
      body: JSON.stringify({
        query,
        html: false,
        gl: country,
        hl: language,
        tbs: freshness ? freshnessFilters[freshness] : null,
      }),
    },
  );

  const body = await response.json();

  if (!response.ok || !body.success) {
    throw new Error(body.error?.message ?? `Search failed (${response.status})`);
  }

  return {
    requestId: body.request_id,
    results: body.data.content.results.map((result: any) => ({
      rank: result.rank,
      type: result.type,
      title: result.title,
      url: result.url,
      snippet: result.snippet,
      source: result.source_name,
    })),
    features: body.data.content.serp_features,
    hasNextPage: body.data.content.has_next_page,
  };
}

The wrapper deliberately returns a smaller object than the full API response. Giving the model only fields it needs reduces context use and makes its behavior easier to test. Keep the request ID in your logs so a failed agent run can be traced later.

For all supported request controls and the complete response schema, use the PrismCrawl API reference.

Step 2: Describe the tool clearly

An agent chooses tools from their names, descriptions, and input schemas. A vague tool definition causes unnecessary searches and poor queries. A useful generic definition looks like this:

export const searchWebTool = {
  name: "search_web",
  description:
    "Search the live web with Google. Use for current, time-sensitive, " +
    "location-sensitive, or externally verifiable information. Returns " +
    "ranked results with titles, snippets, and source URLs.",
  inputSchema: {
    type: "object",
    additionalProperties: false,
    properties: {
      query: {
        type: "string",
        description: "A concise search-engine query, not the full user request.",
      },
      country: {
        type: "string",
        description: "Two-letter Google result-country code, such as us or gb.",
      },
      language: {
        type: "string",
        description: "Google interface language, such as en-US or fr.",
      },
      freshness: {
        type: "string",
        enum: ["day", "week", "month"],
      },
    },
    required: ["query"],
  },
};

Register that definition using your model provider or agent framework's custom-tool API, then route calls named search_web to the searchWeb function. In a visual builder, use the same fields as the inputs to an HTTP action.

The tool description matters as much as the code. It tells the agent both what the tool can do and when the extra network call is justified.

Step 3: Give the agent a search policy

Tool access alone does not produce good research. Add a short policy to the agent's system instructions:

Use search_web when the answer depends on current, changing, local, or
externally verifiable information. Break broad research tasks into focused
queries. Prefer primary and authoritative sources. Compare multiple sources
for consequential claims. Never claim that a snippet proves more than it says.
Include the source URL for factual claims derived from search results. If the
results are insufficient or conflict, say so. Do not exceed five searches for
one task unless the user asks for deeper research.

This policy solves several common agent failures at once: searching when it is unnecessary, putting an entire paragraph into the query box, trusting the first result blindly, and presenting a search snippet as if the full article had been read.

Search results are discovery data, not full-page evidence

This distinction is easy to miss. PrismCrawl gives the agent the live search-results page. A result's snippet is Google's preview of a source, not the complete source itself.

For many jobs, search data is enough:

Find the current top-ranking pages for a keyword.
Discover competitors, products, documentation, or recent coverage.
Track how rankings differ by country, language, or location.
Collect candidate URLs for a later extraction step.
Use titles and snippets to triage a large result set.

When an answer depends on details inside a page, use a second fetch or extraction tool after PrismCrawl identifies the best URLs. A strong research agent usually follows search → select → fetch → verify → answer, rather than treating one search response as the finished research product.

Step 4: Add guardrails before you make it autonomous

Agents can turn one innocent request into a long tool loop. Put the important limits in code, where the model cannot ignore them.

Set a search budget

Track calls per task or conversation and reject calls after a fixed limit. Five searches is a reasonable starting point for a normal research answer. Let users explicitly request a deeper run.

Cache duplicate queries

Normalize the query and search controls, then cache the response for an appropriate window. An agent that asks the same question twice should not spend two credits unless freshness requires it.

Retry selectively

Retry temporary service failures and rate limits with backoff. Do not retry invalid input, an invalid API key, or exhausted credits. PrismCrawl returns a request ID with responses; log it alongside the agent run.

Keep secrets outside the model

The agent should be able to invoke search_web, but it should never see the underlying API key. Execute the tool on your server and expose only validated arguments and sanitized results.

Validate location inputs

Search geography is not one setting. gl influences the result country, hl controls the interface language and can affect selection, while location or coordinates represent the searcher's location. If local rankings matter, expose the controls you actually support and test them intentionally. Our guide to Google search localization explains the layers in detail.

A practical example: a competitor-research agent

Suppose the user asks:

Find the leading invoicing tools for US freelancers, explain how they position themselves, and cite your sources.

A disciplined agent might make three focused calls:

{ "query": "best invoicing software for freelancers", "country": "us" }
{ "query": "freelance invoicing software pricing", "country": "us" }
{ "query": "freelancer invoicing app reviews", "country": "us", "freshness": "month" }

It can deduplicate domains, compare titles and snippets, choose promising primary pages and independent reviews, then fetch those pages if deeper claims are needed. The final answer links every source instead of presenting model memory as current research.

The same tool works for a coding agent checking current documentation, a sales agent finding recent company news, an SEO agent auditing rankings, or a shopping agent discovering products. Only the instructions and downstream processing change.

Why use a SERP API instead of giving the agent a browser?

A browser is essential when an agent must click, log in, fill a form, or interact with a JavaScript application. It is unnecessary overhead for a straightforward search.

Search pages also change frequently and defend themselves against automation. If every agent run launches a browser, you inherit browser infrastructure, proxy management, CAPTCHAs, parser maintenance, and a large amount of markup in the model context. A SERP API compresses that work into one predictable call and returns the result fields directly.

The best setup is often hybrid: use PrismCrawl for fast source discovery, a content fetcher for selected pages, and a browser only when the task truly requires interaction.

Make the first live search

The shortest path from a model with stale context to a useful research agent is one well-designed tool. Build the wrapper, register the schema, add a search policy, and enforce a small budget in code. The same PrismCrawl integration can then travel with you across models, frameworks, and agent builders.

Create a PrismCrawl account to get your API key, or open the API reference and test a live Google or Bing request first.

Frequently asked questions

Which AI agents can use PrismCrawl?

Any agent that can call an HTTP endpoint or invoke a custom function can use PrismCrawl. That includes hosted assistants, coding agents, agent frameworks, workflow tools, and custom applications. The provider-specific adapter may change; the search_web contract can stay the same.

Does PrismCrawl return full web page content?

PrismCrawl returns live Google or Bing search-result data, including titles, snippets, URLs, ranks, and SERP features. It helps an agent discover and rank sources. Fetching the full content of a result page is a separate step.

How do I stop an AI agent from making too many searches?

Set a per-task search budget in application code, return a clear error when the budget is reached, cache repeated queries, and instruct the agent to search only when current or externally verifiable information is required.