EQIQs

Get a person's profile

get_profile

Read-onlyIdempotent

Return the full 21-framework read for one saved person: results per framework with plain-language labels, strengths, and working-style notes. Provide exactly one of profile_id, email or name. Read-only; costs 1 unit.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`name`	No	Full name. Ambiguous names return a list to choose from rather than a guess.
`email`	No	The person's exact email.
`context`	No	Relationship context that sets framework weighting. 'business' (default) is work-safe and withholds personal-life signals (love language, attachment style, date of birth); the other contexts include them.	business
`profile_id`	No	Profile id from list_profiles (preferred).

Output Schema

TableJSON Schema

Name	Required	Description
`context`	No	Relationship context the profile was filtered for.
`profile`	No	The person's profile fields that are visible in this context.
`label_meanings`	No	Plain-language meanings for the framework labels on the profile.
`frameworks_total`	No	Total frameworks EQIQs uses (21).
`framework_coverage`	No	How many of the 21 frameworks have data.
`frameworks_withheld`	No	How many frameworks are hidden in this context (e.g. personal-life signals at work).

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 29, 2026

changedOutput schema / properties / frameworks_withheld / description

Previous value: -"Frameworks hidden in this context (e.g. personal-life signals at work)."New value: +"How many frameworks are hidden in this context (e.g. personal-life signals at work)."

removedOutput schema / properties / frameworks_withheld / items
```
Removed value: -{}
```
changedOutput schema / properties / frameworks_withheld / type
```
Previous value: -"array"New value: +"number"
```

Changed1 schema field changedSep 28, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "context": {
+      "description": "Relationship context the profile was filtered for.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "framework_coverage": {
+      "description": "How many of the 21 frameworks have data.",
+      "type": "number"
+    },
+    "frameworks_total": {
+      "description": "Total frameworks EQIQs uses (21).",
+      "type": "number"
+    },
+    "frameworks_withheld": {
+      "description": "Frameworks hidden in this context (e.g. personal-life signals at work).",
+      "items": {},
+      "type": "array"
+    },
+    "label_meanings": {
+      "additionalProperties": {
+        "$ref": "#/properties/profile/additionalProperties"
+      },
+      "description": "Plain-language meanings for the framework labels on the profile.",
+      "type": "object"
+    },
+    "profile": {
+      "additionalProperties": {},
+      "description": "The person's profile fields that are visible in this context.",
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

Changed6 schema fields changedSep 25, 2026

addedInput schema / properties / context / default
```
Added value: +"business"
```

changedInput schema / properties / context / description

Previous value: -"Relationship context. Business (default) withholds personal-life signals: love language, attachment style, date of birth."New value: +"Relationship context that sets framework weighting. 'business' (default) is work-safe and withholds personal-life signals (love language, attachment style, date of birth); the other contexts include them."

addedInput schema / properties / email / description
```
Added value: +"The person's exact email."
```
addedInput schema / properties / email / format
```
Added value: +"email"
```

addedInput schema / properties / name / description

Added value: +"Full name. Ambiguous names return a list to choose from rather than a guess."

addedInput schema / properties / profile_id / description

Added value: +"Profile id from list_profiles (preferred)."

Changed1 schema field changedSep 23, 2026

addedInput schema / properties / context

Added value: +{
+  "description": "Relationship context. Business (default) withholds personal-life signals: love language, attachment style, date of birth.",
+  "enum": [
+    "business",
+    "romantic",
+    "friendship",
+    "coparenting"
+  ],
+  "type": "string"
+}

First observedSep 1, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description still adds non-structured behavior by disclosing the cost ('costs 1 unit') and the one-identifier-at-a-time constraint. It does not describe error behavior for missing profiles or ambiguous names, keeping it short of a 5.

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?

Two sentences, no filler, with the core behavior front-loaded and the invocation constraint plus cost placed immediately after. Every clause carries information an agent needs.

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-value detail is unnecessary, and the description covers scope, identifier constraint, read-only nature and cost. The only real omission is guidance on how the context parameter alters results, but that is documented in the schema itself.

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 the exclusivity rule ('exactly one of profile_id, email or name') that the schema does not encode since required is 0. That constraint meaningfully extends the parameter documentation beyond what the structured fields provide.

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 and resource ('Return the full 21-framework read for one saved person') and even enumerates what the payload contains (per-framework results, plain-language labels, strengths, working-style notes). This clearly distinguishes it from siblings like list_profiles and get_my_profile.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description tells the agent it must supply exactly one of profile_id, email or name, which is useful invocation guidance, but it never states when to reach for this tool versus get_my_profile, list_profiles, or prep_meeting. Usage is implied by the resource rather than explained.

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?