Skip to main content
Glama
Sign In

Fastero

by com.fastero
OverviewDiscussionsAdmin

Invite to project

fastero_invite_to_project
Destructive

Ask to invite someone by email to view a project. No email is sent by this call: the invite waits until a signed-in Owner or Admin of the organisation confirms it at confirmUrl, a page in Fastero that names the address, the project and the organisation and says they will be able to view every project in the organisation. Confirming sends the invitation, whose link then works for 7 days; unconfirmed, the request lapses after 7 days. Accepting makes them a Viewer of the whole organisation, able to open every project in it, not only this one. Someone already in the organisation is added to the project at once instead, keeps their role, and is sent nothing. Use it for people who should sign in to Fastero; for a link anyone can open without an account, use fastero_share_dashboard. Needs an Owner or Admin role in the organisation. An address with an invite already open in this project is refused (409), and so is a request once 20 asked for in the same person's name await confirmation (429); requests do not count against the 20 invitation emails a person may send a day, but confirming one does. Returns inviteId and status: 'awaiting_confirmation' with confirmUrl and expiresAt, or 'added' for someone already in the organisation.

Input Schema

NameRequiredDescriptionDefault
appIdNoThe Streamlit app they land on when they accept: an app’s id, from fastero_list_streamlit_apps.
emailYesThe address the invitation goes to, exactly as the person uses it. The confirmation page shows it to whoever confirms, before anything is sent.
projectIdYesThe project to invite them to: its id, from fastero_list_projects.
dashboardIdNoThe dashboard they land on when they accept: a dashboard’s id, from fastero_list_dashboards.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Far beyond what the annotations provide: it discloses the two-phase confirmation flow, that no email is sent by the call, the 7-day expiry for both confirmation and link validity, escalation to organisation-wide Viewer access, the immediate-add path for existing members, and the 409/429 failure conditions with their rate-limit accounting. These are exactly the mutation consequences destructiveHint=true and openWorldHint=true imply but do not explain.

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 is front-loaded and every clause carries operational weight, but the middle section packs many facts (access scope, membership shortcut, rate limits, return shape) into one dense run-on, which reduces scannability slightly.

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?

No output schema exists, yet the description documents the return payload (inviteId, status, confirmUrl, expiresAt, 'added'). For a mutation tool with 4 parameters, annotations, and no output schema, it supplies everything an agent needs to call and interpret it.

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 the baseline is 3, but the description adds real meaning beyond it: what the email parameter triggers at confirmation (shown to the confirmer before anything sent) and the observable outcome (inviteId plus 'awaiting_confirmation'/'added' status). The appId and dashboardId landing targets are left to the schema, which is acceptable.

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 first sentence states a specific verb and resource ("Ask to invite someone by email to view a project") and the description names the sibling it is not (fastero_share_dashboard), so an agent can distinguish it from the share-link tool immediately.

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 names when to use it ("people who should sign in to Fastero") and the alternative with its condition ("for a link anyone can open without an account, use fastero_share_dashboard"), plus the role prerequisite (Owner or Admin). Nothing is left to inference.

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

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