Skip to main content
Glama
EQIQs

@eqiqs/mcp-server

Official
by EQIQs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Invite someone to compare

invite_person

Create a private invite link so someone can take the EQIQs assessment and share results with you. Optionally email the link or return it to hand over directly.

Instructions

Create a private invite link for someone to take the EQIQs assessment and compare with the user. Finishing the assessment is their consent to share results. Optionally emailed by EQIQs; otherwise the link is returned to hand over. Limited to 10 invites per hour; no self-invites or opted-out addresses. Costs 1 unit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoInvitee's name, shown in the invite.
emailNoInvitee's email, when they are not saved yet.
personNoExisting saved person to invite (optional if email is given). Accepts a profile id, an exact email, or a full name. If a name matches more than one person the tool asks which one instead of guessing.
send_emailNotrue: EQIQs emails the link. false: only return the link.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changedv0.1.1
    • addedInput schema / properties / email / description
      Added value: +"Invitee's email, when they are not saved yet."
    • addedInput schema / properties / email / format
      Added value: +"email"
    • addedInput schema / properties / name / description
      Added value: +"Invitee's name, shown in the invite."
    • addedInput schema / properties / name / maxLength
      Added value: +120
    • addedInput schema / properties / person / description
      Added value: +"Existing saved person to invite (optional if email is given). Accepts a profile id, an exact email, or a full name. If a name matches more than one person the tool asks which one instead of guessing."
    • addedInput schema / properties / send_email / default
      Added value: +true
    • addedInput schema / properties / send_email / description
      Added value: +"true: EQIQs emails the link. false: only return the link."
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (readOnlyHint=false), the description adds key behavioral details: consent is established upon completion of the assessment, rate limit and cost, and disambiguation behavior when a name matches multiple people. This substantially exceeds the annotation-only information.

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?

The description is three sentences, leading with the primary purpose and then relevant constraints. Every sentence contributes new information—consent, email option, rate limit, cost—with no redundant phrasing.

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 tool with no output schema, the description adequately explains the return behavior: the link is returned when send_email is false. It also covers the main usage conditions and limitations. The description is sufficiently complete for an agent to select and invoke the tool correctly.

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?

The input schema already has 100% coverage with descriptive fields. The tool description adds meaning beyond the schema, particularly for the 'person' parameter (it asks which one if multiple matches) and for 'email' (no self-invites or opted-out addresses). With full schema coverage, a baseline of 3 is used, and the extra context justifies a 4.

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 action ('Create a private invite link') with a clear resource (someone to take the EQIQs assessment) and outcome (compare with the user). It is easily distinguished from siblings like list_invites, which lists invites rather than creating them.

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 provides conditional guidance such as whether the link is emailed or returned, and notes constraints (10 invites/hour, no self-invites, no opted-out addresses, costs 1 unit). It doesn't explicitly name alternatives, but no sibling tool performs the same function, so the context is sufficient.

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