Skip to main content
Glama
swsd-mcp

swsd-mcp

by mikimatsub

swsd_get_group

Read-onlyIdempotent

Fetch a SWSD assignment team by ID to see who is on it, including member names, membership IDs, and user IDs/emails when available. Use the list groups tool first to find the ID.

Instructions

Fetch one SWSD group (assignment team) by id, including its members (membership_id, name, and user id/email when available). Answers "who is on this team?". Use swsd_list_groups first to find the id.

Input Schema

NameRequiredDescriptionDefault
idYesSWSD record id (from the matching swsd_list_* tool).

Output Schema

NameRequiredDescriptionDefault
groupYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.3.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds real value beyond them by disclosing the shape of the returned membership data and framing the tool's purpose as answering "who is on this team?" It stops short of noting error behavior for a non-existent id or whether membership lists are paginated.

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?

Three short sentences: what it returns, the question it answers, and how to get the id. Nothing is wasted and the identifying detail (members included) is front-loaded.

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 one-parameter read tool with full schema coverage, complete annotations, and an output schema, the description covers everything an agent needs: identity of the resource, returned fields, and how to obtain the id. No meaningful gap remains.

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?

There is a single required id parameter with 100% schema description coverage, and the schema already says it comes from the matching swsd_list_* tool. The description's "by id" plus the list_groups pointer restates rather than extends that, so this is the baseline 3 for a fully documented schema.

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 and resource ("Fetch one SWSD group (assignment team) by id"), clarifies the domain synonym (assignment team), and specifies what the payload contains (members with membership_id, name, user id/email). This clearly separates it from the sibling swsd_list_groups, which returns many groups.

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?

"Use swsd_list_groups first to find the id" gives explicit routing to the right sibling and states the prerequisite for the required id. It does not spell out when-not-to-use (e.g., when you only need the group name or a bulk lookup), so it falls just short of fully explicit guidance.

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