Models, tools, and MCP
Connect model providers and external capabilities without confusing the local runtime with the optional Cloud control plane.
iPolloWork can work with model providers, Skills, plugins, MCP servers, and browser automation. These are distinct extension points. Model credentials select inference. Skills and plugins shape reusable behavior. MCP adds a remote or local tool surface.
A model endpoint, reusable instruction, tool server, and browser session have different security and lifecycle rules.
How the model is selected
Connects an account or key to a model endpoint; credentials stay out of prompts and source control.
Cloud policy can manage shared model access without exposing the secret to a local project.
How work is shaped
Reusable instructions and local capability patterns for an intended job.
Packaged capability that can be related to configuration and marketplace access.
How a task reaches another service
A local or remote tool surface with explicit authentication and tool semantics.
A visible task surface that needs its own target, permissions, and review.
Connect a model provider
Use the provider configuration that matches the model endpoint. The project supports ChatGPT sign-in, Anthropic keys, and custom OpenAI-compatible endpoints through its documented connection flows. Keep credentials outside prompts and source control.
When a team uses iPolloCloud, a managed provider can be shared by organization policy. A local-only workspace can instead use its own provider configuration.
Before connecting a provider, identify whether the task needs a local personal credential, a team-managed provider, or a custom OpenAI-compatible endpoint. Then run a small known-safe request and confirm the selected model is reported by the client. Provider setup proves inference access; it does not automatically grant a new tool or workspace permission.
Add an MCP server
Before adding an MCP connection, answer three questions:
- What task needs the tool?
- What data and actions will the server expose?
- Which session or team should be allowed to use it?
The goal is not to install every available server. Add a concrete capability, verify its tool list, and keep authentication and access ownership clear.
For OAuth-capable remote MCP clients, the hosted iPolloWork Connect path uses organization-scoped authorization. A client opens the browser authorization flow, a person chooses the organization, and the client stores a scoped result. For a local MCP server, the workspace configuration and local approval boundary remain the source of truth.
A successful connection screen is not the same thing as a usable, correctly scoped tool.
- 01State the job
Describe one outcome that requires the provider, Skill, plugin, MCP server, or browser target.
- 02Scope access
Choose the narrowest workspace, organization, OAuth, or credential scope required for that job.
- 03Inspect capability
Read the available model or tool list and confirm it matches the expected service.
- 04Exercise and review
Run one safe action, verify the visible effect, and remove the setup if it is no longer needed.
Validate the extension
- Run a small task that exercises one intended tool action.
- Confirm the task has the expected permission prompt or access boundary.
- Check that the session output explains what changed.
- Remove unused configurations instead of leaving broad credentials in a shared workspace.
For organization-managed providers, shared MCP connections, and policies, use the Cloud documentation in the iPolloWork repository. The website documentation here focuses on the local project workflow.
See Local Server reference for local extension routes and Control-plane resource map for organization-managed plugins, Skills, marketplaces, providers, and grants.