- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
36m ago
What is MCP Server Console?
MCP Server Console is where ServiceNow administrators build and manage MCP servers: collections of tools that external AI agents and MCP clients can discover and call. Each server is a curated catalog of capabilities you choose to expose, such as the ability to look up an incident, summarize a case, or trigger a workflow. This article covers how to design those tools well, starting with the most important decision you'll make: what the tool should actually be built from, and why.
If you're new to building MCP servers on ServiceNow, there's a very natural instinct that leads almost everyone astray on their first attempt: starting with the building blocks instead of the job.
This applies whether the tool is being called by a fully autonomous agent working through a multi-step process on its own, or by Claude in the middle of an ordinary chat conversation. The shape of the job still comes first either way, though as you'll see below, who's in the loop changes how much certain mistakes cost.
Before you start: You'll need the sn_mcp_server.tools_admin role to create and configure tools in MCP Server Console. If you don't see the configuration options described in this article, check with your instance administrator.
In this article:
Start with the job • Why REST doesn't transfer • Four-step method • Check what exists first • Match job to tool type • Server scoping • Best practices by tool type • Adding a UI to a tool • Keep the catalog lean • ITSM example • Pre-publish checklist
❓ Start with the job, not the tool
You open MCP Server Console, you see the tool types available: Knowledge Graph, Scripted REST API, Subflows, Actions, and Now Assist Skills, and the first question that comes to mind is “which one of these should I use?”
That’s not the question to start with. The better first question is: what is the AI agent actually trying to get done?
What this feels like depends on who’s using it. For an autonomous agent running unattended, it shows up as slower responses and occasional wrong tool selections that nobody catches in real time. For someone chatting with Claude directly, it shows up as something more noticeable: Claude asking an unnecessary clarifying question, picking a similar but wrong tool, or taking longer than expected to respond. A crowded catalog isn’t just a behind-the-scenes performance issue in that case. It’s a worse conversation.
Why this distinction matters
This distinction matters more than it sounds like it should. Customers who skip it tend to land on the same default pattern: building one platform artifact per table operation, then exposing each one as its own tool. One subflow to create a case, one to classify it, one to assign it, one to close it. It feels logical, because that’s how database schemas and integration APIs are organized. But ServiceNow’s own platform guidance already warns against this pattern: flows and subflows should be short, modular, reusable units of work, not thin wrappers around individual table operations. When you build artifacts that way and then expose them through MCP, the model inherits the problem — a flat list of near-identical tools it has to call in the right order to accomplish anything useful.
🔄 Why the REST API instinct doesn’t transfer
A REST API is designed for human developers who read the documentation once, learn the required sequence of calls, and write code that calls them correctly every time. An MCP tool isn’t used that way.
The AI model reads each tool’s name and description, and on its own, turn by turn, decides what to call next based on the conversation. It doesn’t know, the way a developer would, that create_case has to be called before assign_case, or that the output of one call only makes sense in the context of the next.
|
REST API DESIGN A developer reads the docs once, learns the sequence, and writes code that calls operations in the right order every time. The developer is the orchestrator. |
MCP TOOL DESIGN The AI model reads tool descriptions and decides what to call next. It doesn’t know the required sequence. The tool design has to make each call self-contained and unambiguous. |
✓ Key Takeaway: If your tool surface is four narrow operations that only work correctly in a specific order, you’re handing the model a flat list of choices and hoping it reconstructs the right sequence. The fix isn’t a smarter model — it’s a different design approach.
⚙️ The four-step method
Before reaching for a tool type, run through this exercise, similar to how you’d use pseudo-code to develop an app or solution:
Explain it the way you’d explain it to a coworker. No technical jargon, no database operations — just what the agent is trying to accomplish.
Not platform operations — the natural units of work. “Log and route” is one step, not three, because the routing logic is part of the same job as the logging.
For each step, ask: is this a lookup, an action, a known API call, or AI-generated content? The answer points directly at the right tool type.
Wrap only what each step needs into a tool, then group related tools into a domain-scoped server covering the related use cases they belong to.
Example: “Log a customer complaint and get it to the right team”
Walking through the method: this is one step, not several, because “log and route” is a single unit of work from the agent’s point of view. It’s a process with its own decision logic (which team gets it), so the right platform artifact is a subflow. The subflow takes the complaint as input, runs creation, classification, and routing logic, and returns one result: the case number and the team it went to. If a subflow like this already exists on your instance, expose it. If not, build it first in Flow Designer around the complete job, then expose it. One well-named tool — log_and_route_complaint — backed by one well-designed subflow, beats three or four narrow ones every time.
✅ Check what you’ve already built before you build anything new
This is the fastest shortcut in the entire process, and it’s easy to skip because it doesn’t feel like “designing” anything. Before building anything new, check two places.
These ship with curated, ready-to-use tools for common use cases. The tool you need may already exist with no setup required.
Look for existing artifacts before building from scratch:
- An existing Scripted REST API or Integration Hub spoke doing this work? Wrap it.
- An existing Flow Designer subflow or action doing this business logic? Expose it as the tool.
- An existing Now Assist Skill summarizing or drafting this kind of content? Use it.
- Existing Knowledge Graph schema covering these relationships? Query it.
If something already exists, in either place, you’re mostly done. The remaining work is usually just writing a clear description so the agent knows when to reach for the tool, and turning on the right access.
What makes a good tool description?
A clear description answers three things: what the tool does, what input it needs, and when the agent should reach for it over a similar tool.
Weak: “Use this tool to summarize a case.”
Strong: “Use this tool to generate a plain-language summary of a CSM case record, including the customer issue, steps taken, and current status. Call this when the user asks to summarize, recap, or get an overview of a specific case.”
⚠ One thing that trips up first-time builders:
Subflows are blocked from AI consumption by default. Each one has to be explicitly enabled before it can be exposed as an MCP tool — this is a deliberate security control, not a bug. If you’ve built the subflow and it’s not showing up as available, this is usually why. For more information on setting this ACL see the Subflow product documentation on Community.
🔄 Matching the job to the right tool type
If nothing exists yet, here’s how to recognize which tool type fits:
| If the ask sounds like… | Reach for… |
|---|---|
| “How are these connected?” / “What depends on this?” | Knowledge Graph |
| “Submit and route” / “Trigger a process” / “Get approval” | Subflow |
| “Do this one thing” / “Run this single operation” / “Reuse this atomic step” | Action |
| “Create, update, or look up a specific record” | Scripted REST API |
| “Summarize this” / “Draft this” / “Classify this” | Now Assist Skill |
You don’t have to choose only one tool type per server
The matching table above is for picking the right tool type one step at a time, not for picking one tool type for an entire use case. A single server typically mixes several tool types, each handling the piece it’s actually good at.
Example — case intake and triage: A realistic tool catalog might include a Knowledge Graph tool to look up the customer’s account relationships, related contacts, and owned assets; a Now Assist Skill to summarize the incoming complaint; a Subflow to create the case and route it to the right team; and a Scripted REST API tool to check an external billing system for account status. Four different tools, one server, one coherent use case.
Skill and Subflow aren’t always competing options
A Skill can be invoked from inside a Subflow when a deterministic workflow needs an AI-generated step partway through. They sit at different layers. Don’t assume it’s either/or.
⚙️ Servers scoped to a domain, not a single use case
The mixing example above shows how multiple tool types work together within a single server. The next question is how many use cases live inside one server, and the answer is usually more than one.
ServiceNow’s pre-built domain servers are scoped to a product area — ITSM, ITOM, CSM — not to a single use case. A CSM server, for example, typically covers case intake, case triage, escalation, and knowledge lookup together, since these are different jobs but the same domain: they operate on related objects (cases, customers, knowledge articles), need similar permissions, and get used together constantly in real conversations.
This matches a broader pattern in MCP server design: a well-scoped server serves one functional domain and completes meaningful units of work within it. A server scoped to exactly one use case is often too narrow in practice, since most real workflows end up needing a sibling use case in the same breath, and a too-narrow server just forces a customer to connect to multiple servers to do one coherent job.
A useful signal for sizing a server
- 5 to 8 tools: comfortable target
- 8 to 12 tools: still reasonable
- More than 15 tools: the domain has grown wide enough to consider splitting into two servers
💡 Best practices by tool type
Every tool in MCP Server Console wraps one underlying artifact: one Subflow, one Action, one Scripted REST endpoint, one Knowledge Graph schema, one Now Assist Skill. The tool itself is a thin layer — a name, a description, and the inputs the agent uses to call the underlying artifact. Getting the tool right means getting the artifact right first.
Subflows should be short, modular, reusable units of work with defined inputs and outputs. A subflow is called with variable input, runs a sequence of actions, and returns specific outputs to whatever called it — which maps exactly onto what an MCP tool call needs.
The design mistake to avoid is building a subflow around platform operations rather than around the job the agent is trying to do. A subflow that creates a record, a subflow that classifies a record, and a subflow that assigns a record are three platform operations. But “log a customer complaint and get it to the right team” is one job. If you expose three separate subflows because the underlying operations are separate, the agent has to call all three in the right order — work that belongs inside a single well-designed subflow, not in the agent’s reasoning loop.
A well-designed subflow takes the inputs the agent can provide, runs the logic that belongs on the platform, and returns one useful result. Notification, survey closure, follow-up tasks are separate concerns and belong in separate subflows if they need to be MCP-callable at all.
⚠ Side effects in autonomous workflows: A subflow that bundles a visible action (logging a case) with an invisible side effect (sending a customer email) removes the agent’s ability to stop between them. If someone is chatting with Claude and asks to log a complaint, they likely expect to review the draft notification before it goes out. Keep side effects in their own subflow so the agent, or the person, can choose whether to invoke them.
A Flow Designer Action, built in Action Designer, is the smallest reusable building block in Workflow Studio. This is distinct from other things on the platform called “action” — UI Actions, business rule script actions, and catalog task actions are different constructs. The Action described here is the one you build in Flow Designer’s Action Designer.
Where a Subflow orchestrates a sequence of steps, an Action performs a single atomic operation: one Script step, one REST call, one record operation. Actions are designed to be called from inside flows and subflows, reused across multiple workflows without duplicating logic.
As an MCP tool, an Action is the right choice when the operation the agent needs to perform is genuinely a single, discrete step with no sequencing logic around it. If the job requires multiple steps, use a Subflow. If the job is one atomic operation that needs to be reusable, available as a governed tool, and callable directly by the agent without invoking a wider workflow, use an Action.
What a well-designed Action tool looks like
The platform’s own guidance for Actions is straightforward: an Action should do one thing, have clear inputs, and return clear outputs. Those outputs populate data values that can be used by other flows, subflows, and actions. That same principle applies when an Action is exposed as an MCP tool: the agent provides inputs, the Action runs its single operation, and the agent gets a result back it can immediately use.
The platform’s own guidance for Actions is straightforward: an Action should do one thing, have clear inputs, and return clear outputs. Those outputs populate data values that can be used by other flows, subflows, and actions. That same principle applies when an Action is exposed as an MCP tool: the agent provides inputs, the Action runs its single operation, and the agent gets a result back it can immediately use.
A few things to get right when designing an Action for MCP exposure:
- Keep the scope genuinely atomic. An Action that creates a record, sends a notification, and updates a related record is no longer atomic — it’s a Subflow that hasn’t been built as one. If you find yourself adding multiple Script steps or multiple operations, consider whether a Subflow is the right construct instead.
- Define explicit inputs and outputs. The agent’s ability to call the Action correctly depends on inputs being well-defined and outputs being specific enough to be useful. Vague or optional inputs force the model to guess.
- Use Actions for custom logic that core steps don’t cover. The platform ships many core Actions (Create Record, Update Record, Send Email, and more). Build a custom Action when those genuinely don’t cover the operation you need.
- Be aware of the human intervention exclusion. MCP Server Console automatically excludes flows and actions that require human intervention or wait steps. If an Action includes a Wait for Condition step or any approval logic, it will not be eligible for MCP exposure.
⚠ Same default as Subflows: Actions are blocked from AI consumption by default and must be explicitly enabled before they can be exposed as MCP tools. See the Actions product documentation for the specific enablement step.
Action vs. Subflow: the practical test
Does the job require sequencing, conditionals, or multiple operations the agent might want to invoke in different combinations? If yes, build a Subflow. If the job is one operation, reused in multiple places, with no sequencing logic required, build an Action.
Our guidance for Scripted REST APIs is to start with a specific use case and design the endpoint around what that use case actually needs: clear inputs, clear outputs, and a response payload shaped for the consumer. When the consumer is an AI agent, that principle applies directly — the endpoint should return the fields that answer the question the agent will ask, not everything the underlying table happens to have.
The design mistake to avoid: building an endpoint shaped around what’s easy to query rather than what’s useful to return. An endpoint that takes a case number and returns the full case record with every related contact, every work note, and every attachment was probably designed for a UI or a dashboard. An agent asking for case status doesn’t need all of that, and everything extra costs context window space and can confuse the model about what to look at.
A well-designed endpoint is built around a specific question: what are the key details of this case right now? It takes a case number, returns current state, assigned team, and last update, and leaves everything else out. If a different question needs more, that’s a different endpoint and a different tool.
Supported HTTP methods
MCP Server Console supports GET, POST, and PUT methods for Scripted REST tools. If your endpoint uses DELETE, it cannot be exposed as an MCP tool in the current release.
🔗 Scripted REST API good practices — product documentation | Jessems.com — Scripted REST API Best Practices in ServiceNow
Knowledge Graph gives AI agents relationship-aware access to live instance data. Rather than returning records that match a query string, it traverses a semantic graph of how things connect: people to roles to org structures, assets to services to CIs, processes to tasks to approvals. This is the right tool type when the agent’s job is understanding how things relate, not just retrieving a specific record.
When you configure a Knowledge Graph tool in MCP Server Console, the core decision is which schema to select. ServiceNow ships several schemas out of the box, each covering a different slice of the instance’s relationship graph. The schema you select determines what relationships and entities the tool can reason about.
Key decision 1 — which schema: ServiceNow ships several schemas out of the box. Enterprise Graph is the broadest option.
Enterprise Graph: two modes
Enterprise Graph (regular): searches across all tables, prioritizing tables included in a tag you configure in the consuming app. Right choice when the use case is genuinely broad or when answers may come from more than 50 tables.
Enterprise Graph (Small): limits search entirely to tables included in the tag you configure. Tagging is mandatory. Better suited for operational use cases where the domain is known — faster, more focused, and less likely to surface results from unrelated parts of the instance. Limit is 50 tables. For most MCP tool use cases, start here.
Beyond Enterprise Graph, you can package any Knowledge Graph schema as a tool. If your instance has a domain-specific schema already configured for ITSM, HR, or CSM workflows, pointing a tool at that schema gives the agent a focused set of relationships relevant to that domain.
Key decision 2 — the tool description: Knowledge Graph tools respond to natural language questions, and the description shapes what the agent asks for. A description that says “use this tool to answer questions about IT infrastructure” produces different queries than one that says “use this tool to find the owner of a CI, the services that depend on it, and any open incidents assigned to those services.” Be explicit about what the schema covers and what kinds of questions it can answer.
🔗 Knowledge Graph — product documentation | Enterprise Graph — product documentation
A Now Assist Skill is a ServiceNow platform capability that uses a large language model to generate output: a summary, a draft email, a classification, a set of action recommendations. This is the right construct when the agent’s job requires AI-generated content rather than deterministic data retrieval or process execution.
Skills work differently from the other constructs because the platform enforces a 1:1 mapping: one skill, one tool. You can’t split a skill across multiple tools and you can’t bundle multiple skills into one tool.
OOB skills
ServiceNow ships a growing catalog of OOB skills already designed around specific AI jobs. Incident Summarization, Case Summary, Generate Email, Sentiment Analysis, and others each do one well-defined thing. For most use cases, start here first. OOB skills are maintained by ServiceNow, work within the platform’s security and governance model, and require no custom prompt engineering.
The design work for OOB skills is at the catalog level: which skills belong in this server, and are the tool descriptions specific enough that the agent reaches for the right one? Case Summary and Incident Summarization can look similar to a model if both descriptions just say “summarize a record.” Each tool description needs to be specific about what record type the skill operates on, what it returns, and when to use it over a similar skill. That specificity is the design work, not the skill configuration itself.
Custom skills with Now Assist Skill Kit
Start with OOB skills. ServiceNow ships a growing catalog of OOB skills — Incident Summarization, Case Summary, Generate Email, Sentiment Analysis, and others — each doing one well-defined thing. OOB skills are maintained by ServiceNow, work within the platform’s security and governance model, and require no custom prompt engineering. The design work for OOB skills is at the catalog level: which skills belong in this server, and are the tool descriptions specific enough that the agent reaches for the right one?
Custom skills with Now Assist Skill Kit (NASK)
NASK is for cases that OOB skills don’t cover. Start with OOB capabilities first, try the configuration options in Now Assist Admin, and reach for NASK only when those are genuinely insufficient. Three principles for custom skill design carry directly into MCP:
- One skill, one job. If you find yourself writing a skill that summarizes a case, drafts a reply, and classifies urgency in one prompt, that’s three jobs. Build three skills and expose them as three tools.
- Provide the right context, not all the context. A summarization skill needs the relevant case fields. It doesn’t need every field on the record.
- Test with real data before exposing as a tool. NASK includes prompt testing and evaluation tools. Use them before adding the skill to a server catalog.
On tool descriptions for both OOB and custom skills: Write the description to answer three questions — what does this skill do, what record type or input does it operate on, and when should the agent use this skill versus a similar one in the same catalog. Vague descriptions produce ambiguous tool selection. Specific descriptions produce reliable ones.
🔗 Now Assist Skill support in MCP Server Console | Now Assist Skill Kit prompt development — product documentation
What this means in practice
The platform’s own principles for each construct give you the answer: a well-designed subflow has clear inputs, runs a coherent sequence of actions, and produces a specific output. A well-designed endpoint is shaped around what its consumer actually needs. A well-scoped Knowledge Graph tool points at the right schema and has a description that focuses the agent’s questions. A well-selected skill catalog includes exactly the skills the domain needs with descriptions specific enough to distinguish them.
✓ Key Takeaway: If the artifact already follows platform design principles — clear inputs, coherent sequence, specific output — it will make a good MCP tool. If it doesn’t, exposing it through MCP Server Console won’t fix it. It’ll just expose the same problems to a model that doesn’t know how to work around them the way a human developer would.
💻 Adding a user interface to a tool
The standard MCP tool model is text in, text out. A client sends a request, the tool executes, and a text response comes back. That works well for discrete operations: looking up an incident, summarizing a case, checking assignment group. It breaks down when the workflow demands rich interaction.
Service Catalog request forms need field validation, conditional logic, and multi-step input. Approval flows present structured choices across multiple fields. Configuration interfaces expose tables, dropdowns, and nested relationships. None of these translate adequately into a plain text response in a chat window. A user working in Claude or Copilot should be able to interact with a full ServiceNow form without switching to the portal to complete it.
MCP Apps is the mechanism for this. It is an official extension to the Model Context Protocol (stable since January 2026, supported by Claude, ChatGPT, VS Code, and other compliant clients). ServiceNow added support in Zurich patch 9 and Australia patch 2 via MCP Server Console (sn_mcp_server) v1.6.
An MCP App is an HTML file registered in MCP Server Console before the tool is created. When the tool is called, the client fetches the HTML and renders it in a sandboxed iFrame inline in the conversation. Authentication passes through the existing OAuth session established during the MCP handshake, so no additional login is required. The iFrame sandbox enforces origin isolation, preventing the projected application from accessing the host client’s DOM or storage.
Any tool type supports an attached App: Subflow, Scripted REST, Knowledge Graph, Skill, or Action. The App is a presentation layer on top of the underlying artifact, not a replacement for it. The same tool that returns a text confirmation can also render a full ServiceNow form the user completes in one interaction, with the form submission triggering the underlying Subflow or Scripted REST call.
The clearest signal for MCP Apps is when a text back-and-forth exchange would be needed to collect structured inputs. Instead of the agent asking a series of questions to gather the fields needed for a Service Catalog request, the server projects the form directly. The user fills it out once and submits. One interaction, complete inputs, no approximation.
Other good fits: approval widgets where the user needs to review structured fields before deciding, configuration interfaces with conditional logic, and any workflow where the full fidelity of a ServiceNow UI component is genuinely required rather than a nicety.
Do not use it when plain text is sufficient. A tool that returns a case number, a status string, or a summarized paragraph does not need a UI layer. The HTML build and iFrame configuration add real complexity. The App should earn its place.
Think carefully about tool visibility
When a tool has an App attached, you choose whether it is visible to the model, to the UI, or both. This is a design decision with real consequences for how the model behaves and how much context the tool consumes.
Visible to both (default): The model can call the tool, and the App renders when it does. Right for most cases where the agent is deciding to surface the UI based on the user’s request.
App-only visibility: Hides the tool from the model entirely. Use this for internal UI controls: refresh buttons, pagination, form submissions, drill-down actions. Keeping them app-only prevents the model from treating UI controls as operational tools, keeps the catalog cleaner, and reduces context load.
The description field and client support
The description you write for an MCP App is exposed to the AI client to decide when to call it, the same as every other tool description in this article. Write it to answer what the App shows, what the user does with it, and when the agent should surface it rather than returning a text response.
MCP Apps requires a client that renders iFrames. A client that does not support the extension ignores the UI resource and returns the text result instead, so the tool still works without the App. Confirm that the clients connecting to your server support MCP Apps before building one.
💡 Keep your tool catalog lean
When you connect an MCP client to a server, every tool in that server’s catalog gets sent to the AI model before it reads the first word of your question. The model has to process all of those tool definitions just to figure out which one it needs. Think of it like handing someone a manual for every tool in a workshop before asking them to fix one thing: most of it isn’t relevant, but they still have to look through it.
A catalog with too many tools, or tools with long overlapping descriptions, makes this harder. The model spends more of its available attention on tool definitions and less on the actual task. The Model Context Protocol’s own documentation names this as one of the main scaling challenges of MCP: tool definitions that fill the context window before the model has even read the user’s message.
What a crowded catalog feels like to the user
- Autonomous agent: slower responses and occasional wrong tool selections that nobody catches in real time
- Chat with Claude: Claude asking an unnecessary clarifying question, picking a similar but wrong tool, or taking longer than expected to respond — a worse conversation, not just a behind-the-scenes performance issue
A few habits help keep the catalog lean. Group tools by the job they support, so an agent only sees tools relevant to what it’s working on. Keep each tool’s inputs to what the job actually needs, rather than including every field the underlying record or API exposes. And when in doubt, a smaller set of well-scoped tools performs more reliably than a large set of narrow ones, as long as each tool still returns a complete, useful result.
A few habits that help:
- Group tools by the job they support, so an agent only sees tools relevant to what it’s working on.
- Keep each tool’s inputs to what the job actually needs, rather than including every field the underlying record or API exposes.
- A smaller set of well-scoped tools performs more reliably than a large set of narrow ones, as long as each tool still returns a complete, useful result.
Context cost isn’t just about tool count
What drives context cost is two things: how many tools are in the catalog, and how large each tool’s definition is. A server with five Scripted REST tools, each with a verbose schema and overlapping descriptions, can cost more context than a server with one well-designed Subflow tool that does the same work. A single Knowledge Graph tool can often replace several narrower lookup tools entirely. The goal is a catalog where every tool earns its place — not just a short one.
🤖 What this looks like in practice: ITSM
ServiceNow’s pre-built ITSM server ships with five tools covering core incident operations: retrieving incident details, modifying incidents, looking up users and assignment groups, and searching for similar records semantically. All five are deterministic Scripted REST tools. This is the right starting point for any ITSM use case — no build time required, governed out of the box.
Three paths from there:
Once you have the pre-built server connected, there are three ways to extend it, and the right one depends on what you need:
If the additional capability is in the same ITSM domain, serves the same audience, and fits alongside the existing five tools, you can add tools directly to the pre-built server. A custom Now Assist Skill for incident summarization, or a Subflow for incident escalation, could sit alongside the existing Scripted REST tools. One server, one connection, one authentication flow.
If the use case is scoped differently from core incident operations — a purpose-built triage workflow, a problem management process, or a use case that needs different access controls — build a separate custom server. This keeps the pre-built server clean and governed independently from your custom tooling.
When a custom server makes the most sense
A custom server is the right choice, rather than extending the pre-built server, when:
- You need tools that don’t belong in a general-purpose ITSM catalog, such as a triage workflow specific to your organization’s escalation policies
- You need different access controls — the custom tools should only be available to certain agents or clients
- You want to keep pre-built and custom-built tools governed and classified separately
- The use case extends beyond incident into problem, change, or request
MCP clients support multiple server connections simultaneously. A user connecting to both the pre-built ITSM server and a custom triage server authenticates to each once via OAuth. After that, tools from both servers are available in the same conversation without additional friction. Claude decides which tool to call based on the question, regardless of which server it comes from.
The practical benefit: the pre-built server handles incident record operations, the custom server handles workflow execution and AI reasoning, and the user doesn’t need to think about which server does what.
A realistic custom ITSM triage server alongside the pre-built one
Five tools on the custom triage server:
- summarize_incident (Now Assist Skill) — AI-generated plain language summary for triage reasoning
- get_ci_owner_and_dependencies (Knowledge Graph, Enterprise Graph Small) — relationship context the pre-built server doesn’t cover
- classify_and_assign_incident (Subflow) — execute the triage decision, setting priority, category, and assignment
- escalate_to_problem (Subflow) — create a linked problem record when a pattern is detected
- create_change_request (Subflow) — initiate a change if triage surfaces a configuration issue
Combined with the five on the pre-built ITSM server, the user has ten tools available in Claude — covering record operations, semantic search, AI summarization, relationship context, and process execution. Neither server alone does everything. Together they cover the complete triage workflow without either server becoming a catch-all.
[ IMAGE: Architecture diagram showing pre-built ITSM server + custom triage server connecting to Claude — itsm_dual_server_architecture.png ]
📋 Before you publish a new MCP tool, check:
|
1
|
Did I describe the job in plain language before picking a tool type? |
|
2
|
Did I check whether a pre-built domain-specific MCP Server I’m entitled to already does this? |
|
3
|
Did I check whether a Subflow, Scripted REST API, Skill, or Knowledge Graph schema already does this? |
|
4
|
Does this tool give the agent one complete result — not a fragment, not a hidden process? |
|
5
|
Does the tool only ask for the inputs it actually needs? |
|
6
|
Is this tool grouped into a server scoped to a coherent domain, covering the related use cases I’ll actually combine in practice? |
|
7
|
Is that server focused enough that an agent connecting to it doesn’t need to also connect to a second server just to finish one job? |
If yes to all seven, you’re ready to write a clear, specific description so the agent knows exactly when to reach for it.
Quick reference: tool types at a glance
| Tool type | Best for | Underlying artifact |
|---|---|---|
| Knowledge Graph | Relationship lookups, “how are these connected” | KG schema (e.g., Enterprise Graph Small) |
| Subflow | Process execution, routing, approvals | Flow Designer subflow |
| Action | Single atomic operations, reusable custom logic | Flow Designer Action (Action Designer) |
| Scripted REST API | Record lookups and updates, external system calls | Scripted REST endpoint (GET, POST, PUT) |
| Now Assist Skill | Summarization, drafting, classification | OOB or NASK custom skill |
References
Model Context Protocol specification — Tools
AWS Prescriptive Guidance — MCP Tool Design Strategy
Model Context Protocol — Client Best Practices
MCP Apps specification
Jessems.com — Scripted REST API Best Practices in ServiceNow
For more on MCP Server Console — including authentication setup, server configuration, and common questions — see the MCP Server Console FAQ →
