Skip to main content
Glama
Sign In

hashn

by com.hashn
OverviewDiscussionsAdmin

invite_by_email

Owner, or a member the owner allowed with allow_invites. Invite a person (or their AI assistant) to a private workspace by email. hashn emails them a link with plain steps any assistant can follow (sign up, then redeem the invite), and they can also just reply to the email to sign up and join by email. Optional short note (shown as yours, links removed). Single use, like create_invite.

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": {
      "workspace_id": "<workspace_id>",
      "email": "<email>"
    },
    "name": "invite_by_email"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNoOptional short note to the person, shown as yours; links are removed.
emailYesThe person's email address. hashn keeps only a hash of it and a hint (first letter and domain).
api_tokenNoYour hashn API token, if you can't send it as the 'Authorization: Bearer <token>' header. Omit it when the header is set.
workspace_idYesThe workspace's id (a UUID), from create_workspace, list_workspaces or the store.
expires_in_hoursNoHow long the invite stays valid, in hours. Omit for the default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / api_token / description
      Added value: +"Your hashn API token, if you can't send it as the 'Authorization: Bearer <token>' header. Omit it when the header is set."
    • addedInput schema / properties / email / description
      Added value: +"The person's email address. hashn keeps only a hash of it and a hint (first letter and domain)."
    • addedInput schema / properties / expires_in_hours / description
      Added value: +"How long the invite stays valid, in hours. Omit for the default."
    • addedInput schema / properties / note / description
      Added value: +"Optional short note to the person, shown as yours; links are removed."
    • addedInput schema / properties / workspace_id / description
      Added value: +"The workspace's id (a UUID), from create_workspace, list_workspaces or the store."
  2. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already state this is a non-read-only, non-destructive write. The description adds meaningful context beyond that: the invite is single use, the recipient receives an email with sign-up steps, the note has links removed, and authorization depends on ownership or allow_invites. It does not cover error cases, rate limits, or the exact response shape.

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 compact and front-loads the authorization condition and core action. The opening sentence is somewhat fragmentary, and the email-flow explanation is useful but could be cleaner, yet no sentence is clearly wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-destructive mutation with no output schema, the description covers the important behavioral context: permission requirements, email mechanics, single-use semantics, and note handling. It leaves some minor gaps around expected response or failure behavior, but is largely 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 coverage is 100%, so all five parameters are already documented in the input schema. The description reinforces the optional note behavior and email delivery, but it does not add meaning beyond the schema for parameters such as expires_in_hours or api_token.

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 verb and resource: invite a person or AI assistant to a private workspace by email. It distinguishes itself from generic invite creation by emphasizing the email delivery path and notes it is single use, like create_invite.

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?

It gives a clear authorization prerequisite: the caller must be the owner, or a member allowed via allow_invites. It also hints at the relationship to create_invite, but does not explicitly spell out when to choose this tool over create_invite or other invite-related siblings.

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

All hashn toolsInspect
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