Skip to main content
Glama
Sign In
drop2run-mcp

drop2run-mcp

Official
by Drop-to-run
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List who a site is shared with

list_people
Read-only

Lists everyone added to a site's invite list, showing their view/comment permission and open status, and whether the list controls access while the site is invite-only.

Instructions

Lists the people on a site's list — the ones invite_people added — with what each may do (view or comment) and whether they have opened it yet. Says whether the list decides who can open the site, which it does only while the site is invite-only.

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": {
      "site": "<site>"
    },
    "name": "list_people"
  }
}

Input Schema

NameRequiredDescriptionDefault
siteYesSubdomain or site id, from list_sites.

Output Schema

NameRequiredDescriptionDefault
limitYesThe most the plan allows on one site's list.
totalYesHow many are on the list.
peopleYes
invitedOnlyYesWhether only the people on the list can open the site now.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.2.5

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses return semantics (per-person permission level and whether they've opened the site) and a non-obvious conditional behavior: the list governs site access only while the site is invite-only. That invite-only caveat is real behavioral context the annotations do not convey, though permission/access requirements for calling it are not stated.

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?

Two sentences, front-loaded with the resource and its scope, and every clause adds information (entry origin, per-person permission, opened status, invite-only caveat). The second sentence is slightly convoluted but not wasteful.

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?

With annotations covering the safety profile, a full output schema covering return values, and 100% schema coverage for the lone parameter, the description only needs to add domain nuance — which it does via the permission values and the invite-only conditional. Nothing needed to call this correctly is missing.

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% and there is a single required 'site' parameter documented in the schema with its source (list_sites), so the description adds no parameter detail. Baseline 3 applies when the schema fully carries parameter meaning.

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 (lists) and resource (people on a site's list) and immediately scopes it to entries added by invite_people, which separates it from siblings like list_sites, list_comments, and remove_person. It also names the per-entry data returned (view/comment permission, opened status), so an agent knows exactly what this tool yields.

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

Usage Guidelines4/5

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

The description ties the tool to its companion write operation by noting the entries are 'the ones invite_people added', which implicitly tells the agent this is the read counterpart to invite_people/remove_person. It gives clear context but no explicit when-not-to-use or exclusion against other listing tools.

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

Deploy Server

Other Tools