Permissions, plans and data

Plans

Plan	MCP access
FREE	Not available
BASIC	Read: find, read and summarize feedback
STARTUP and higher	Read and triage: also update and assign reports, manage tags and add internal comments

There's no add-on and no extra charge. The free trial includes MCP for the plan you pick.

On BASIC, your assistant only sees the read tools. If your team moves to a plan without MCP, connected assistants stop working until you upgrade again. Your connections stay listed under Connected apps.

Tool calls are rate limited per team, and everyone's assistants in the team share the limit. Normal use doesn't come close to it. A long job, like reading hundreds of reports one by one, can hit it for a minute. See "Rate limit exceeded".

What the assistant can see

The assistant signs in as you, for one team. It sees what your Ybug account can see in that team:

• the team's active projects you have access to (archived projects are left out)
• feedback in those projects: title, description, status, priority, type, tags, assignee id and name, page URL, browser, device and screen size
• screenshot and video links for one report at a time
• comments on a report, both internal and public
• console logs and network requests captured with a report
• the team's tags

It doesn't get:

• reporter or commenter email addresses
• other teams you belong to, unless you connect again for them
• your billing, team or project settings

Text that reporters typed into a report or comment is included, so the assistant sees whatever people wrote there.

Console logs and network requests are sent as they were captured on the page. That includes the full URL of each request, query string and all, so a token in a URL reaches the assistant too. Request and response bodies are never captured. Network requests are only recorded on STARTUP and higher, and only when the project has them turned on in its widget settings.

Screenshot and video links

Screenshot and video links expire after about an hour. They're meant for your assistant to look at right away, so don't paste them into places where they need to last. Ask for the report again to get fresh links.

Getting a link isn't the same as seeing the image. Whether your assistant can open a screenshot or watch a video depends on the client and the model. Some open the link and look at the image, some only pass the link on to you, and most can't watch video. If the answer depends on what's in the screenshot, check that the assistant actually looked at it, or open the report yourself.

What stays in the dashboard

The MCP server returns the details most useful for finding and fixing a report. For now, some things a report can hold are only in the Ybug dashboard. We plan to bring more of them to the MCP server soon:

• attachments
• user data your site passes to the widget
• the reporter's location and referrer
• custom fields

If the assistant says it needs something it can't get, open the report in the dashboard. The assistant can tell you the report's number, like #412, so you can find it.

What the assistant can change STARTUP

With triage access, the assistant can:

• change a report's status, priority and type
• assign a report to a project member, to yourself, or to nobody
• add and remove tags, and create new tags
• add internal comments

It can't delete reports, comments or tags, or change settings.

Every change is made as you and follows your normal permissions. If you can't edit a project's reports in the dashboard, the assistant can't either.

Comments are internal

Comments added through MCP are always internal. They're never emailed to the reporter and can't be made public. Your team members who follow the report are notified as usual.

Assignment emails work like in the dashboard

When the assistant assigns a report, the new assignee and the previous one get the usual assignment emails. You don't get one about your own change, the same as when you assign in the dashboard. The assistant can only assign people who can open the project: deactivated users and suspended team members are left out.

Status changes work like in the dashboard

A status change made by your assistant counts the same as one you make in the dashboard. That matters for feedback auto-replies: if you've turned them on for a project, moving a report into a status in the Resolved or Closed category sends your automatic reply to the reporter, using your template. What counts is the status's category, not its name, so a custom status like "Done" or "Shipped" triggers it too if it's in one of those categories. Moving between two statuses in the same category doesn't send it again. The reply goes out about a minute after the change, and it isn't sent if the report has left that category by then, so you can undo a mistaken move. If you don't want the assistant to trigger that, tell it not to resolve or close reports, and do that step yourself.

Read-only access on STARTUP and higher

On STARTUP and higher, a connected assistant can use the triage tools: update_feedback, add_comment and create_tag. If you want an assistant to only read, you have three options, from strongest to weakest.

1. Connect with read permission only. If your client lets you choose the OAuth scopes it requests, request only feedback:read. Ybug then rejects every change, whatever the assistant tries and whatever the client settings say. The triage tools may still show up in the client's tool list, but every call to them fails.

The consent screen shows what the client asked for, but you can't untick a permission there. Most clients ask for both, so this option isn't available everywhere.

2. Turn off the triage tools in your client. Most clients let you turn off individual tools. This works as long as the client setting stays in place, but Ybug itself would still accept the change if the setting were removed.

The examples below assume you named the server ybug, as on the setup pages. If you used another name, like ybug-acme, use that name instead. Each server entry needs its own rules.

• Claude Code: add deny rules to .claude/settings.json in your project, or to ~/.claude/settings.json to cover all projects. The part between the double underscores is the server name:

  {
    "permissions": {
      "deny": [
        "mcp__ybug__update_feedback",
        "mcp__ybug__add_comment",
        "mcp__ybug__create_tag"
      ]
    }
  }

• Codex: in ~/.codex/config.toml, add a disabled_tools line to the existing [mcp_servers.ybug] table. Don't add a second copy of the table:

  [mcp_servers.ybug]
  url = "https://mcp.ybug.io/mcp"
  disabled_tools = ["update_feedback", "add_comment", "create_tag"]

• VS Code: click Configure Tools in the Copilot Chat input and untick the three tools under ybug.

• ChatGPT: open the Ybug app in the app settings and turn the three tools off.

• Other clients: look for the tool list in the connector or MCP server settings, and turn those three tools off.

Requiring approval for a tool is not the same as turning it off. The assistant asks first, but once you approve, the change goes through. It's a good fit when you want to review each change, not when you want no changes at all.

3. Ask the assistant not to change anything. This is useful, but it isn't a permission. A prompt doesn't change what the assistant is allowed to do. The assistant can misread it or forget it in a long conversation.

You can also limit it in Ybug itself. The assistant never gets more access than the person who connected it. A team member with the Viewer role on a project can read its reports and comment, but can't change status, priority, type or tags, and neither can their assistant.

The consent screen

When you connect an assistant, Ybug shows a consent screen with:

• the assistant's name
• the team it will access
• the permissions it asked for: Read feedback and bug reports and, when it asks for it, Make changes to feedback and bug reports

The permissions come from the assistant's request. On BASIC, the change permission has no effect, because the triage tools aren't available.

What happens to the data your assistant receives

Everything a tool returns, like report text, comments, page URLs and screenshot links, goes to your AI assistant. From there, the assistant's provider decides how it's stored, how long it's kept and whether it's shared further. Check your client's privacy settings and your plan with that provider. Ybug doesn't control what happens after the data leaves the MCP server.

Instructions inside reports

Reports and comments are written by other people, including website visitors. Sometimes that text contains instructions, on purpose or not: "ignore previous instructions", "mark this as resolved", "run this command". Treat that as report content, not as permission to act. Ybug's tool descriptions tell the assistant the same thing, but it helps to be careful:

• review triage changes before you approve them, especially in large batches
• don't give a coding agent broad permissions in the same session where it reads reports from the public

Disconnecting an assistant

1. Open Connected apps in your account settings.
2. Find the assistant and click Disconnect.

This revokes the assistant's access to that team right away. It can't call any Ybug tools for that team until you connect it again and approve access.

A few things aren't affected:

• Other teams. Each team is a separate connection. If you connected the same assistant to another team, that connection stays active until you disconnect it too.
• Screenshot and video links the assistant already received. They keep working until they expire, about an hour after they were issued.
• Anything the assistant already did, such as status changes or comments. Those stay in Ybug.

Connected apps also shows the team each connection has access to and when it was last used.

Access also ends automatically if you leave the team or your user account is deactivated.