MCP tools: what an assistant can do

The thirty-one MCP tools, the scope each one needs, and what each will refuse.

Checking the MCP connection

lynkarr_whoami needs no scope and answers with the account, the plan, the scopes the token holds and how much rate limit and quota is left. It is the first thing to try when something is refused, because it turns “that did not work” into “the token has no codes:write”.

Reading codes

lynkarr_list_qr_codes needs codes:read. It lists codes newest first with their current destination and scan count, and takes an optional name search so an account with two hundred codes does not have to be paged through.

lynkarr_get_qr_code needs codes:read and returns one code in full, given its id.

Making and changing codes

lynkarr_create_qr_code needs codes:write. Codes are dynamic unless you say otherwise, which is almost always what you want: a static code cannot be changed after printing, ever.

lynkarr_repoint_qr_code needs codes:write and is the one that earns the whole integration. It changes where an existing dynamic code goes. The pattern does not change, so everything already printed keeps working and starts going somewhere new.

lynkarr_archive_qr_code needs codes:write and stops a code resolving. Anything printed dies with it.

Repointing takes effect on the next scan. There is no cache to wait for.

Short links

lynkarr_list_short_links needs links:read. lynkarr_create_short_link needs links:write and takes an optional slug — leave it out and one is generated.

Cards, pages and forms

Each of the three works the same way: list, read one, create, and edit. Reading needs cards:read, pages:read or forms:read; creating and editing needs the matching write scope. Anything created is a draft unless you say to publish it, so it can be checked before anybody can reach it.

Two things are deliberately left to the dashboard. A page's blocks and a form's fields are not edited through an assistant — a page is built visually, and changing a form's fields changes what its past submissions mean.

What people have submitted

lynkarr_get_form_submissions and lynkarr_get_card_enquiries return what other people have sent you: names, email addresses, whatever your form asked for. They sit behind forms:read and cards:read, because reading the responses is most of what a form is for.

That makes those two scopes meaningful things to grant. A token issued so an assistant can tidy up your form titles will also read every enquiry, so if that is not what you want, issue it without forms:read. Both are read only: nothing here can delete somebody's enquiry.

This is your customers' personal data. Whatever obligations you have about it are unchanged by an assistant being the thing that reads it.

GS1, media, campaigns and tags

GS1 Digital Links can be listed, created and edited with gs1:read and gs1:write — including changing where a printed pack resolves to, which works for the same reason repointing a QR code does. One resolution per GTIN and link type; a second is refused with the id of the one that already exists.

The media library is read only: media:read lists what is there with names, types and sizes. Uploading is a two-step against object storage, and a token that could start one could fill your quota with anything.

campaigns:read and campaigns:write cover campaigns and tags. Things are put into a campaign from the dashboard.

The team, and why it is read only

lynkarr_list_team needs team:read and returns who is on the account, their role, whether they are active and when they last signed in.

There is no writing counterpart and there is no team:write scope. Inviting somebody creates a credential; changing a role grants power; removing somebody takes their work away. A leaked token that could do any of those costs you the account rather than an afternoon, so no token can, whatever it holds. Those changes are made on the Team page by a person who signed in.

Analytics

lynkarr_get_scan_analytics needs analytics:read and reports scans for one code over a number of days, broken down by day, country and device.

It cannot tell you who scanned, on any plan, because that is not recorded anywhere. No cookies, no stored IP addresses, no cross-site identifier. The answer is how many, from where and on what — never who.

When something is refused

A refusal comes back as a tool error with the reason, not as a broken tool, so the assistant can explain it. The common ones: a missing scope, the plan's code allowance being full, the per-minute rate limit, and the monthly API quota. lynkarr_whoami tells you which of those you are against.