Paperform

Share connection

share_connection

DestructiveIdempotent

Change who can use an app account the user connected in Stepper, such as sharing their Google Sheets account with another space so that space's workflows can use it. Only the person who connected an account can change this (fetch the connection: can_share says whether the user can). Credentials never change hands; only who may use the account does. The user's own platform connection (Stepper, Paperform and Papersign) can be shared the same way; list({ type: "connection", mine: true }) returns its id. A space's own connection cannot be shared.

sharing: • "spaces" — share it with the spaces listed in spaces (space ids from whoami), and only those. This is "Shared" on Stepper's Connections page. • "team" — share it with everyone on the team ("Public"). • "private" — stop sharing it ("Private").

Taking an account away from a space unpublishes the workflows there that use it, and they stay off until it is shared again and they are published again. The user is told which workflows before anything changes; workflows in spaces the user cannot see are not named, only said to exist. Some teams' plans only allow "team". Spaces this connection to Paperform cannot reach keep any sharing they already have. Asking for the sharing it already has changes nothing. Confirm with the user before calling this.

Returns { id, changed, sharing, message, record, unpublished }.

Example: share_connection({ id: "12:connection:9c58b7a0-…", sharing: "spaces", spaces: [12, 14] }) → { "changed": true, "message": "Work sheets is now shared with Marketing and Sales (Shared).", … }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "sharing": "<sharing>"
    },
    "name": "share_connection"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	The connection id, exactly as list or fetch returned it.
`spaces`	No	With sharing "spaces": every space that should be able to use it afterwards (space ids from whoami). Spaces left out lose it, except ones this connection to Paperform cannot reach, which keep what they have.
`sharing`	Yes	Who can use it afterwards: "private" (only its owner), "team" (everyone on the team) or "spaces" (only the spaces in spaces).
`confirm_unpublish`	No	Only when an earlier call refused and asked for the user's agreement (because the change would unpublish workflows, or the connection could not be read): the value that refusal gave, passed after the user agreed to exactly what it asked.

Output Schema

Name	Required	Description	Default
`id`	No
`record`	No
`changed`	No
`message`	No
`sharing`	No
`unpublished`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial context beyond them: unsharing unpublishes affected workflows and they stay off until re-shared and re-published, the user is warned about which workflows first, hidden-space workflows are only described as existing, and credentials never transfer. It also confirms the idempotent no-op case ("Asking for the sharing it already has changes nothing"), consistent with the annotation.

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?

Front-loads the core action and permission constraint, then uses a tight bulleted list for the three sharing modes and a short paragraph for side effects. The prose is dense but every sentence carries non-obvious information; no filler.

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?

An output schema exists, so return format needn't be explained, yet the description still names the returned fields and shows a realistic response. Permission requirements, destructive side effects, the Paperform exception, and the confirmation handshake are all covered for a destructive 4-parameter mutation.

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 genuine meaning: the enum values are mapped to Stepper's UI states ("Shared", "Public", "Private"), omitting a space is stated to revoke it, and the two-step confirm_unpublish flow is motivated by an earlier refusal. The example illustrates the id format and the spaces array usage.

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?

States a specific verb and resource: changing who may use a connected app account, with the concrete example of sharing a Google Sheets account with another space. It is clearly distinct from generic siblings like update/delete, though it never names the closest alternative (e.g. update or connect_app) to draw the boundary explicitly.

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/when-not rules: only the connector can change sharing (verified via fetch's can_share), a space's own connection cannot be shared, some plans allow only "team", and it instructs confirming with the user before calling. The fetch-then-share and refusal-then-confirm_unpublish sequences are spelled out rather than inferred.

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

All Paperform tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?