Skip to main content
Glama
antideploy

antideploy-mcp

Official
by antideploy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Switch on sign-in for the application's own users now

auth_create

Enable Neon Auth sign-in for an application so its login page is built and tested against real authentication, with users stored in the app’s Postgres.

Instructions

Switch on sign-in (Neon Auth) for this application now, while the project is still being written, so a login page is built and tested against the real thing instead of a library and a table of passwords of your own. The people who sign up are rows in a neon_auth schema of the application's own Postgres, so it makes the database first if there is none, and that counts against the plan's databases. Safe to call twice. Only for a project that has accounts: skip it otherwise, and skip it when the user already chose a service (Clerk, Auth0, Supabase Auth), or when the project connects to a database of its own: the answers are 409 own_auth and own_database. A 402 database_limit is not a rate limit, so do not retry, say what it says and let the user choose. If the call is refused or blocked, do not look for another route: tell the user. The cookie secret is not returned: call auth_env_to_file to put the variables in .env. In Next.js, install @neondatabase/auth and follow https://neon.com/docs/auth/quick-start/nextjs (a beta library, so that page is the source of truth for its code). Anywhere else it is Better Auth over HTTP at NEON_AUTH_BASE_URL: POST /sign-up/email and /sign-in/email, GET /get-session, and GET /token for a JWT that verifies against NEON_AUTH_JWKS_URL, every request carrying an Origin that is the application's own address. Localhost works while you build, and the platform registers the application's address and any custom domain itself. Sign-up and sign-in allow about nine attempts per ten seconds, then answer 429, so show a person a try-again message. Tell the user what was created and on which account.

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (openWorldHint=false, destructiveHint=false), the description discloses idempotency ('safe to call twice'), a real side effect (creates a database if none exists, consuming a plan database slot), rate limits (~nine attempts per ten seconds, 429), which error codes are terminal (402/409), and that the cookie secret is deliberately withheld. These are exactly the behavioral traits an agent cannot infer from 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 opening sentences are front-loaded with the core action and the key constraint (requires an existing project with accounts). The description is long and its later half drifts into HTTP endpoint and rate-limit detail, but for a zero-param tool with this much side-effect surface, most sentences still earn their place; the parenthetical style makes it slightly denser than ideal.

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?

With no output schema and a qualifying annotation set, the description covers everything an agent needs: prerequisites, side effects, idempotency, error semantics, secret handling, and the concrete next step (auth_env_to_file) plus framework-specific follow-up. Nothing material is left implicit.

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 tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The description adds no parameter-level information, but none is needed.

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 names a specific action (switching on sign-in / Neon Auth) and the resource it provisions (accounts stored in a neon_auth schema of the app's own Postgres). It is clearly distinguishable from siblings like auth_env_to_file, which it explicitly names as the follow-up step for retrieving secrets.

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 gives explicit when-to-use ('while the project is still being written'), explicit when-not-to-use (no accounts, user already chose Clerk/Auth0/Supabase Auth, project already has its own database), and maps those exclusions to concrete error answers (409 own_auth / own_database). It also states the correct response to failures: a 402 database_limit is not retryable, and refusals should be reported to the user rather than worked around.

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

Deploy Server

Other Tools