Skip to main content
Glama

Cluby MCP

List organizations

list_orgs
Read-only

Organizations (and their venues) this API key can access. Call this first: every other tool takes an organization's id as orgId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
searchNoCase-insensitive search across organization and venue names
perPageNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the description doesn't need to restate safety. It adds meaningful behavioral context beyond the annotations: results are scoped to the API key's access, and the tool is a required first step for other operations. It does not cover pagination or default return order, but the added access and workflow details are valuable.

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?

Two tightly constructed sentences with no filler. The resource scope is front-loaded, and the prerequisite instruction follows immediately, making the key routing information highly scannable.

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 simple read-only discovery tool, the description provides enough context to use it correctly: what it returns, that it is scoped to the API key, and that it must be called first. Pagination behavior for page and perPage is left to the schema, and since no output schema exists, the description does not need to explain return values further.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%, with page and perPage undocumented anywhere. The description adds no input parameter semantics at all; it mentions orgId only as an output identifier used by other tools, not as an argument to this tool. It therefore fails to compensate for the low schema coverage.

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?

The description identifies the exact resource (organizations and their venues) and the access scope (this API key), while the tool name and title supply the list verb. It also distinguishes this tool from all siblings by declaring that it must be called first, making its purpose unmistakable.

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?

It explicitly states when to use this tool: 'Call this first.' It further explains why by noting that every other tool takes an organization's id as orgId, effectively defining this as the prerequisite discovery call. No alternative tool exists for this prerequisite, so the guidance is complete.

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.

Resources