Skip to main content
Glama

Invite or revoke model access

layerz_share_model
Destructive

Changes who can access a model, by op. invite (default): grants email the role viewer (read-only, default) or editor; a registered user gets an active share, an unregistered one a pending invite; both receive an email. revoke: removes the collaborator or pending invite principal_id (an id from the sharing.members of layerz_get_model). Owner-only. The link visibility (invite / public) is changed by the owner in the web app only. No version is persisted. Not advertised to read-only keys.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "layerz_share_model"
  }
}

Input Schema

NameRequiredDescriptionDefault
opNoinvite (default) | revoke.invite
roleNo`invite`: viewer (read-only, default) or editor.
emailNo`invite`: the email address to invite.
model_idNoTarget model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys.
principal_idNo`revoke`: collaborator user id or pending-invite id from `sharing.members`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / email / description
      Previous value: -"The email address to invite."New value: +"`invite`: the email address to invite."
    • changedInput schema / properties / model_id / description
      Previous value: -"Target model UUID. Required for user-scoped API keys; ignored (or validated against scope) for model-scoped keys."New value: +"Target model UUID. Required for user-scoped API keys; validated against the bound model for model-scoped keys."
    • addedInput schema / properties / op
      Added value: +{
      +  "default": "invite",
      +  "description": "invite (default) | revoke.",
      +  "enum": [
      +    "invite",
      +    "revoke"
      +  ],
      +  "type": "string"
      +}
    • addedInput schema / properties / principal_id
      Added value: +{
      +  "description": "`revoke`: collaborator user id or pending-invite id from `sharing.members`.",
      +  "minLength": 1,
      +  "type": "string"
      +}
    • changedInput schema / properties / role / description
      Previous value: -"viewer (read-only) or editor (can edit). Defaults to viewer."New value: +"`invite`: viewer (read-only, default) or editor."
    • removedInput schema / required
      Removed value: -[
      -  "email"
      -]
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds material context beyond them: owner-only authorization, side effects (emails sent, active share vs pending invite depending on registration), no version persisted, and that link visibility cannot be changed here. That is exactly the kind of consequence an agent needs before mutating access.

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

Conciseness5/5

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

Dense but front-loaded: the op semantics come first, then role/identity details, then constraints and caveats. Backticks around identifiers keep it scannable, and no sentence is redundant.

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

Completeness4/5

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

Covers operations, permissions, side effects, and caveats for a 5-parameter mutation tool with no output schema. The only gap is what a successful call returns (share object, invite status), which would help an agent chain the next step.

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, but the description adds real meaning: the default value of `op`, the viewer/editor distinction and viewer being read-only default, and crucially that `principal_id` comes from `sharing.members` of `layerz_get_model`. It does not explain the interaction constraint between `op` and the other parameters (e.g. that `email`/`principal_id` are op-specific).

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?

States a specific verb+resource ('Changes who can access a model') and immediately enumerates the two operations, `invite` and `revoke`, with their effects. An agent can distinguish this from siblings like `layerz_get_model` or `layerz_list_models` without opening the schema.

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?

Gives explicit when-to-use routing per `op`: invite grants a role to an email, revoke removes a collaborator or pending invite by `principal_id`. It also names the alternative path for link visibility ('changed by the owner in the web app only'), states the owner-only precondition, and warns it is not advertised to read-only keys.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources