EQIQs

Score a team

score_team

Read-onlyIdempotent

Score a whole group in one call: every pairing is rolled up into a team cohesion score (visual card), the weakest shared dimension, the best-connected person, who is most isolated, pairings to watch (<55) and anchor pairings (75+), and the role mix with what is missing. Use instead of looping score_compatibility for 3+ people. Decision-support only. Read-only; costs 2 units.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`label`	No	Optional group name echoed in the summary.
`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
`members`	No	Profile ids or full names of the people in the group (2-12). Omit when using department.
`department`	No	Use everyone tagged with this department instead of naming members. Exact match first; refuses and asks for names if more than 12 people match or the name spans several departments.

Output Schema

TableJSON Schema

Name	Required	Description
`label`	No	Team or department name.
`pairs`	No	Every pairing and its score.
`context`	No	Relationship context used.
`members`	No	Each member with their average fit.
`connector`	No	Best-connected member.
`thin_data`	No	Members with too little data for a reliable read.
`disclaimer`	No	Decision-support disclaimer.
`pair_count`	No	Pairings scored.
`watch_pairs`	No	Pairings that need care.
`anchor_pairs`	No	Strongest pairings.
`member_count`	No	People in the team.
`most_isolated`	No	Member furthest from the rest.
`role_coverage`	No	Mix of working-style roles, counting each person once.
`cohesion_score`	No	Team cohesion, 0-100.
`weakest_subscore`	No	The team's weakest shared dimension.
`subscore_averages`	No	Average score per dimension across the team.

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": {
+    "anchor_pairs": {
+      "description": "Strongest pairings.",
+      "items": {
+        "$ref": "#/properties/members/items"
+      },
+      "type": "array"
+    },
+    "cohesion_score": {
+      "description": "Team cohesion, 0-100.",
+      "type": "number"
+    },
+    "connector": {
+      "description": "Best-connected member."
+    },
+    "context": {
+      "description": "Relationship context used.",
+      "type": "string"
+    },
+    "disclaimer": {
+      "description": "Decision-support disclaimer.",
+      "type": "string"
+    },
+    "label": {
+      "description": "Team or department name.",
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "member_count": {
+      "description": "People in the team.",
+      "type": "number"
+    },
+    "members": {
+      "description": "Each member with their average fit.",
+      "items": {
+        "additionalProperties": {
+          "$ref": "#/properties/subscore_averages/additionalProperties"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "most_isolated": {
+      "description": "Member furthest from the rest."
+    },
+    "pair_count": {
+      "description": "Pairings scored.",
+      "type": "number"
+    },
+    "pairs": {
+      "description": "Every pairing and its score.",
+      "items": {
+        "$ref": "#/properties/members/items"
+      },
+      "type": "array"
+    },
+    "role_coverage": {
+      "description": "Mix of working-style roles, counting each person once."
+    },
+    "subscore_averages": {
+      "additionalProperties": {},
+      "description": "Average score per dimension across the team.",
+      "type": "object"
+    },
+    "thin_data": {
+      "description": "Members with too little data for a reliable read."
+    },
+    "watch_pairs": {
+      "description": "Pairings that need care.",
+      "items": {
+        "$ref": "#/properties/members/items"
+      },
+      "type": "array"
+    },
+    "weakest_subscore": {
+      "description": "The team's weakest shared dimension."
+    }
+  },
+  "type": "object"
+}

Changed9 schema fields changedSep 25, 2026

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

addedInput schema / properties / context / description

Added 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."

changedInput schema / properties / department / description

Previous value: -"Score everyone in this department instead of naming members."New value: +"Use everyone tagged with this department instead of naming members. Exact match first; refuses and asks for names if more than 12 people match or the name spans several departments."

addedInput schema / properties / department / maxLength
```
Added value: +100
```

addedInput schema / properties / label / description

Added value: +"Optional group name echoed in the summary."

addedInput schema / properties / label / maxLength
```
Added value: +80
```

changedInput schema / properties / members / description

Previous value: -"Profile ids or names (2-12)."New value: +"Profile ids or full names of the people in the group (2-12). Omit when using department."

addedInput schema / properties / members / maxItems
```
Added value: +12
```
addedInput schema / properties / members / minItems
```
Added value: +2
```

AddedSep 23, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds the non-obvious cost ('2 units'), the 'decision-support only' caveat, and the department parameter's refusal behavior. It does not cover auth/permission requirements or pagination/limits, but the added cost and caveat context is real value beyond structured fields.

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?

Front-loaded with the core action and then a dense enumeration of outputs, with the alternative and cost trailing. Every clause carries information, though the output enumeration runs long enough that a reader must parse carefully.

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?

An output schema exists and annotations cover safety, yet the description still supplies the decision-support caveat, unit cost, sibling alternative, and the shape of the result. Nothing an agent needs in order to select and call this correctly is missing.

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 description coverage is 100%, so the schema already documents label, context, members, and department, including the enum semantics of context and the 2-12 bound. The description adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 ('score a whole group') and enumerates exactly what the rollup contains: cohesion score, weakest shared dimension, best-connected/isolated members, pairings to watch, anchor pairings, role mix gaps. It also explicitly contrasts itself with the sibling score_compatibility, so an agent can route without opening schemas.

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?

'Use instead of looping score_compatibility for 3+ people' gives an explicit alternative plus the numeric threshold that selects it. The schema reinforces member-vs-department selection, and the 'decision-support only' framing sets expectations about how results should be used.

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?