WORKING MACHINES GUIDE
MCP server list: choose agent-ready software by task
PUBLISHED AUGUST 29, 2026 / REVIEWED SEPTEMBER 2, 2026
An MCP server list is useful only when it helps an agent complete a real task safely. Start with the system of record and the smallest capability set: GitHub for repository work, Gmail for bounded email workflows, Google Calendar for scheduling, Slack for team communication, and CRM or issue-tracking software for customer and project context. Before installation, verify server provenance, authorization, permission scope, tool contracts, and how the result can be checked.
Use a task list, not a popularity list
Directories can help discover MCP servers, but popularity is not evidence that a server fits a particular workflow. Begin with a defined outcome such as investigating a production incident, preparing a customer follow-up, coordinating a release, or scheduling a reviewed meeting. Then identify the few systems of record that own the relevant data or action.
A useful selection is usually smaller than a general-purpose list. For example, incident triage may require Sentry, GitHub, Linear, and Slack; a sales follow-up may need HubSpot and Gmail; and a meeting workflow may need Google Calendar, Notion, and Linear. Add a provider only when it has a verified role in the work.
- Name the intended outcome
- Identify systems of record
- Separate reads from writes
- Choose the minimum scopes
- Define how success will be verified
Common MCP server categories
Engineering servers can provide repository, issue, deployment, and observability context. Communication servers can search bounded message or email histories and prepare approved updates. Productivity servers can expose calendars, documents, and task systems. Commerce, CRM, support, and analytics servers should be chosen only when the task needs those records and the organization has approved the relevant data path.
An application layer can present these capabilities through a common discovery and execution model. Working Machines uses Agent Apps to help compatible agents search a large catalog by outcome, inspect a specific action schema, select an authorized connection, and return a structured execution result.
- GitHub: repository and pull-request workflows
- Gmail: bounded thread search and draft preparation
- Google Calendar: availability and reviewed scheduling
- Slack: channel and thread context
- Linear or Jira: verified engineering work
- CRM: account and opportunity context
Check authorization before a tool call
A public listing does not tell you whether a server is safe to connect. Check who maintains it, where its source and documentation live, which transport it uses, and how users authorize it. A remote server should provide a clear authorization flow and bind access to the intended resource. Never put provider OAuth tokens, refresh tokens, API keys, or passwords into an MCP configuration or model prompt.
Provider credentials can stay behind a managed server boundary, but tool inputs and returned provider data may still enter the active model context. Use narrow searches, explicit named connections, bounded result sizes, and a model account whose privacy settings fit the workflow.
- Verified maintainer and documentation
- Supported transport and client compatibility
- OAuth or other explicit authorization
- Provider-native least-privilege scopes
- Clear write and destructive-action behavior
Verify work after execution
A tool response is evidence, not a guarantee that the business outcome happened. Confirm a provider-side object, stable identifier, canonical URL, state transition, or created artifact. For writing actions, require confirmation immediately before a financial, destructive, externally visible, or difficult-to-reverse change.
Treat this guide as a selection framework rather than a universal ranking. Server availability, provider features, and authorization requirements change frequently. Recheck the official documentation and the action contract before deployment or production use.
- Inspect the exact action schema
- Confirm the selected account
- Use idempotency for safe retries
- Store execution identifiers
- Revoke unused access
Primary references
The protocol and security guidance in this article is grounded in the following primary documentation.