TheSignup

Identify the calling credential

whoami

Identify which organizations this connection can act in and which scopes were granted. Call first to confirm context before doing real work. organization is the default org — the one used when a tool is called without organization_id. organizations lists every org reachable from this connection, each with the scopes in force there; pass one of their ids as organization_id on any tool to act in it. Also returns a quotas map keyed by scope (ai:draft, messages:send) with used, limit, remaining, and period. Unlimited quotas (Pro+) report limit: null and remaining: null. messages:send is never unlimited — it counts RECIPIENTS emailed today (UTC), so read remaining before calling message_participants on a large scope.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`organization_id`	No	Which organization to act in. Defaults to the one this connection was authorized for. Any other organization must have been granted to this connection — call whoami to list them.

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden and it excels: it explains the org structure, default org semantics, per-org scopes, quota fields, null values for unlimited quotas, and the special recipient-counting behavior of the message limit. This goes well beyond the name and schema.

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?

The description is information-dense but every sentence earns its place: purpose, when-to-call, org fields, quota fields, null semantics, and an exception for messages:send. It is front-loaded with the core purpose and each added detail clarifies a real decision the agent may need to make.

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?

There is no output schema, so the description fully takes on the return format. It explains nested concepts like the organizations list and the quotas map, defines field semantics, and handles edge cases like unlimited quotas. Nothing critical is missing for an agent to safely use this tool and know what it will get back.

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

Parameters4/5

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

The schema already describes the one parameter with complete coverage, so the baseline is 3. The description adds extra value by specifying that the default org is the one used when organization_id is omitted and that all reachable organization ids from the organizations field can be used as parameter values. This elevates the guidance.

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 says specifically what the tool does: identifies the organizations and scopes available to the calling connection. This is a distinct purpose from all sibling tools, which are CRUD actions on signups, slots, participants, and messages.

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 instructs the agent to call it first 'before doing real work.' It also gives condition-specific guidance: pass an organization id from the returned organizations list to act in another org, and check the remaining quota before calling message_participants on a large scope. These are concrete and usable context signals.

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

All TheSignup tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0

Disambiguation4/5

Each tool targets a clear resource and action, and the descriptions explicitly separate potentially confusing pairs like get_signup_analytics vs get_slot_coverage and register_self vs register_participant. publish_signup and set_signup_status overlap somewhat on status transitions, and message_participants vs send_reminder are both messaging tools, though their channel and scope differences are well documented.

Naming Consistency5/5

Tool names consistently follow the verb_noun snake_case pattern: add_items, create_signup, list_participants, set_signup_status, etc. whoami is the only deviation, but it is a common convention and does not undermine the overall pattern.

Tool Count4/5

At 16 tools, this sits just above the typical well-scoped range, but the count is justified by the breadth of the domain: signup creation, slot/item management, participant registration, analytics, messaging, and status transitions. Each tool earns its place, though the set feels slightly heavy.

Completeness4/5

The core signup lifecycle is well covered: create, add slots/items, publish, register/remove participants, analyze coverage, and communicate. Notable gaps include no way to update or delete a signup, and no editing of slots/items after creation, which agents may need to work around by creating new resources.

Resources

Need Help?