Skip to main content
Glama

Get AutoDM

get_auto_dm
Read-onlyIdempotent

Fetches the AutoDM welcome message and its on/off status for a Skool group, so admins can review the new-member greeting text and sender.

Instructions

The welcome message Skool sends every new member, and whether it is on. Admins only.

Returns the group's AutoDM: the chat message Skool sends each new member when they are approved, who it comes from and whether it is on. #NAME# and #GROUPNAME# in the text become the member's first name and the group's name. Admins only.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds real context beyond that: the admins-only auth requirement and the placeholder substitution rule (#NAME# becomes the member's first name, #GROUPNAME# the group's name). It doesn't discuss errors for non-admin callers, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The text is materially redundant: the opening line restates the 'welcome message ... whether it is on' summary that the second paragraph repeats in full, and 'Admins only' appears twice. The useful details are present but buried in duplicated phrasing.

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?

For a one-parameter read tool with no output schema, the description covers what is returned (message text, sender, enabled state), the auth restriction, and placeholder behavior. Details of the exact return shape are the only omission, and those are low risk here.

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 coverage is 100% and the single `group` parameter is documented with a concrete example format in the schema. The description adds nothing about the parameter, 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?

States a specific verb and resource: returns the group's AutoDM welcome chat message, its sender, and whether it is enabled. An agent can tell this is the read side of a settings pair. It does not explicitly name set_auto_dm as the mutation counterpart, so it stops short of full sibling differentiation.

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?

'Admins only' establishes the authorization prerequisite and implies the read-versus-write split with set_auto_dm, but that alternative is never named. There is no explicit when-to-use or when-not-to-use guidance beyond the admin restriction.

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