Skip to main content
Glama

VibeDeploy

by be.vibedeploy
OverviewDiscussionsAdmin

Read plan, limits, and current usage

get_account
Read-onlyIdempotent

Return the team's plan, its limits, current usage, the trial end date and the per-token MCP rate limit. Call it before deploy_site or add_custom_domain to check a plan limit instead of running into PLAN_LIMIT_EXCEEDED.

Input Schema

NameRequiredDescriptionDefault

No arguments

Output Schema

NameRequiredDescriptionDefault
planYesPlan name. Current plans: Free (the 14-day trial), Solo, Maker, Studio, Business. Older accounts can show Freemium or Ultimate.
teamYes
usageYes
limitsYes
trialEndsAtYesISO timestamp when the 14-day trial of the team owner ends or ended, or null on a paid plan or without a trial. When a trial ends without a plan, the sites go offline and the files are kept for 30 days.
planExpiresAtYesISO timestamp when the current plan ends (trial-tier limits apply after it), or null if no end date is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / properties / usage / properties / customDomains / description
      Previous value: -"Currently attached custom domains across the team."New value: +"Distinct custom domains in use across the team: added with add_custom_domain or linked and bought in the dashboard."
  2. Changed5 schema fields changed
    • changedOutput schema / properties / limits / properties / mcpCallsPerHour / description
      Previous value: -"Per-token cap on total MCP tool calls. Live remaining headroom is also returned in the X-RateLimit-Remaining HTTP response header on every call."New value: +"MCP tool calls allowed per hour per token; the remaining count is in the X-RateLimit-Remaining header."
    • changedOutput schema / properties / plan / description
      Previous value: -"Effective plan name: Free, Solo, Freemium, Maker, Studio, Business, Ultimate."New value: +"Plan name. Current plans: Free (the 14-day trial), Solo, Maker, Studio, Business. Older accounts can show Freemium or Ultimate."
    • changedOutput schema / properties / planExpiresAt / description
      Previous value: -"ISO timestamp when the plan downgrades to Free, or null if no expiry set."New value: +"ISO timestamp when the current plan ends (trial-tier limits apply after it), or null if no end date is set."
    • addedOutput schema / properties / trialEndsAt
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "ISO timestamp when the 14-day trial of the team owner ends or ended, or null on a paid plan or without a trial. When a trial ends without a plan, the sites go offline and the files are kept for 30 days."
+}
    • changedOutput schema / required
      Previous value: -[
-  "plan",
-  "planExpiresAt",
-  "limits",
-  "usage",
-  "team"
-]New value: +[
+  "plan",
+  "planExpiresAt",
+  "trialEndsAt",
+  "limits",
+  "usage",
+  "team"
+]
  3. Changed1 schema field changed
    • removedOutput schema / properties / request_id
      Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}
  4. Changed1 schema field changed
    • changedOutput schema / properties / plan / description
      Previous value: -"Effective plan name: Free, Freemium, Maker, Studio, Business, Ultimate."New value: +"Effective plan name: Free, Solo, Freemium, Maker, Studio, Business, Ultimate."
  5. Changed1 schema field changed
    • addedOutput schema / properties / request_id
      Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}
  6. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context: what account information is returned and why an agent should check it before plan-limited operations. It stops short of richer details like auth requirements, but the output schema and annotations cover most of the remaining burden.

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. The return contents are front-loaded, followed by a concrete pre-call recommendation. No filler and every clause carries information.

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 zero-parameter, read-only account-info tool with annotations and an output schema, the description is complete. It states what is returned, when to call it, and the operational reason, leaving nothing essential for the agent to infer.

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?

This tool has zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and the description correctly does not waste space on nonexistent inputs.

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 uses a specific verb (Return) and names the exact resource and fields: team plan, limits, current usage, trial end date, and per-token MCP rate limit. This clearly distinguishes it from all sibling tools, which are deployment, domain, file, and site operations.

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 this before deploy_site or add_custom_domain to check a plan limit, and gives the concrete failure mode to avoid (PLAN_LIMIT_EXCEEDED). That is a direct when-to-use rule with named alternatives.

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

All VibeDeploy toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources