In this article
An agent sharing role controls access to its definition and use. MCP authentication remains per user, and tool approval follows the instance policy.
Sharing an agent in LibreChat can make a reusable workflow available to another person. It does not mean that the recipient inherits the author’s external credentials or gains every tool permission. Model access, agent sharing and tool authentication need to be tested as separate parts of the recipient’s actual session.
Choose the recipient’s agent role
The Agents guide describes Viewer, Editor and Owner roles. A viewer can chat with the agent without receiving builder access to its definition. An editor can change its configuration, while an owner has broader management powers. Choose the role required for the intended collaboration.
For an internal document assistant, the person asking questions may need only the ability to use it. The maintainer changing model instructions needs another scope. Treat those people as separate test accounts rather than using an administrator account to establish what every ordinary recipient can do.
Check the instance access policy
The LibreChat access-control reference describes the surrounding permissions system. Agent sharing exists within that policy. A visible card does not establish eligibility for the underlying model, file resources or external integration.
List the dependencies of a representative task. Check that the recipient can select the intended model and use the resources they are meant to see. Keep an unavailable dependency distinct from an absent shared agent: both can prevent the workflow, but the fixes belong to different owners.
Authenticate MCP as the recipient
The MCP guide documents per-user connections and credentials. Sharing an agent that references a server does not silently transfer the author’s OAuth identity. The recipient may need their own authentication or required connection values.
Inspect the recipient’s connection state before running a task. A server can be reachable while authentication is missing. Also distinguish an agent’s bound tools from the chat picker’s available servers. The configured agent should expose only the tools needed for the stated task.
Test a tool result, not only a text answer
Use a non-sensitive sample resource that the recipient is authorized to read. Ask the shared agent for a bounded retrieval and verify the actual tool result. An answer that sounds plausible without the expected source does not establish a working connection.
Check the tool approval behavior in the recipient session. Administrator rules and supported per-agent approval settings are separate from the sharing role. Do not broaden permissions merely to eliminate a prompt; determine which operation the task actually requires and apply the existing instance policy.
Review what the agent can reveal
The Agents guide notes that hiding builder access does not guarantee that instructions or supplied files can never be repeated in a conversation. Avoid embedding information that the intended audience must never receive. Share only a definition whose resources match its audience.
Keep a short handover record covering agent role, model connection, MCP identity and the successful sample task. Repeat the recipient test after changing tools or attached resources. This makes collaboration reproducible without confusing a shared interface with delegated authority over another user’s accounts.
Related reading
llama.cpp server: a local API from a GGUF model, VRAM for LLMs: why model size is only part of the calculation.