Skip to main content
Glama
EQIQs

@eqiqs/mcp-server

Official
by EQIQs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Write a coaching narrative

generate_narrative
Read-only

Write a plain-language coaching narrative for one person or a pair by synthesizing 21 frameworks. Select business context to keep insights limited to working behavior.

Instructions

Premium: write a plain-language coaching narrative for one person, or for a pair when compare_with is given, synthesized from all 21 frameworks. Business context stays on working behavior only. Slower than other tools. Costs 5 units.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
focusNoOptional topic to emphasize, e.g. 'giving feedback'.
lengthNoApproximate length of the narrative.standard
personYesWho the narrative is about. 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.
contextNoRelationship 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
audienceNoWho will read it. Hiring or candidate-screening audiences are intentionally not supported.manager
compare_withNoOptional second person for a pair narrative. 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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed12 schema fields changedv0.1.1
    • addedInput schema / properties / audience / default
      Added value: +"manager"
    • changedInput schema / properties / audience / description
      Previous value: -"Who the narrative is for. Hiring or candidate-screening audiences are intentionally not supported."New value: +"Who will read it. Hiring or candidate-screening audiences are intentionally not supported."
    • addedInput schema / properties / compare_with / description
      Added value: +"Optional second person for a pair narrative. 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 / 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."
    • addedInput schema / properties / context / enum
      Added value: +[
+  "business",
+  "romantic",
+  "friendship",
+  "coparenting"
+]
    • addedInput schema / properties / focus / description
      Added value: +"Optional topic to emphasize, e.g. 'giving feedback'."
    • addedInput schema / properties / focus / maxLength
      Added value: +200
    • addedInput schema / properties / length / default
      Added value: +"standard"
    • addedInput schema / properties / length / description
      Added value: +"Approximate length of the narrative."
    • addedInput schema / properties / length / enum
      Added value: +[
+  "short",
+  "standard",
+  "deep"
+]
    • addedInput schema / properties / person / description
      Added value: +"Who the narrative is about. 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."
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

The annotations already signal read-only and non-destructive behavior. The description adds useful behavioral context beyond the annotations: output is plain-language, synthesized from all frameworks, business context stays on working behavior only, and there are speed and cost tradeoffs. It does not contradict the annotations or claim any mutation.

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 tight sentences: purpose is front-loaded, the pair mode is noted, and the cost/speed caveats are summarized without extra prose. Every sentence contributes useful information and there is no redundant repetition of title or schema details.

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?

Given the tool's complexity, the description is complete enough for an agent to select and invoke it: it names the output form, identifies the required person input, explains the optional compare_with behavior, and gives the business-context restriction plus cost/speed tradeoff. There is no output schema, but the expected result is clearly stated as a plain-language narrative, so a richer return contract is not essential.

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?

The input schema already describes all 6 parameters, so schema description coverage is 100%. The description does not add per-parameter meaning beyond the schema; it only explains the pair behavior via compare_with, which is already stated in the parameter description. Baseline 3 is appropriate.

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 ('write a plain-language coaching narrative'), a clear resource scope ('for one person, or for a pair when compare_with is given'), and a distinctive method ('synthesized from all 21 frameworks'). This separates it from sibling tools like score_compatibility or list_profiles, which do different things.

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 clearly conveys when to use the tool: when a coaching narrative is needed for an individual or a pair, with compare_with enabling pair mode. The warning that it is 'Slower than other tools' and 'Costs 5 units' adds practical selection context, though it does not explicitly name alternative tools or state strict when-not-to-use conditions.

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