Skip to main content
Glama
Sign In
Fulcra MCP Server

Fulcra MCP Server

by fulcradynamics
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Create Agent Invitation

create_agent_invitation
Destructive

Create a Fulcra invitation to share with another person so their agents can connect, returning the invitation text and saved details without sending or connecting.

Instructions

Create a Fulcra invitation the user can share with another person to connect their agents. Returns full invitation_text and saved details. Does not send or connect. With authorized delivery, use send_agent_message with the returned text.

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": {
      "inviter_name": "<inviter_name>",
      "recipient_name": "<recipient_name>"
    },
    "name": "create_agent_invitation"
  }
}

Input Schema

NameRequiredDescriptionDefault
inviter_nameYesThe user's name.
recipient_nameYesThe invited person's name.
recipient_useridNoOptional exact Fulcra user ID; shares only the invitation outbox with that user immediately.

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.19.8
    • changedInput schema / properties / recipient_userid / description
      Previous value: -"Optional exact Fulcra user ID of the invited person."New value: +"Optional exact Fulcra user ID; shares only the invitation outbox with that user immediately."
  2. Addedv1.18.7

TDQS

A4.3/5.0
Behavior4/5

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

Against annotations that only say readOnlyHint=false, openWorldHint=true, destructiveHint=true, the description adds real context: the call persists an invitation and returns invitation_text plus saved details, and it deliberately does not perform delivery. It does not explain why destructiveHint is true for a create operation, nor whether recipient_userid causes an immediate share as the schema implies, leaving the risk profile partly unexplained.

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?

Four short sentences: purpose first, return shape second, non-behavior third, routing fourth. Every sentence carries distinct information and nothing is repeated from the schema or annotations.

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?

An output schema exists so return values need not be re-explained, and the description still gives the useful hint that invitation_text is the key artifact. Complete for invocation purposes, with only the missing sibling differentiation and the unexplained destructive flag keeping it below a 5.

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?

Schema description coverage is 100% and all three parameters carry their own explanations, including the subtle behavior of recipient_userid sharing the outbox immediately. The description correctly does not duplicate that text, so the schema carries parameter meaning as intended.

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 names a specific verb and resource ("Create a Fulcra invitation") plus the domain purpose ("share with another person to connect their agents"). It implicitly separates itself from send_agent_message by stating it does not send, but it never distinguishes itself from the closely named siblings prepare_agent_invitation and prepare_standing_agent_invitation, which an agent would plausibly confuse it with.

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?

"Does not send or connect. With authorized delivery, use send_agent_message with the returned text" gives explicit downstream routing and a clear boundary on this tool's scope. What is missing is any guidance on when to prefer this tool over prepare_agent_invitation or prepare_standing_agent_invitation, which is the most likely mis-selection risk given the sibling list.

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

Deploy Server

Other Tools