--- sourceDocument: Brazil Enable AI sourceDocumentLink: https://www.servicenow.com/docs/r/intelligent-experiences Release : - brazil ft:locale : - en-US ft:publication_title : - Brazil Enable AI ft:clusterId : - platai bundleId : - platai workflow : - Platform --- # Creating tools # Creating tools for a Model Context Protocol server {#ariaid-title1} Release version: Brazil Updated September 10, 2026 ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete. ## Summary of Creating tools for a Model Context Protocol server This guide explains how ServiceNow customers can create tools for Model Context Protocol (MCP) servers to expose ServiceNow capabilities to MCP clients. Tools define the data and functionality that MCP clients can access and the actions they can perform on a ServiceNow instance. Show full answer Show less Tools can be created from various capabilities including Subflows, Actions, Knowledge Graph schemas, REST APIs, and AI skills (including custom skills built with AI Skill Kit). Each tool includes inputs that correspond to fields from the underlying capability, and only enabled inputs are exposed to clients. Every MCP server must have at least one tool, and tools must reside in the same application scope as their servers. Tool descriptions are critical as clients use them to understand what the tool does and when to call it, so clear, complete descriptions prevent misuse. ## Access and Security ServiceNow access controls such as ACLs, role-based permissions, and field-level security apply to tools just as they do to the underlying capabilities. MCP tools do not bypass any access controls. Tool calls execute under two possible identities: * **Human users:** The calls run with the authenticated user's ServiceNow identity, enforcing all layers of access control including roles, script-based ACLs, row and field security, and deny-unless-permitted defaults. * **Autonomous agents:** The calls run under an integration user account. Access depends on the integration user's assigned roles and separate tool-level ACLs. Both must permit access for successful execution. Proper configuration of the integration user account is essential to avoid failures or security risks. ## Tool-Level ACL Requirements The tool-level ACL configuration varies by tool type: * **AI skill tools:** Require an execute ACL and role masking on custom AI skills to prevent silent empty results that complicate troubleshooting. * **Subflow and Action tools:** Require an AI ACL to be usable as MCP tools. * **Knowledge Graph tools:** Enforce ACLs at the node level during graph traversal, meaning returned data depends on caller permissions. ## Creating Tools from Different Capabilities Specific procedures exist for creating MCP tools from different capability sources: * Subflows * Actions * Knowledge Graphs * REST APIs * AI skills (including generative AI skills) These tools enable MCP clients to interact with ServiceNow instances securely and efficiently. ## Additional Resources ServiceNow customers should also review related configurations such as creating AI ACLs for Subflows and Actions, checking compatibility, and setting up OAuth inbound integrations for MCP clients to ensure complete and secure tool integration. You can create tools from various tool categories to expose ServiceNow capabilities to Model Context Protocol (MCP) clients from MCP servers. ## MCP tools overview {#creating-tools-mcp-server__section_vjk_f5h_bkc} Tools define which functionality and data an MCP server exposes to clients and the actions that can be performed on an instance by MCP clients. You can create tools based on the following capabilities: * [Subflows](https://www.servicenow.com/docs/BYUks1UfemCjMPGdvYsKfg "Create a tool from a Subflow to expose it to Model Context Protocol (MCP) clients from an MCP Server Console.") * [Actions](https://www.servicenow.com/docs/_sZrBcxS8NDyQwe5TGtq2g "Create a tool from an Action to expose it to Model Context Protocol (MCP) clients from an MCP Server.") * [Knowledge Graph schemas](https://www.servicenow.com/docs/oi3PBa9TfhS2IfpQM196hQ "Create a tool from a Knowledge Graph to expose it to Model Context Protocol (MCP) clients from an MCP Server.") * [REST APIs](https://www.servicenow.com/docs/IgdxklYY6gMqzLFEst~TqQ "Use a REST API to create a tool and expose it to Model Context Protocol (MCP Server Console) clients from an MCP Server Console.") * [AI skills](https://www.servicenow.com/docs/aaTgHv0YicfVMnqZ2SQuxw "Create a tool from a generative AI skill to expose it to Model Context Protocol (MCP) clients from an MCP Server."), including custom skills created with AI Skill Kit {#creating-tools-mcp-server__ul_rct_fxh_bkc} Tools include inputs that correspond to the fields of the existing capability. Any inputs that are enabled for a tool are exposed to clients. Each server must include at least one tool, and tools must be in the same application scope as any servers that contain them. When clients receive a list of available tools from a server, they rely on tool descriptions to decide whether to call a tool and how to call it. Every tool description should answer two questions: what does this tool do and when should it be called. When creating tools, particularly REST API tools, make sure the description is clear and complete, otherwise clients may select the wrong tool for the job. Note: A tool can be used by multiple servers. Changes that you make to a tool's name, description, or enabled inputs apply to any servers that use the tool. Before editing a tool, review which servers it's associated with to determine the impact for every server. ## MCP tools access {#creating-tools-mcp-server__section_overview} Existing access control lists (ACLs), role-based permissions, and field-level security all apply to tool calls made through an MCP server. MCP servers and tools don't bypass any ServiceNow access controls applied to the capabilities that tools are based on. Evaluating ACL enforcement depends on who is calling a tool and which capability the tool is based on. If a caller lacks permission, tools can return an empty or incomplete result rather than an explicit authorization error so it's important to understand which type of enforcement applies to a given caller and tool type when troubleshooting unexpected results. MCP tool calls execute under one of two identities, which are evaluated differently: Human users : Tool calls execute under the authenticated user's own ServiceNow user identity. A user who can't read incident records in the platform can't retrieve them through an MCP tool either. All four layers of the standard access model apply: role-based access, contextual script-based ACLs, row- and field-level security, and deny-unless-permitted defaults. Autonomous agents : Tool calls execute under the identity of the integration user account rather than any individual end user's identity. What an agent can access is controlled by the integration user's roles and by the tool-level ACLs two layers, which are evaluated independently and both must permit the call for a tool to return data: * The integration user must hold the roles required for every tool the agent will call. Under-provisioning this account causes tool calls to fail while over-provisioning creates unnecessary risk. For more information about configuring this account, see [Create an OAuth inbound integration for an MCP client](https://www.servicenow.com/docs/0i1s5t58eC0Cb80bZ3Q7tA "Secure access to Model Context Protocol (MCP) servers on an instance by creating an OAuth inbound integration for each MCP client."). * Tool-level ACLs control whether execution is permitted at the level of the tool itself, independent of the integration user's roles. Configuration requirements differ by tool type. {#creating-tools-mcp-server__ul_jqm_bj3_bkc} ## ACL requirements for MCP tools {#creating-tools-mcp-server__section_tool_type_table} The configuration required for tool-level enforcement depends on which capability the tool is built from. {#creating-tools-mcp-server__table_acl_by_tool_type__entry__2} | Tool type | ACL configuration | |-|-| | AI skill tools | An execute ACL and role masking is required for any custom AI skill to be used as a tool. Otherwise a tool can return empty results instead of an authorization error, which can be difficult to diagnose as a permissions issue rather than a data issue. For more information, see [Create a skill](https://www.servicenow.com/docs/~ak7kL0bW_JQBd9zdU1nAA "Create a custom skill for Otto. Custom skills extend the generative AI capabilities of Otto to fit your own use cases.") and [Create a tool from an AI skill](https://www.servicenow.com/docs/aaTgHv0YicfVMnqZ2SQuxw "Create a tool from a generative AI skill to expose it to Model Context Protocol (MCP) clients from an MCP Server."). | | Subflow and Action tools | An AI ACL is required for any Subflow or Action to be used as an MCP tool. For more information, see [Create an AI ACL for a Subflow or Action](https://www.servicenow.com/docs/nJq5BlA4vRa32QituU4eyg "Create the necessary AI Access Control List (ACL) for the component to be called externally.") and [Check the compatibility of a Subflow or Action](https://www.servicenow.com/docs/2q7xB0~HIuCCfEodsInjSw "After establishing the ACL, publish the component and check the compatibility staging table."). | | Knowledge Graph tools | ACL enforcement happens at the node level during every graph traversal. Two users or agents with different permissions issuing the identical query can receive different results, based on what each caller is permitted to see. For more information, see [Knowledge Graph](https://www.servicenow.com/docs/ODL8xlj~CIOUpVIu5TP1eg "The Knowledge Graph application, uses the structured and unstructured data from ServiceNow records, knowledge bases, and external sources to enhance the performance of ServiceNow Otto for Virtual Agent, AI agents, and generative AI skills.") and [Create a tool from a Knowledge Graph](https://www.servicenow.com/docs/oi3PBa9TfhS2IfpQM196hQ "Create a tool from a Knowledge Graph to expose it to Model Context Protocol (MCP) clients from an MCP Server."). | [Table 1. Tool-level ACL configuration by tool type] {#creating-tools-mcp-server__table_acl_by_tool_type} * **[Create a tool from a Subflow](https://www.servicenow.com/docs/BYUks1UfemCjMPGdvYsKfg)** Create a tool from a Subflow to expose it to Model Context Protocol (MCP) clients from an MCP Server Console. * **[Create a tool from an Action](https://www.servicenow.com/docs/_sZrBcxS8NDyQwe5TGtq2g)** Create a tool from an Action to expose it to Model Context Protocol (MCP) clients from an MCP Server. * **[Create a tool from a Knowledge Graph](https://www.servicenow.com/docs/oi3PBa9TfhS2IfpQM196hQ)** Create a tool from a Knowledge Graph to expose it to Model Context Protocol (MCP) clients from an MCP Server. * **[Create a tool from a REST API](https://www.servicenow.com/docs/IgdxklYY6gMqzLFEst~TqQ)** Use a REST API to create a tool and expose it to Model Context Protocol (MCP Server Console) clients from an MCP Server Console. * **[Create a tool from an AI skill](https://www.servicenow.com/docs/aaTgHv0YicfVMnqZ2SQuxw)** Create a tool from a generative AI skill to expose it to Model Context Protocol (MCP) clients from an MCP Server. **Related tasks** * [Create an AI ACL for a Subflow or Action](https://www.servicenow.com/docs/nJq5BlA4vRa32QituU4eyg "Create the necessary AI Access Control List (ACL) for the component to be called externally.") * [Check the compatibility of a Subflow or Action](https://www.servicenow.com/docs/2q7xB0~HIuCCfEodsInjSw "After establishing the ACL, publish the component and check the compatibility staging table.") * [Create an OAuth inbound integration for an MCP client](https://www.servicenow.com/docs/0i1s5t58eC0Cb80bZ3Q7tA "Secure access to Model Context Protocol (MCP) servers on an instance by creating an OAuth inbound integration for each MCP client.")