Skip to main content
Glama

Approve membership request

approve_membership_request
Destructive

Let an applicant into the group. Your AutoDM, if set, goes out as usual. Waits for the owner's approval.

Input Schema

NameRequiredDescriptionDefault
groupYesGroup URL name, e.g. 'yourgroup' for skool.com/yourgroup.
request_idYesrequest_id from list_membership_requests.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true and non-idempotentness, so the safety bar is lower. The description does add real behavioral context beyond the annotations — the AutoDM side effect firing on approval — but omits what the call returns, whether re-approving an already-approved request errors, and what happens if the AutoDM is unset.

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?

Three short sentences, front-loaded with the effect, no restated title boilerplate. "Goes out as usual" is slightly vague filler but does not bloat the definition.

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

Completeness3/5

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

For a mutation with side effects and no output schema, the description covers the AutoDM consequence but leaves the return value, failure modes, and the actual semantics of the "owner's approval" wait unexplained. Adequate but with a clear gap at the exact point an agent would need certainty.

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%, including where request_id comes from, so the schema carries parameter meaning. The description adds nothing about the group vs. request_id pairing or format constraints, which is acceptable given full coverage but is not value-add.

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

Purpose3/5

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

"Let an applicant into the group" conveys the action and resource, and the tool name/siblings make the contrast with decline_membership_request inferable. However, "Waits for the owner's approval" undercuts the verb — it is unclear whether this call actually admits the member or merely registers an approval that then pends, leaving the agent unsure of the effect.

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

Usage Guidelines2/5

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

There is no explicit statement of when to use this versus decline_membership_request, no mention of first calling list_membership_requests, and no prerequisites or preconditions. Usage is only implied by the noun 'applicant'.

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.