Skip to main content
Use this reference to find the MSPortal MCP tool for a job, see what permission it needs and learn whether it changes data. It is for API consumers and MSP staff who have already connected an AI client. If you have not, follow Connect your client first.

Before you start

  • Connect your client and approve access. See MCP Server.
  • Call get_current_user to check the connected user, tenant and company.
  • Your client receives only the tools that your server version, approved areas, role, company scope, integrations and client tool selection allow. A tool in this reference may not be in your session.
  • The catalog groups related operations into public tools, so full access stays under a 128-tool client limit.

Call a read tool

1

Pick the public tool

Find your operation in the tables below. The Public tool column is the name your client lists in tools/list. The Action / legacy name column is the value for request.action.
2

Send the action and its arguments

Call the query_* tool with request.action and request.arguments. For example, to list Planner items:
3

Check the result

Look for pagination and truncation fields in the response. One page is not the whole data set. Find record IDs with list or search tools. Do not invent IDs.
Each action has its own argument schema and access checks. Use the schema your connected server returns. Seeing a grouped tool does not grant every action in it.

Change data with a proposal

1

Request the change

Call the manage_* tool with the action and its arguments, without confirm. MSPortal returns a proposal, a confirmationId and an expiry. Nothing is saved.
2

Review the proposal

Check the preview, company, records and effects with the person who asked for the change.
3

Confirm the same action

After approval, call the same tool and action with confirm: true and the returned confirmationId inside request.arguments. For a manage_planner proposal with action create_planner_item:
4

Check the record

Open the new or changed record to confirm the result.
Do not resend changed values on a confirmation call. Request a new proposal to change the target or payload. A proposal expires after ten minutes.

Tool naming

  • query_* tools read related records or summaries, such as query_planner or query_projects.
  • manage_* tools stage and confirm related changes, such as manage_planner or manage_meeting_participants.
  • Standalone tools keep their names and original arguments, with no request wrapper. They are get_current_user, search_portal, submit_feedback, draft_compliance_notes and mark_notification_read.

Existing connections and legacy names

Legacy operation names are still accepted by tools/call with their original arguments and result shapes. Existing connections keep their OAuth grants and access limits. You do not need a new server URL or grant. Pending confirmations keep their original operation identity. A proposal can be confirmed through its legacy tool name or the matching grouped action, with the same user, client, expiry and replay checks. The compatibility aliases update_compliance_status and list_compliance_templates work when called directly but are not listed in tools/list. A confirmation created through an alias must keep using that alias.
tools/list now returns grouped names, not every legacy operation name. Cached legacy calls still work. Update any client tool-name allowlist to include the public tool names you need. A custom client that requires a legacy name in tools/list must update its discovery logic.

Read the access column

  • Read retrieves data and needs no proposal. The results still go to your connected client.
  • Write (confirm) stages a proposal. A proposal is not a saved record. Commit it with the confirmation call.
  • Immediate action runs with no proposal step. mark_notification_read changes your notification state. draft_compliance_notes generates output and does not save it.
  • Send feedback sends a feedback message to MSPortal at once. It is for MSP staff only and needs an explicit user request.
The module scopes below are a summary. You do not need to grant every scope. Read and write grants are separate. The Permissions column lists alternatives unless it says All. Staff-only gates and record-level checks apply to administrators too. A client-side tool allowlist cannot widen server access.

Core

Module scopes: companies.read, companies.write, goals.read, planner.read, projects.read, reports.read, tickets.read

Tickets

Module scopes: tickets.read, tickets.write

Ticket Templates

Module scopes: ticket_templates.write

Devices

Module scopes: devices.read, companies.read (industry insights)

Reporting

Module scopes: reports.read, reports.write

Analytics

Module scopes: analytics.read, companies.read, companies.write, training.read, users.read

Personal task lists

Module scopes: mcp.read, mcp.write These MSP staff-only actions use the existing MCP read or write grants and require no task-specific role permission. Use the schemas returned by your connection for the available actions and parameters. Ownership, company sharing and tenant boundaries are enforced when a change is committed. Private tasks can also be read by authorized task-list auditors in the portal. Scratch notes are not exposed by these tools. See Tasks and notes for the portal workflow.

Planner

Module scopes: planner.read, planner.write

Goals

Module scopes: goals.read, goals.write

Compliance

Module scopes: compliance.read, compliance.write

Meetings & Calendar

Module scopes: calendar.read, calendar.write

Security Awareness

Module scopes: training.read

Training

Module scopes: training.read, training.write

Budgets

Module scopes: budgets.read, budgets.write

Surveys

Module scopes: surveys.read, surveys.write

Automation

Module scopes: automation.read, automation.write

Users & Contacts

Module scopes: users.read, users.write

Microsoft 365 & Secure Score

Module scopes: m365.read

Backup

Module scopes: backup.read

Projects

Module scopes: projects.read, projects.write

Client Health

Module scopes: customer_success.read, devices.read, backup.read

Financials

Module scopes: financial.read

Integrations

Module scopes: integrations.read, integrations.write

Documentation

Module scopes: documentation.read, documentation.write

Onboarding

Module scopes: onboarding.read, onboarding.write

Technology Standards

Module scopes: standards.read, standards.write

Security

Module scopes: security.read

Broadcasts

Module scopes: broadcasts.read, broadcasts.write

Notifications

Module scopes: notifications.read, notifications.write

Dashboards

Module scopes: dashboards.read

User Directory

Module scopes: users.read

Frequently asked questions

The tables list operations, which are grouped into 114 public tools covering 359 operations in the full catalog. Some newer operations are not listed in these tables yet. Your deployed server, consent scopes, permissions, company access, integrations and client filters can reduce that set further. The reference is not a grant of access.
No. Tool results go to your connected client. submit_feedback is a separate sending action, is not marked read-only in the consolidated catalog, and needs an explicit request to send feedback.
No. Proposal tools stage a confirmation, but immediate actions run directly. Read the access column and exact tool description before authorizing a call.
A confirmation applies the staged proposal. If you want a different target or change, request a new proposal and review it. Do not reuse an old confirmation for a new request.
No. Some operations return after scheduling work. Verify the saved record, job status or provider result appropriate to that tool.
No. It is an alias for check definitions. Use list_compliance_run_templates for reusable run templates and resolve the appropriate records before starting a run.