- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
47m ago
What is AI Search as an MCP tool?
MCP Server Console now supports AI Search as a native tool type. Instead of building a custom tool to replicate search, you bind an MCP tool directly to an existing AI Search profile. The agent's queries stay scoped to whatever that profile covers, so every result is grounded in content your organization has already indexed and secured, not an open-ended search across the instance.
Demo How it works Search profiles Validate first Use cases Effective use Limitations Learn more
๐ฅ See it in action
โ๏ธ How it works
Creating the tool takes three steps: select AI Search as the tool category, choose the AI Search profile the tool should query, and save. The tool's name and description default from the profile, and you can edit both before publishing. Once the tool is added to a server, any connected agent can call it, within the scope the profile defines.
๐ What's a search profile?
A search profile is where the scope and tuning for a search experience lives: which search sources it draws from, plus synonyms, stop words, typo handling, Genius Results, and result improvement rules.
A profile has to be published before its settings take effect. When you bind an MCP tool to a profile, the tool inherits that profile's scope, the same way any other search application does when it references the profile.
Governance carries through
The tool respects the same access controls as any other AI Search surface. MCP calls honor the requesting user's authenticated session, including ACLs and runtime permission checks, through the existing token-validation system, so results stay scoped to what that user is authorized to see, not just what the profile targets.
๐ Validate your profile before you test the tool
Before pointing an MCP tool at a profile, confirm the profile itself returns what you expect using Search Preview. This separates two different failure points: a search profile that isn't returning the right results, versus an MCP tool or agent that isn't calling correctly.
Search Preview UI for AI Search ยท Search Preview admin tools
๐ก Example use cases
An agent asks, "Find knowledge articles related to VPN connectivity issues." The tool queries the bound profile and returns matching articles, the same underlying retrieval that powers AI Search elsewhere on the platform.
Bind a second tool to a profile scoped to Known Error articles instead of general knowledge content. An agent asks, "Is there a known error for intermittent VPN drops on the new client?" and gets back matches from that narrower, triage-specific content set.
Same tool type, different profile, different result set. The admin controls what an agent can search just by choosing which profile the tool points to.
โ Effectively using the tool
Whether an agent calls this tool at all, and calls the right one when you've bound more than one, comes down to three things: the tool's own description, the calling agent's system instructions, and how the tool sits next to others in the same catalog.
A vague description is the most common reason a tool goes unused.
Weak: "AI Search tool"
Better: "Search IT knowledge articles for troubleshooting content. Use when a user asks how to resolve a technical issue, error message, or configuration problem."
Even a well-described tool can go unused if the agent's own instructions don't point it there. This is a separate failure point from the tool description, and it's usually the one people check last.
Example instruction: "When a user asks about resolving a technical problem, check the IT Knowledge Search tool for documented guidance before answering from general knowledge. Only use Known Error Search when the user is asking whether something is a known, ongoing issue rather than requesting general troubleshooting help."
For Claude specifically, see Claude's tool use guide and prompt engineering overview. On the ServiceNow side, see Writing instructions for large language models.
The agent isn't evaluating this tool in isolation, it's choosing from everything available to it in that conversation. If several AI Search tools are bound to different profiles, each needs a name and description that's distinct enough that the agent isn't guessing between near-duplicates.
Weak catalog: "Search," "Search 2," "Knowledge Tool"
Better catalog: "IT Knowledge Search," "Known Error Search," "Catalog Item Search"
Each name in the better version signals its own scope on sight. The weak version forces the agent to open each tool's description just to tell them apart, which is exactly the kind of ambiguity that leads to the wrong tool getting called, or none at all.
โ ๏ธ Limitation: text-only output
The tool returns text, not images. If a knowledge article's answer lives in a screenshot, diagram, or chart, the tool won't return that image to the agent. It will, however, return a caption describing what's in the image, graph, or table, since supported attachment types are processed through image captioning before being made searchable as text. An agent can learn that a diagram shows, for example, a network topology with three VPN gateways, but it can't receive or display the diagram itself.
This only works for attachments that are indexed. An attachment sitting on a record but not included in the relevant indexed source won't be captioned or searchable at all, by this tool or by AI Search generally. If results seem to be missing content you expect, confirm the attachment is actually indexed before assuming the tool is at fault.
