GrowSurf MCP Server

Official

Overview Schema Source Related Servers Discussions Admin

growsurf_create_account

Destructive

Create a GrowSurf account to receive an API key for a 14-day trial. Owner approval and email verification activate the key.

Instructions

Create a brand-new GrowSurf account and return an API key. Call this tool only after the authorized owner explicitly approves account creation and accepts GrowSurf's Terms of Service (https://growsurf.com/terms) and Privacy Policy (https://growsurf.com/privacy). This is the only tool that does not require GROWSURF_API_KEY. The account starts a 14-day Business trial without a credit card. The endpoint returns the new key once in apiKey. A lost key cannot be recovered through this API, so do not create an account here unless you can store the key somewhere that outlives the current conversation. If you cannot, ask the account owner to connect GrowSurf's hosted MCP server at https://mcp.growsurf.com instead, which keeps the credential with your tool rather than in chat. The key is locked until the account owner's email address is verified. Until then, program and resource endpoints return a 403 with error code EMAIL_NOT_VERIFIED_ERROR. Create the account, tell the owner to click the link in the verification email, then retry until that error clears. Use growsurf_resend_team_owner_verification_email if the email was lost. The welcome email also contains a set-password link for dashboard access. Accounts whose email is never verified are deleted automatically after 7 days. Verification unlocks the same key you were given, so keep it and retry rather than asking for a replacement. Separately, the API key is replaced the first time the account owner signs in to the GrowSurf dashboard; after that the previous key returns a 403 with error code NOT_AUTHORIZED_ERROR. Some actions, such as emailing participants, also require GrowSurf to verify the team. Personal and disposable email addresses are not accepted.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`email`	Yes
`company`	No
`lastName`	No
`firstName`	No

Output Schema

TableJSON Schema

Name	Required	Description
`email`	No	Email address for the new account.
`apiKey`	No	An API key for the new account. Shown once, locked (`403` `EMAIL_NOT_VERIFIED_ERROR`) until the account's email is verified, and rotated when the owner first signs in to the dashboard.
`verificationStatus`	No	Team verification state for the new account.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.12.2Aug 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only set readOnlyHint=false and destructiveHint=true. The description goes far beyond, disclosing trial period, key locking until email verification, auto-deletion after 7 days, key replacement on first sign-in, and the specific error codes. This is extensive behavioral context that an agent needs and is not present in structured fields.

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?

The description is long but every sentence adds necessary information about verification, error handling, and key storage. It is front-loaded with the primary purpose and preconditions. While dense, it is not redundant; a 4 is appropriate for its efficiency given the complexity.

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?

For a complex account-creation tool, the description covers the full lifecycle: prerequisites, token retrieval, verification, error codes, retry logic, key replacement, and automatic deletion. An output schema exists so return values need not be explained. Nothing essential for correct invocation is missing.

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 0%, so the description carries the full burden. It explains constraints on email (personal/disposable not accepted) but does not clarify the meaning or format of company, firstName, or lastName. Partial compensation; enough to avoid misuse of email but leaves other fields ambiguous.

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 states a specific action (create a brand-new account), the resource (GrowSurf account), and the key outcome (returns an API key). It also differentiates from all siblings by noting it's the only tool not requiring GROWSURF_API_KEY. This is unambiguous and distinguishes it well.

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?

Provides explicit conditions for use (owner approval, terms acceptance) and explicitly names an alternative (hosted MCP server) when key storage is not possible. Also gives post-call guidance (verification email, resend tool) and when to retry. This fully covers when and when-not to use.

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

Deploy Server