Skip to main content
Glama

Share

share

Create a one-time invite link that lets a named person search this knowledge corpus. Preview what would be exposed first, then confirm to register the owner and start the background upload.

Instructions

SHARE this knowledge base with someone — returns a link to send them.

Reach for this when the user says share my KB / send my knowledge base to X / let X search what I've read. It hands back one link. The person who opens it can install Opyt if they need to, and after that their assistant can search this corpus, with every result attributed here.

TWO-PHASE, and the preview is the consent step, so run it first: • confirm=False (the default) → a PREVIEW. It publishes nothing, mints nothing and hands nobody anything; on an install that has already shared it asks the service whether an export has landed, and that is the only thing it sends. It reports WHAT would be shared — how many atoms, from which sources and authors, over what date span — and what sharing means. READ THAT BACK to the user before confirming. Sharing is the WHOLE knowledge base, standing, not a slice and not a snapshot: there is no way to share part of it, anyone given a link keeps access until it is revoked, and the copy refreshes itself when people read it. • confirm=True → registers this install with the service if it is not registered yet, starts the first upload, mints a one-time invite, and returns the link.

Skip straight to confirm=True only when the user has already said yes to sharing THIS knowledge base, having been told what is in it.

The first share uploads the whole corpus, which runs in the background and usually takes a minute or two. The link works immediately: a reader who accepts inside that window is registered normally, and it is their first SEARCH that comes back saying the copy is still arriving. The next one works. Later shares are instant.

WHAT THIS IS NOT. It does not publish anything on the open web — the service serves only people holding a link, one reader token per link, revocable. It does not send anything to the person for you: hand the user the link and let them send it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
as_nameNowhat to call this knowledge base's owner. This is what every recipient's install suggests as the name they search under, so use the user's own name or handle. Required on the FIRST share; ignored afterwards, because the name is already registered.
confirmNoFalse (default) = preview only, nothing written or sent; True = register, publish and mint the invite.
for_whomNoan optional label for who this particular invite is for ("Leo"). It is the handle that makes that person nameable afterwards: `unshare(reader="Leo")` cuts off exactly them. Without it they can only be named by a token id.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations to rely on, the description fully discloses side effects: confirm=False publishes/mints nothing, confirm=True registers and uploads, the first upload is asynchronous, links work immediately with eventual consistency for the first search, access is revocable, and sharing is a standing whole-corpus grant. This is unusually complete behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but well-structured and front-loaded: purpose first, then the critical two-phase consent flow, then operational expectations, then exclusions. There is minor redundancy across the 'publishes nothing / mints nothing / hands nobody anything' clusters, but the length is justified by the security-sensitive behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a no-annotation tool with side effects and an output link, the description covers the full invocation decision: what happens on preview, what happens on confirm, first-share timing, link behavior, and security boundaries. An agent has enough context to select, run, and explain the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by explaining the two-phase behavior of confirm and by clarifying that as_name matters on the first share. It does not add specific semantics for for_whom, but the schema already describes it well.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence names the action ('SHARE'), the resource ('this knowledge base'), and the outcome ('returns a link'), and the later 'WHAT THIS IS NOT' section draws clear boundaries against related operations. This is immediately distinguishable from the sibling tools such as unshare.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly tells the agent when to reach for the tool ('share my KB / send my knowledge base to X'), when it is acceptable to skip the preview ('only when the user has already said yes'), and what the tool does not do (no open-web publishing, no sending on the user's behalf). It communicates that the preview is a consent step that must be run first, which is essential guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/maimond123/Opyt'

If you have feedback or need assistance with the MCP directory API, please join our Discord server