Available Tools and Capabilities

The Xurrent MCP server exposes tools across the major Xurrent surfaces. Tools marked (write) change data in your instance; everything else is read-only.

What determines which tools you see

The tool list is not fixed. Three things shape it:

• Your credential's scope. A Personal Access Token needs the MCP scope with Tools, Resources, and Prompts. An OAuth sign-in requests the equivalent. See MCP Authentication.
• Your roles in Xurrent. The write tools additionally depend on what you may do in the account. Creating a problem needs the Problem Manager role on the account owning the service; drafting a knowledge article needs the corresponding knowledge rights.
• Your account's Sera AI configuration. Some tools are only offered where the relevant Sera AI version is in use.

If a tool you expect is missing, that is where to look first. Your client's tool list is the authoritative answer for your account.

What each tool can see

Most tools follow your roles. If you hold a Specialist role that sees every request in the UI, global_search, summarize_request, get_notes, list_records_by_ci and run_report return the same breadth through MCP.

Four tools are deliberately personal and ignore your role:

• list_active_requests: requests you raised or that were raised for you
• list_inbox, search_inbox and filter_inbox_records: assignments waiting on you

global_search is also personal when you ask for "my open requests" or "my withdrawn requests". A free-text search is not.

No tool lists or exports every request in the account. For a full corpus, such as bulk extraction, historical trend analysis, or feeding a dataset into another system, use the GraphQL API. For account-wide figures inside the conversation, use run_report.

Identity

• whoami: Returns the profile and account information of the authenticated user. Useful for confirming which account and identity the connection resolved to.

Cross-domain search

• global_search: Searches across requests, knowledge articles, request templates, problems, workflows, tasks, and people. The best starting point when you do not know which surface holds the record. Recognizes a request ID such as #704540 as a direct lookup.

Inbox and assignments

• list_inbox: Returns a prioritized list of assignments needing your action, which may include requests, problems, tasks, project tasks, and approvals.
• search_inbox: Searches your inbox for requests, tasks, and problems.
• filter_inbox_records: Filters inbox items by record type, status, impact, service, or team.

Requests

• list_active_requests: Lists active requests raised by you or on your behalf.
• summarize_request: Summarizes a request's status, recent updates, and next steps.
• search_request_template: Finds request templates, such as access requests or hardware provisioning, returning the template ID and any form fields.
• list_request_templates_by_service: Lists the request templates for a named service that you can apply in self service.
• start_request_from_template (write): Starts a request from an existing template, prefilling the form with the fields you supply.
• prepare_request (write): Creates a basic request when no suitable template exists. Use only when a template does not fit.
• create_request (write): Creates a request, either from a template or generically against a support domain. Team, service instance, and requested-for are resolved by name, and you are asked to choose when a name is ambiguous.
• update_request (write): Updates a request's subject, status, category, impact, team, member, requested-for, service instance, or completion reason. A note is required when moving a request to Completed or Waiting for Customer.

Notes

• get_notes: Retrieves all notes on a request, task, or problem you can access, oldest first.
• post_notes (write): Posts a note on a request, task, or problem. Notes are public by default, meaning visible to the requester. Internal, specialist-only notes are supported on requests only.

Knowledge

• search_knowledge_articles: Searches for knowledge articles, FAQs, or documentation.
• filter_knowledge_articles: Filters knowledge articles by service or last-updated date.
• list_knowledge_articles_by_service: Lists the knowledge articles for a named service.
• top_knowledge_articles: Lists the most-viewed articles of the past month that you can access.
• summarize_knowledge_article: Summarizes an article's key steps and applicable services.
• create_knowledge_article (write): Drafts an article on a service, at status Not Validated, for a Knowledge Manager to review.
• update_knowledge_article (write): Updates an article still awaiting review, for example to fold in what another request's resolution added.
• list_unvalidated_knowledge_articles: Lists the articles awaiting a Knowledge Manager's review on a given request's service.

Problems, tasks, and workflows

• summarize_problem: Summarizes a problem's status, recent updates, and next steps.
• create_problem (write): Creates a problem on a service. Requires the Problem Manager role on the account owning the service.
• update_problem (write): Updates a problem's subject, status, category, impact, service, team, or member. Moving it to Accepted, In Progress, or Solved assigns it to you. A note is required for Waiting for and Solved.
• summarize_task: Summarizes a task's status, recent updates, and next steps.
• update_task (write): Updates a task you have access to.
• summarize_project_task: Summarizes a project task's status, recent updates, and next steps.
• update_workflow (write): Updates a workflow you can access, mirroring the controls on the workflow form. Only fields you may write are changed.

Configuration items

• list_ci_by_service_instance: Lists the configuration items linked to a named service instance.
• list_records_by_ci: Lists open records of a chosen type linked to a specific CI, across all teams rather than only your inbox.
• blast_radius: Analyzes the impact of a CI failure, pivoting around the service instances that use the CI.

Boards, services, and broadcasts

• list_agile_board_items: Lists items on an agile board. Items may be requests, problems, tasks, or project tasks.
• service_availability: Checks the status and availability of services you can access.
• list_broadcasts: Lists the broadcasts currently active for you, including outage, maintenance, warning, and information notices.

Analytics

• find_report: Finds standard analytics reports matching a described need, such as "open problems per team". Returns ranked candidates with their group-by options and filters.
• run_report: Answers an analytics question with the actual numbers from a standard report, such as "open requests per team".
• open_report: Opens a matched report with the filters your question stated.

Example prompts

• "Show me everything in my inbox that's high impact."
• "Summarize request 1234 and tell me what's blocking it."
• "Find knowledge articles about VPN setup and summarize the top one."
• "Start a new request from the laptop replacement template."
• "Add an internal note to request 1234 with what I found in the logs."
• "Set request 1234 to waiting for customer and let them know we need the error screenshot."
• "Open a problem on the Email service for the recurring Outlook crashes and assign it to my team."
• "What breaks if the primary database server goes down?"
• "How many open requests does each team have?"
• "Are there any active outage broadcasts right now?"

Tool naming conventions

Tools follow a consistent verb_noun pattern, for example list_inbox, summarize_request, create_problem. The verbs map to action types: list, search, filter, find, summarize, create, start, prepare, update, post, open, and run. Anything prefixed with create, update, post, start, or prepare writes to your instance. That makes the surface predictable for both people and AI clients discovering what is available.

Related

See MCP Authentication for scopes, and Troubleshooting if tools are missing from your client.