Hustle Got Real

Post Virtualassistants Invite

hgr_post_virtualassistants_invite

Destructive

Dedicated HGRApi tool for POST api/VirtualAssistants/Invite. This is an explicit tool with a fixed endpoint; it is not a generic endpoint caller. HGRApi functional documentation: Purpose: Sends a single-use, seven-day email invitation; a changed email or reinvitation withdraws previous access until acceptance. ownerAgent: account-metrics. Use when: Invite a new VA, enable a historical profile, change the verified recipient or resend an invitation. Input: Optional profile Id, Name, Email, Stores with exact owned ChannelOAuthId and permission codes, Language. Resending requires the exact existing Id; omitting Id never reuses an existing profile. Output: Saves the relationship and sends the email; never sets or returns a password. Returns 400 with va_owner_email for the owner's email or va_email_already_used for an email assigned to another VA, ignoring case and surrounding whitespace. Maximum 3 active or invited VAs per account; acquiring another slot returns 409 va_profile_limit. Existing access is not automatically revoked. Maximum 3 distinct recipient emails per rolling 24 hours, including removed, suspended or revoked profiles and previous addresses of edited profiles. After the initial invitation, only 1 resend per recipient per rolling 24 hours. Email limits return 429 va_distinct_email_limit or va_invitation_resend_limit with Retry-After and retryAfterSeconds. Saved attempts count even when delivery fails. Limit rejections preserve the profile, permissions and existing invitations and send no email. Search terms: virtualassistants invite. Send the exact request payload in body. Requires confirmed=true before execution.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "body": "<body>",
      "confirmed": "<confirmed>"
    },
    "name": "hgr_post_virtualassistants_invite"
  }
}

Input Schema

Name	Required	Description	Default
`body`	Yes	HGRApi POST /api/VirtualAssistants/Invite request body.
`confirmed`	Yes	Must be true after the user explicitly requested or confirmed the exact action.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 5, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Far exceeds what the annotations provide (destructiveHint=true, idempotentHint=false, openWorldHint=true). It discloses the three-VA-per-account cap with 409 va_profile_limit, the three-distinct-emails and one-resend-per-recipient rolling 24-hour limits with 429 and Retry-After/retryAfterSeconds, that saved attempts count even on delivery failure, that limit rejections preserve profile and invitations, that existing access is not auto-revoked, and that no password is ever set or returned.

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 purpose and use-when conditions are front-loaded, and nearly every sentence carries operational information (limits, error codes, idempotency caveats). It nonetheless reads as a dense wall of text with some boilerplate ('Dedicated HGRApi tool', 'not a generic endpoint caller', 'Search terms: virtualassistants invite') that a structured layout would absorb more cheaply.

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 destructive, non-idempotent write tool with a nested, undocumented body object, the description supplies everything needed to call it correctly: preconditions (confirmed=true), payload shape, resend-vs-create semantics, quota behavior, and error signals. Return values need not be covered since an output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema documents both parameters at 100%, its body description is a content-free stub ('HGRApi POST /api/VirtualAssistants/Invite request body'). The description compensates by enumerating the payload fields (profile Id, Name, Email, Stores with exact owned ChannelOAuthId and permission codes, Language), the rule that resending requires the exact existing Id, and that omitting Id never reuses a profile, plus confirmed=true gating.

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 verb and resource: 'Sends a single-use, seven-day email invitation' to a Virtual Assistant, and pins the exact endpoint POST api/VirtualAssistants/Invite. It also explicitly distances itself from generic callers and is clearly distinguishable from siblings like hgr_post_virtualassistants_acceptinvitation, hgr_post_virtualassistants_permissions, or hgr_update_virtual_assistant.

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?

'Use when: Invite a new VA, enable a historical profile, change the verified recipient or resend an invitation' gives concrete trigger conditions, including the subtle resend/change-recipient cases. It does not name sibling alternatives or state when-not to use it beyond 'not a generic endpoint caller', which keeps it just below the top band.

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

All Hustle Got Real tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?