Skip to main content
Glama

share_space

Idempotent

Share a space with people by email or @handle. They can read and comment, unless you pass role: edit.

Input Schema

NameRequiredDescriptionDefault
roleNoWhat they may do; view when left out. (one of edit, view)
spaceNoThe space: its address, @handle/slug, or its link. (space name)
peopleNoWho: emails or @handles. (list of person name)
space_idNo`space` by its id, instead of its name. (space id)
people_idsNo`people` by their ids, instead of their names. (list of person id)

Output Schema

NameRequiredDescriptionDefault
sharedNo
refusedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / role / description
      Previous value: -"What they may do; edit when left out. (one of edit, view)"New value: +"What they may do; view when left out. (one of edit, view)"
  2. Changed15 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / allOf
      Added value: +[
      +  {
      +    "anyOf": [
      +      {
      +        "required": [
      +          "space"
      +        ]
      +      },
      +      {
      +        "required": [
      +          "space_id"
      +        ]
      +      }
      +    ]
      +  },
      +  {
      +    "anyOf": [
      +      {
      +        "required": [
      +          "people"
      +        ]
      +      },
      +      {
      +        "required": [
      +          "people_ids"
      +        ]
      +      }
      +    ]
      +  }
      +]
    • removedInput schema / properties / emails
      Removed value: -{
      -  "default": [],
      -  "description": "Email addresses or usernames (with or without @) to grant access to; may be empty when only changing visibility",
      -  "items": {
      -    "pattern": "^(?:[^@\\s]+@[^@\\s]+\\.[^@\\s]+|@?[a-z0-9][a-z0-9-]*)$",
      -    "type": "string"
      -  },
      -  "type": "array"
      -}
    • addedInput schema / properties / people
      Added value: +{
      +  "description": "Who: emails or @handles. (list of person name)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / people_ids
      Added value: +{
      +  "description": "`people` by their ids, instead of their names. (list of person id)",
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / role / description
      Previous value: -"What the people in `emails` may do: 'edit' (the default — sharing hands over the pen, they can change the document from the web app) or 'view' (read and comment only). Pick 'view' when they should only read it — a customer or client getting a finished report, anyone outside the team. Given, it also re-sets the role of anyone in `emails` who already had access. The result says who can edit."New value: +"What they may do; edit when left out. (one of edit, view)"
    • addedInput schema / properties / space
      Added value: +{
      +  "description": "The space: its address, @handle/slug, or its link. (space name)",
      +  "type": "string"
      +}
    • addedInput schema / properties / space_id
      Added value: +{
      +  "description": "`space` by its id, instead of its name. (space id)",
      +  "type": "string"
      +}
    • removedInput schema / properties / team
      Removed value: -{
      -  "description": "Move the space into one of your teams, by its name, slug or id, so everyone on that team can open it (and anyone the team admits by email domain — the answer names them); an empty string takes it out of its team. Only when the person asked to move it, and only a team they named: a name two of your teams share, or a team you are not on, is refused and nothing changes. Moving in with no visibility given narrows the page to the invite rung (the team plus the people already added), so a public page stops being public; pass visibility too to keep it wider.",
      -  "type": "string"
      -}
    • removedInput schema / properties / team_access
      Removed value: -{
      -  "description": "What the team's members may do: 'view' (read and comment) or 'edit'. A space moved into a team with this left out gets 'view'; on a space already in that team, leaving it out keeps what it was.",
      -  "enum": [
      -    "view",
      -    "edit"
      -  ],
      -  "type": "string"
      -}
    • removedInput schema / properties / uuid
      Removed value: -{
      -  "description": "Space UUID, full URL, @handle/slug, or a slug belonging to you",
      -  "type": "string"
      -}
    • removedInput schema / properties / visibility
      Removed value: -{
      -  "description": "Optionally set who can view: 'public' = anyone with the link, no sign-in (STATIC spaces only); 'signed_in' = anyone with the link once they sign in (worker spaces allowed; no guest list to maintain); 'members' = only people you invite, and they may invite others (org space also = org members); 'private' = only people you invite, and only you may invite. On personal spaces members/private differ in invitation rights; on org spaces members also admits org members. A work account's page (its owner's address is on their team's own email domain, e.g. a nekko.ai address on the nekko team) shares as in Google Workspace: 'public' and 'private'/'members' work, 'signed_in' is refused.",
      -  "enum": [
      -    "public",
      -    "signed_in",
      -    "members",
      -    "private"
      -  ],
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "uuid"
      -]New value: +[]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "refused": {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    "shared": {
      +      "items": {
      +        "properties": {
      +          "id": {
      +            "type": "string"
      +          },
      +          "name": {
      +            "type": "string"
      +          }
      +        },
      +        "type": "object"
      +      },
      +      "type": "array"
      +    }
      +  },
      +  "type": "object"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / team
      Added value: +{
      +  "description": "Move the space into one of your teams, by its name, slug or id, so everyone on that team can open it (and anyone the team admits by email domain — the answer names them); an empty string takes it out of its team. Only when the person asked to move it, and only a team they named: a name two of your teams share, or a team you are not on, is refused and nothing changes. Moving in with no visibility given narrows the page to the invite rung (the team plus the people already added), so a public page stops being public; pass visibility too to keep it wider.",
      +  "type": "string"
      +}
    • addedInput schema / properties / team_access
      Added value: +{
      +  "description": "What the team's members may do: 'view' (read and comment) or 'edit'. A space moved into a team with this left out gets 'view'; on a space already in that team, leaving it out keeps what it was.",
      +  "enum": [
      +    "view",
      +    "edit"
      +  ],
      +  "type": "string"
      +}
  4. Changed1 schema field changed
    • changedInput schema / properties / visibility / description
      Previous value: -"Optionally set who can view: 'public' = anyone with the link, no sign-in (STATIC spaces only); 'signed_in' = anyone with the link once they sign in (worker spaces allowed; no guest list to maintain); 'members' = only people you invite, and they may invite others (org space also = org members); 'private' = only people you invite, and only you may invite. On personal spaces members/private differ in invitation rights; on org spaces members also admits org members. A work account's page (its owner's address is on their team's own email domain, e.g. a nekko.ai address on the nekko team) can't be set to 'public' or 'signed_in': it stays inside the company, and people outside are added by email."New value: +"Optionally set who can view: 'public' = anyone with the link, no sign-in (STATIC spaces only); 'signed_in' = anyone with the link once they sign in (worker spaces allowed; no guest list to maintain); 'members' = only people you invite, and they may invite others (org space also = org members); 'private' = only people you invite, and only you may invite. On personal spaces members/private differ in invitation rights; on org spaces members also admits org members. A work account's page (its owner's address is on their team's own email domain, e.g. a nekko.ai address on the nekko team) shares as in Google Workspace: 'public' and 'private'/'members' work, 'signed_in' is refused."
  5. Changed1 schema field changed
    • changedInput schema / properties / visibility / description
      Previous value: -"Optionally set who can view: 'public' = anyone with the link, no sign-in (STATIC spaces only); 'signed_in' = anyone with the link once they sign in (worker spaces allowed; no guest list to maintain); 'members' = only people you invite, and they may invite others (org space also = org members); 'private' = only people you invite, and only you may invite. On personal spaces members/private differ in invitation rights; on org spaces members also admits org members."New value: +"Optionally set who can view: 'public' = anyone with the link, no sign-in (STATIC spaces only); 'signed_in' = anyone with the link once they sign in (worker spaces allowed; no guest list to maintain); 'members' = only people you invite, and they may invite others (org space also = org members); 'private' = only people you invite, and only you may invite. On personal spaces members/private differ in invitation rights; on org spaces members also admits org members. A work account's page (its owner's address is on their team's own email domain, e.g. a nekko.ai address on the nekko team) can't be set to 'public' or 'signed_in': it stays inside the company, and people outside are added by email."
  6. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), so the description's job is to add the semantics of the mutation. It does: recipients get read-and-comment by default, and role: edit escalates them. It does not say whether recipients are notified or what happens when sharing with an external address, which is a real gap for an open-world tool.

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?

Two short sentences, front-loaded with the action and the audience, then the permission nuance. No filler, no repetition, and the conditional clause is placed exactly where it is needed.

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?

With a full output schema, complete parameter descriptions and annotations covering safety, the description only needs to convey intent and the default permission level, which it does. Minor omissions (notification behavior, permission required to share) keep it from being fully complete.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents space, space_id, people, people_ids and the role enum including its view default. The description restates the role default and the email/@handle forms rather than adding new meaning, so baseline 3 applies.

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

Purpose4/5

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

The description gives a specific verb and resource ("Share a space") plus the target audience (people by email or @handle), which separates it from siblings like share_design_system or share_session. It never names those siblings explicitly, so differentiation relies on the resource noun alone.

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

Usage Guidelines3/5

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

Usage is implied: call this when you want to grant people access to a space. The "unless you pass role: edit" clause hints at the permission choice, but there is no explicit when-not guidance, no mention of prerequisites (e.g. ownership or admin rights needed to share), and no routing to alternatives such as set_copy_permission.

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