How to Invite Your Repository Contributors to Preveo With an AI Agent

You've created a project and saved the first review. Now the people building the product need a way to see it.

If you're already working with a coding agent, you can ask it to help with that handoff. It can inspect available repository contributor information, resolve the matching Preveo project, and send invitations through MCP.

The useful part is skipping the manual copying between Git history and an invitation form. The part worth thinking through is who actually belongs on the recipient list.

Be specific about the people and the project

A request like this gives the agent a clear destination and an access level:

Invite this repository's current contributors to the Acme Store project in Preveo as Engineers. Use reliable available email addresses, skip bots and no-reply addresses, and tell me which contributors you couldn't identify confidently.

"Current contributors" may still need clarification. A repository can contain old commit authors, imported history, automated accounts, and people who contributed once several years ago.

If you already know the recipients, providing their addresses is simpler:

Invite alex@example.com and sam@example.com to the Acme Store project as Viewers.

Those are example addresses. In a real request, use the people you intend to invite.

Understand where the addresses come from

The invitation tool doesn't discover email addresses itself. The agent does that work first, using the repository information or authorized services available to it.

Git author information is one possible source. It can help identify a contributor, but an author address may be stale or may not be suitable for a project invitation. Some contributors deliberately use no-reply addresses.

When the available evidence is unclear, the agent should explain the gap and ask you for the right recipient. Guessing an address makes the rest of the automation less useful.

It should also distinguish between "no usable email found" and "person should not be invited." Those are different conclusions.

Choose the access level deliberately

Preveo's invitation tool uses these access values:

Role shown to people	MCP value
Viewer	View
Engineer	Edit
Owner	Delete

The Delete value represents the existing Owner permission. It can look surprising in an invitation request, so check the mapping before working directly with the tool.

You also need sufficient permission to offer that access. Edit or higher can invite Viewers and Engineers. Inviting an Owner requires Owner access. When an entity's access is controlled by its parent, invitations need to follow that controlling scope.

If your request leaves the access level out, the agent needs to resolve it before sending.

What the MCP call does

Once the project and recipients are clear, the agent can call send_access_invitations with the entity ID, access type, and email list.

The tool accepts up to 50 input addresses per call, normalizes and deduplicates them, and returns a result for each resulting address. Larger recipient lists need separate batches.

This sends actual invitation emails. It can invite someone who hasn't created a Preveo account yet, but it doesn't grant immediate access to the project.

A successful handoff should tell you which invitations were sent, which failed, and which requested people had no reliable address available. You shouldn't have to infer all of that from a single "done" message.

The recipient accepts the invitation

The email takes the recipient to the invitation details. They sign in, or create an account if needed, and explicitly accept using the matching verified email address.

Opening the link alone doesn't grant access.

Preveo checks the invitation again at acceptance, including whether the sender can still offer the permission. A pending invitation and an existing project member are different states, so keep them distinct when you check whether onboarding is complete.

The sender can cancel a pending invitation. The recipient can decline it. Neither action removes access the person already held independently.

Read failures before retrying

One address can fail while others succeed. A recipient may already have equal or stronger access, the sender may lack the required permission, or email delivery may fail.

Use the individual results to decide what to do next.

Repeated calls can reuse a pending invitation and send another email, subject to delivery limits. If a response is uncertain, inspect the current invitation state before retrying rather than sending the whole list again.

After the access step, send people the review context through your normal team communication: what changed, where to look, and which decision you need. An invitation gets them into the project; that context helps them contribute once they're there.

The Preveo MCP guide is the starting point for connecting your agent. For the first batch, a small, clearly identified group is a good way to make sure the handoff works the way you expect.