EQIQs

Add a person

create_profile

Add a new person to the user's workspace, optionally with traits already known (e.g. an MBTI type from a past assessment). Use invite_person instead when the person should take the assessment themselves. Returns the new profile id. Costs 1 unit.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	Yes	Full name (required).
`email`	No	Optional email; used to match results if they later take the assessment.
`eq_score`	No	Optional emotional-intelligence score 0-100.
`disc_type`	No	Optional DISC style: D, I, S, C or a blend such as DI.
`mbti_type`	No	Optional four-letter MBTI type, e.g. INTJ.
`department`	No	Optional team or department, used by score_team, prep_meeting and suggest_lead.
`date_of_birth`	No	Optional YYYY-MM-DD. Personal data: never used in business context.
`enneagram_type`	No	Optional Enneagram type 1-9, with wing if known, e.g. 3w2.
`attachment_style`	No	Optional. Personal data: never used in business context.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`profile`	No	The newly created profile.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "profile": {
+      "additionalProperties": {},
+      "description": "The newly created profile.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

Changed18 schema fields changedSep 25, 2026
- addedInput schema / properties / attachment_style / description
```
Added value: +"Optional. Personal data: never used in business context."
```
- addedInput schema / properties / attachment_style / maxLength
```
Added value: +40
```
- addedInput schema / properties / date_of_birth / description
```
Added value: +"Optional YYYY-MM-DD. Personal data: never used in business context."
```
- addedInput schema / properties / date_of_birth / format
```
Added value: +"date"
```
- addedInput schema / properties / department / description
```
Added value: +"Optional team or department, used by score_team, prep_meeting and suggest_lead."
```
- addedInput schema / properties / department / maxLength
```
Added value: +120
```
- addedInput schema / properties / disc_type / description
```
Added value: +"Optional DISC style: D, I, S, C or a blend such as DI."
```
- addedInput schema / properties / email / description
```
Added value: +"Optional email; used to match results if they later take the assessment."
```
- addedInput schema / properties / email / format
```
Added value: +"email"
```
- addedInput schema / properties / enneagram_type / description
```
Added value: +"Optional Enneagram type 1-9, with wing if known, e.g. 3w2."
```
- addedInput schema / properties / eq_score / description
```
Added value: +"Optional emotional-intelligence score 0-100."
```
- addedInput schema / properties / eq_score / maximum
```
Added value: +100
```
- addedInput schema / properties / eq_score / minimum
```
Added value: +0
```
- addedInput schema / properties / mbti_type / description
```
Added value: +"Optional four-letter MBTI type, e.g. INTJ."
```
- addedInput schema / properties / mbti_type / maxLength
```
Added value: +4
```
- addedInput schema / properties / name / description
```
Added value: +"Full name (required)."
```
- addedInput schema / properties / name / maxLength
```
Added value: +120
```
- addedInput schema / properties / name / minLength
```
Added value: +1
```
First observedSep 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare the mutation/safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower. The description adds genuinely new context — a cost of 1 unit and the fact that traits can be pre-seeded — though it does not warn that non-idempotent creation can produce duplicate profiles.

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?

Three tight sentences, front-loaded with the core action, then the disambiguation, then the return/cost facts. No filler.

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 9-param create tool with a full output schema and safety annotations, the description covers purpose, alternative, return id and cost. The only gap is duplicate-handling behavior implied by idempotentHint=false.

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% and each of the 9 parameters is documented in-schema, so the schema does the heavy lifting. The description only gestures at traits ('e.g. an MBTI type') without adding format or constraint detail beyond what the schema already states.

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?

States a specific verb+resource ('Add a new person to the user's workspace') and explicitly contrasts with the sibling invite_person, so an agent can distinguish the two without opening either schema.

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?

Gives an explicit routing rule: use invite_person instead when the person should self-assess. It also scopes the case where pre-known traits exist, so when-to-use and when-not-to-use are both covered.

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

All EQIQs tools Inspect

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

Need Help?