Skip to main content
Glama

Start a free 14-day trial

start_trial

Starts a free 14-day trial for a company after verified sign-in, letting one builder create up to three apps without a card.

Instructions

For a company that doesn't have TeamOnly yet, after sign_in verified the email: starts a free 14-day trial (one builder, up to 3 apps, no card).

Input Schema

NameRequiredDescriptionDefault
companyNoThe company's name

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

A3.7/5.0
Behavior3/5

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

Annotations only carry openWorldHint=true, so the description bears most of the disclosure burden. It does add valuable terms: 14-day duration, 1 builder, 3 apps, no card required. But it omits what the call returns, whether it is idempotent or errors on an existing trial, and what happens when the trial expires, which matters for a creation/mutation operation.

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?

One compact sentence that front-loads the eligibility precondition before the action, with zero filler. Every clause (eligibility, prior sign-in, trial terms) carries actionable information.

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?

With no output schema, the description should indicate what the agent gets back or what state changes on success/failure. It covers eligibility and trial terms well but leaves return value and post-call state unaddressed, so it is adequate rather than complete for a state-creating tool.

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 parameter with 100% schema description coverage ('The company's name'), so the schema already does the work. The description only implies the company must not already have TeamOnly, adding a precondition rather than new meaning about the parameter itself, 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 ('starts a free 14-day trial') and spells out the resulting entitlements (one builder, up to 3 apps, no card). It also names the precondition (company without TeamOnly, after sign_in verified the email), so an agent can distinguish it from subscribe. It does not explicitly contrast with the subscribe sibling, which keeps it from a 5.

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?

Gives a clear trigger condition: only for a company that doesn't have TeamOnly yet, and only after sign_in has verified the email. This effectively routes the agent away from the paid-subscription path, though the alternative (subscribe) is not named explicitly and no exclusions or repeat-call behavior are stated.

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