- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
3 weeks 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.
📚 Learn more
- 758 Views
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report Inappropriate Content
Im testing the OOB MCP Server Console with Cursor client to retrieve knowledge articles through a MCP server's Search tool using an existing AI Search profile configured.
The flow works with admin user. However, a portal/end-user account fails with:
403 — User Not Authorized — Failed API level ACL Validation
I impersonated as a portal user and then Browser authenticated to get the MCP Client authenticate as portal user.
Both users connect through the same registered OAuth application using Authorization Code flow, with their own user authorization. When I impersonate the affected user in ServiceNow UI, the user can successfully search and access the knowledge content.
So far, I’ve confirmed success for admin user and failure for one portal user;
Could you help on:
What minimum roles or API ACL permissions are required for end users to invoke an OOB MCP Search tool?
Is this supported for users with only portal access (users without additional ServiceNow roles)?
Which endpoint or ACL should I inspect for this error?
My intended use case is end user self-service KB search through a MCP client, preserving each user’s existing knowledge access without granting administrative roles. Any guidance on the supported configuration would be appreciated.
Quick update: If I add the role sn_mcp_client.admin/ sn_mcp_client.viewer & sn_mcp_server.viewer to portal user, then the User is able to search the KB content from the MCP client (cursor). Not sure if this is a permission/configuration issue
