Skip to main content
Glama
Sign In

Tessryx

by io.tessryx
OverviewDiscussionsAdmin

Invite visitor

invite_visitor

Invite someone by email to this workspace's private pages, and only those: a visitor is a member with the Visitor role, who never sees the console, these tools or the workspace's resources, and takes no seat. Tessryx sends no email. Give the person the link to a page whose endpoint lists ROLE_VISITOR in auth.allow.tenant_roles; they sign in or sign up with this address and accept on one screen. tenant_roles is an exact match: list every role that should get in, e.g. ["ROLE_VISITOR", "ROLE_OWNER", "ROLE_ADMIN"], or the owner is shut out of their own page. Pass sites to admit them to some of the workspace's sites only (a folder, an app, or a custom domain): when the workspace runs more than one site, such as one per client, always pass the sites the person is for. Without sites they may see every members-only page that admits visitors. Refused if the address is already on the team, already a visitor (change their sites with set_visitor_sites), or already invited, and past the plan's visitor limit (pending invites count).

Input Schema

NameRequiredDescriptionDefault
emailYesThe person's email address. They must sign in with exactly this address to accept.
sitesNoThe sites this person is for, each one folder, app or domain. Omit for all of the workspace's sites.

Output Schema

NameRequiredDescriptionDefault
emailYes
sitesYes
all_sitesYes
created_atYes
invited_by_user_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / sites
      Added value: +{
+  "description": "The sites this person is for, each one folder, app or domain. Omit for all of the workspace's sites.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "app": {
+        "description": "An app's slug: the members-only pages its published definition selects.",
+        "type": "string"
+      },
+      "domain": {
+        "description": "A custom domain the workspace serves, such as 'portal.acme.com': stored as the folder it serves today.",
+        "type": "string"
+      },
+      "folder": {
+        "description": "A folder: members-only pages whose address is under it, such as 'clients/acme'.",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": "array"
+}
    • addedOutput schema / properties / all_sites
      Added value: +{
+  "type": "boolean"
+}
    • addedOutput schema / properties / sites
      Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "app": {
+        "type": "string"
+      },
+      "folder": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "type": [
+    "null",
+    "array"
+  ]
+}
    • changedOutput schema / required
      Previous value: -[
-  "email",
-  "invited_by_user_id",
-  "created_at"
-]New value: +[
+  "email",
+  "invited_by_user_id",
+  "created_at",
+  "all_sites",
+  "sites"
+]
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false, idempotentHint=false and destructiveHint=false; the description adds material behavior the annotations cannot: no email is sent by the system, the invitee must accept via a page whose endpoint lists ROLE_VISITOR in auth.allow.tenant_roles, tenant_roles is an exact match (omitting the owner would shut them out), and pending invites count against the plan limit. The non-idempotent hint is consistent with "refused if... already invited" — no contradiction.

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 core action and its scope are front-loaded in the first clause, and every sentence carries operational weight. It is nonetheless a single dense block for a two-parameter tool, with the tenant_roles aside sitting between the invite step and the sites guidance, which slightly disrupts reading order.

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?

An output schema exists, so return values need no explanation; the description instead covers what an agent could get wrong — email exactness, the acceptance flow, the tenant_roles requirement, site scoping, and all refusal cases. Nothing needed to invoke this correctly is missing.

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?

Schema coverage is 100%, so baseline is 3, and the description rises above it by explaining the consequence of omitting sites ("they may see every members-only page that admits visitors") and the operational rule for choosing sites per client. The tenant_roles exact-match warning adds real acceptance-failure context that the schema cannot express, though some of the sites guidance overlaps the schema's own descriptions.

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?

Opens with a specific verb and resource ("Invite someone by email to this workspace's private pages") and immediately scopes it to private pages only, defining the resulting entity as "a member with the Visitor role." That definition alone distinguishes it from set_member_scope, create_app, and the other siblings.

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?

Explicitly names the alternative for a related task ("change their sites with set_visitor_sites") and states the conditions under which the call is refused: already on the team, already a visitor, already invited, or past the plan's visitor limit. It also tells the agent to always pass sites when the workspace runs more than one site, which is a concrete when-to-use rule rather than an implication.

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

All Tessryx 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