Look up an address in Outlook contacts, so "email Bob" resolves. Read-only.
Connect it
$ lanes link connect outlook_contacts --profile personal --workspace localOutlook Contacts does not offer dynamic registration, so this needs an OAuth application of your own: you register it once in their console, and Lanes Link uses those values from then on. Run lanes link setup plan outlook_contacts for the exact steps, the values it wants, and the command that finishes the job.
What your agent can do
Capabilities are generated from an OpenAPI document vendored into Lanes Link, so the surface is reviewable in a diff and a change upstream cannot widen what your agents can reach without a commit here.
The scopes it asks for
Each provider asks for the narrowest set that makes its capabilities work, because a scope on a consent screen that no tool can spend is a grant asked for and never noticed.
| Scope | What it allows |
|---|---|
offline_access | keep the connection working without sending you to a browser again; Microsoft issues no refresh token without it |
User.Read | your name and address, so this connection can be labelled with whose it is. No mail, calendar, or files |
Contacts.Read | read the address book. Read-only; nothing here writes a contact |
How to narrow or widen any of this is on Scopes and permissions.
What is recorded
Every call is recorded, allowed or refused. The rule is to keep the shape and withhold the words: an audit log that reproduced the content would be a second copy of the thing it was meant to make accountable.
Identifiers such as top, orderby, select, and contact-id are kept. Everything that carries your words is withheld.
What an entry holds and how to read one is on the audit log.
Narrowing what it may do
Connecting grants the read bundle. Tightening it happens on your machine and takes effect at once:
$ lanes link policy deny 'outlook_contacts.*' --connection outlook_contacts.main --profile personal --workspace localA deny always beats an allow, whatever the order in the file. See Scopes and permissions for widening, and for what can and cannot be set per connection.
Untested
The manifest is right in every way the code can check: it validates, its tools generate inside the budget, its scopes are described, and its endpoint answered a probe. Nobody has yet connected it to a real account, which is the part only a real account proves.
If you connect it, say so and this note comes off.
Next: every provider, or Connections for what a connection is and the methods behind one.