Fast.io

org

Destructive

Organization management: CRUD, billing, members, invitations, ownership transfer, assets, discovery. Call action='describe' for the full action/param reference. Destructive: close (permanently deletes org and all data).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Display name (3-100 chars).
`role`	No	Org permission level — `member` or `admin` ONLY. `owner` is not assignable (it is returned when READING members, alongside admin/member). `guest` and `view` are WORKSPACE/SHARE roles and are rejected here (1605).
`email`	No	Email address of user to invite.
`limit`	No	Page size.
`meter`	No	Meter type, e.g. storage_bytes, transfer_bytes, ai_tokens.
`state`	No	Invitation state, e.g. pending, accepted.
`token`	No	Transfer token for ownership claim.
`action`	Yes	Operation. Use 'describe' for full action reference.
`detail`	No	Per-entity verbosity for list/discover-/members/list-workspaces/details. Defaults: terse for list/discover-/members/list-workspaces, full for details. See action='describe' for per-level field lists.
`domain`	No	URL-safe subdomain (2-80 chars, lowercase alphanumeric + hyphens, globally unique, not reserved).
`offset`	No	Pagination offset (0-based).
`org_id`	No	Organization 19-digit ID or domain string.
`confirm`	No	Confirmation string, must match org domain or ID.
`content`	No	Plain text content. asset-upload: e.g. SVG body.
`expires`	No	Updated expiration datetime.
`message`	No	Custom invitation email message (10-255 chars).
`user_id`	No	User ID.
`end_time`	No	End datetime (default now).
`industry`	No	Industry type, e.g. technology, healthcare, financial.
`metadata`	No	Additional metadata as JSON array string.
`share_id`	No	Filter by share ID.
`token_id`	No	Transfer token ID.
`file_name`	No	Original file name, e.g. logo.png.
`member_id`	No	User ID or email of member.
`perm_join`	No	Permission level required to join workspace.
`asset_name`	No	Asset name, e.g. "logo", "banner".
`start_time`	No	Start datetime (default 30 days ago).
`description`	No	Description (10-1000 chars).
`domain_name`	No	Domain to check for availability.
`file_base64`	No	Base64 file content for binary assets.
`folder_name`	No	URL-safe workspace folder name (4-80 chars).
`join_action`	No	Invitation action: accept or decline (default accept). Appended to the join URL path — restricted to these two values to prevent path injection.
`permissions`	No	Updated permission level.
`twitter_url`	No	Twitter/X profile URL.
`youtube_url`	No	YouTube channel URL.
`accent_color`	No	Brand accent color as JSON.
`billing_plan`	No	Paid plan ID for billing-create, e.g. 'solo_monthly', 'business_v2_monthly', 'growth_monthly' (each has an annual variant). New orgs require a paid plan — free/agent plans are legacy and closed to new subscriptions; legacy 'pro_monthly'/'business_monthly' are also closed. Call billing-plans for the currently-offered plan IDs.
`content_type`	No	MIME type, e.g. image/png. Defaults to application/octet-stream.
`facebook_url`	No	Facebook page URL.
`homepage_url`	No	Organization website URL.
`intelligence`	No	Enable RAG indexing. COSTS 10 credits/page. Defaults "false". See describe.
`workspace_id`	No	Workspace opaque ID. Use this when only workspaces are valid (not shares or other contexts). For polymorphic contexts use profile_id. Filter by workspace ID.
`billing_email`	No	Billing contact email.
`display_limit`	No	Number of orgs to return to the agent (default 10, max 100). Backend page_size unchanged for cache warmth — applies to list. Trims post-fetch only.
`instagram_url`	No	Instagram profile URL.
`invitation_id`	No	Invitation ID or invitee email.
`owner_defined`	No	Custom owner-defined properties as JSON.
`invitation_key`	No	Invitation key from invite link.
`starting_after`	No	billing-invoices cursor: pass a prior invoice's `id` to fetch the next page (cursor pagination, not offset).
`use_background`	No	Enable/disable background, "true"/"false".
`background_mode`	No	Background display mode, e.g. 'stretched', 'fixed'.
`describe_action`	No	When action='describe', narrow the output to ONE action's full params/notes (e.g. 'list'). Omit to get the compact action index.
`background_color`	No	Background color as JSON.
`background_color1`	No	Primary background color as JSON.
`background_color2`	No	Secondary background color as JSON.
`perm_member_manage`	No	Who can manage members, e.g. 'Owner only'.
`perm_authorized_domains`	No	Authorized email domain for auto-join.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already flag destructiveHint=true, and the description adds a specific, high-impact behavioral warning: 'close (permanently deletes org and all data).' This is valuable context beyond the generic annotation. However, it does not elaborate on other potentially destructive actions like asset-delete or transfer-ownership, so it's not fully comprehensive.

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 two sentences, front-loaded with purpose and scope, ending with a critical destructive warning and a self-help pointer. Every sentence earns its place with zero fluff. It is appropriately sized for a high-level overview that delegates detail to the describe action.

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?

For a tool with 57 parameters, 40+ actions, and no output schema, this description is skeletal. It gives a high-level capability list and points to describe for the full reference, which is a useful workaround, but it does not cover return values, authentication, or action-specific side effects. The description relies heavily on the agent calling describe before use, which is acceptable but not fully complete.

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 100%, with each of the 57 parameters already having detailed descriptions. The tool description text itself adds no parameter-level semantics, so the baseline of 3 applies. It correctly points to action='describe' for deeper parameter details, but that is meta-guidance, not parameter semantics.

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?

The description clearly states the tool manages organizations, listing major capabilities (CRUD, billing, members, invitations, ownership transfer, assets, discovery). This is specific and avoids tautology, but it does not differentiate org from sibling tools like member, invitation, or workspace, which appear to be sub-features.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by listing the tool's broad scope, but gives no explicit guidance on when to use org versus sibling tools. The only hint is 'Call action='describe' for the full action/param reference,' which is a navigation aid rather than a decision rule. No alternatives or exclusions are mentioned.

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

All Fast.io 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

A4.1/5.0

Disambiguation5/5

Each tool covers a clearly distinct domain (auth, storage, shares, comments, events, AI, etc.), and overlapping concepts like share vs. fileshare are explicitly disambiguated with deprecation notes and cross-references. An agent can reliably select the correct tool for a task without ambiguity.

Naming Consistency3/5

Tool names are all lowercase single words, but they mix nouns (user, org, workspace) with verbs (download, find, upload) and include a hyphenated 'how-to'. There is no consistent verb_noun or noun-only pattern, though the names are still readable and memorable.

Tool Count4/5

19 tools is slightly above the typical 3-15 sweet spot, but the platform's breadth (auth, file management, sharing, collaboration, AI, metadata, and help) justifies this count. Each tool represents a substantial domain area, so none feel redundant.

Completeness5/5

The toolset provides full lifecycle coverage for the platform: authentication, user/org/workspace management, file storage/upload/download/search, sharing (both quickshare and durable file shares), comments, events, metadata pipelines, AI assistance, and product help. No obvious dead ends or missing operations are apparent.

Resources

Need Help?