Turns a list of people and relationships into a genogram with the standard symbols.
Scored across 2 tools
The two tools split cleanly along validate-vs-render lines: check_genogram explicitly 'draws nothing and makes no files' while make_genogram produces the chart and downloads. Descriptions reinforce the boundary by telling the agent to run check first, so misselection is unlikely.
Both names follow the same verb_noun convention (check_genogram, make_genogram) on the same object noun, which is fully predictable. Even the shared suffix signals that the pair operate on the same input shape.
Two tools is thin for a whole server, even a narrow one, and there is no separate operation for simpler needs like listing generations or converting data without a full draw. Still, the split is principled rather than arbitrary, so it is borderline rather than badly scoped.
The pair covers the natural lifecycle for a stateless diagram service: validate the family data, then render it with geometry checks, legend, and CSV/PDF/SVG output. Gaps are minor (no explicit way to repair or re-emit corrected input, and health/medical data is out of scope by design), so agents can work around them.
Use this when the user wants a family list checked before drawing a genogram, for example "check my genogram data for mistakes" or "which generation is each person in". Takes the same people, relations and household as make_genogram. Returns the problems found (unknown or duplicate ids, a person who is their own ancestor with the cycle named, more than 2 biological parents, a parent who is not older than the child, couple years outside a partner's life, twins with different parents, too many generations; above 150 people it checks the first 150 and names the people left out), warnings, and each person's generation number when the data is consistent. Draws nothing and makes no files. Relationships only: it does not take health or medical details.
| Name | Required | Description | Default |
|---|---|---|---|
| people | Yes | The people, up to 150. Example: [{"id":"p1","name":"Jan","sex":"M","birth_year":1950},{"id":"p2","name":"Ewa","sex":"F","birth_year":1952},{"id":"p3","name":"Ola","sex":"F","birth_year":1980,"index":true}]. | |
| household | No | Ids of the people who live together; drawn with a dashed outline, e.g. ["p2","p3"]. | |
| relations | No | The relationships, up to 600 (at most 150 couples and 100 emotional). Example: [{"type":"couple","a":"p1","b":"p2","kind":"married","start_year":1975},{"type":"parent_child","a":"p1","b":"p3"},{"type":"parent_child","a":"p2","b":"p3"}]. |
| Name | Required | Description |
|---|---|---|
| ready | Yes | |
| shown | No | |
| counts | Yes | |
| issues | Yes | |
| limits | Yes | |
| people | Yes | |
| generation_rule | Yes | |
| people_left_out | No | |
| people_left_out_count | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them by enumerating every category of problem reported (unknown or duplicate ids, self-ancestry with cycle named, >2 biological parents, parent not older than child, couple years outside a partner's life, twins with different parents, too many generations). It also discloses the 150-person cap and the truncation behavior that names omitted people, which an agent could not infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded, followed by input equivalence, output contents, and negative scope. The problem enumeration is long but each clause adds distinct information; a bulleted list would be more scannable, but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with 100% schema coverage, annotations, and an output schema, the description covers trigger, alternatives, checks performed, limits, and side-effect absence. An agent has everything needed to decide to call it and to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already carries field-level meaning and the baseline is 3. The description adds a real semantic constraint beyond the schema: it accepts the same people/relations/household as make_genogram but explicitly excludes health or medical details, which matters because the schema permits additional properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('a family list checked before drawing a genogram') and immediately differentiates from the sibling: 'Draws nothing and makes no files' versus make_genogram, which draws. The quoted user phrasings ('check my genogram data for mistakes') anchor the intent unambiguously.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states exactly when to use it (before drawing a genogram) and implies the alternative by contrasting with make_genogram, which takes the same inputs. It also sets explicit scope boundaries: relationships only, no health or medical details, no files or drawings produced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user wants a genogram or family diagram with standard symbols drawn from people and their relationships, for example "draw a genogram of my family" or "make a three-generation genogram for my social work class". Takes people (id, name, sex, birth and death years, deceased, index person; no label or notes), relations (couple: married, divorced, separated, cohabiting, engaged; parent_child: biological, adopted, foster; twins: identical, fraternal; emotional: close, distant, conflict, cut_off, hostile), an optional household, a title and a page size. Returns counts, each person's generation number, a geometry check (overlapping symbols or names, family lines through a name), the legend of symbols used, an interactive chart, and PDF, SVG, people CSV and relationships CSV downloads. An emotional relationship is drawn as a line only between two people next to each other in the same row; all others, including any between a parent and a child, are listed in a "Relationships not drawn" table and are not in the legend. Refuses unknown ids, parent cycles, more than 2 biological parents and impossible years, naming the problem. Up to 150 people, 12 generations and 100 emotional relationships. Relationships only: does not take health or medical details. Download links of large charts expire after about 1 hour.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Title printed on the chart and used in file names, up to 80 characters, e.g. "Kowalski family". | |
| people | Yes | The people, up to 150. Example: [{"id":"p1","name":"Jan","sex":"M","birth_year":1950},{"id":"p2","name":"Ewa","sex":"F","birth_year":1952},{"id":"p3","name":"Ola","sex":"F","birth_year":1980,"index":true}]. | |
| household | No | Ids of the people who live together; drawn with a dashed outline, e.g. ["p2","p3"]. | |
| page_size | No | PDF page: letter (default), a4, tabloid, a3 or a2. One page when the whole chart fits with text of at least 6 pt; else the chart prints in overlapping parts at full size. | |
| relations | No | The relationships, up to 600 (at most 150 couples and 100 emotional). Example: [{"type":"couple","a":"p1","b":"p2","kind":"married","start_year":1975},{"type":"parent_child","a":"p1","b":"p3"},{"type":"parent_child","a":"p2","b":"p3"}]. |
| Name | Required | Description |
|---|---|---|
| Yes | ||
| shown | No | |
| title | Yes | |
| checks | Yes | |
| counts | Yes | |
| legend | Yes | |
| people | Yes | |
| warnings | Yes | |
| downloads | Yes | |
| generation_rule | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses the validation rules (unknown ids, parent cycles, >2 biological parents, impossible years) and that errors name the problem, hard limits (150 people, 12 generations, 100 emotional relationships), the drawing rule that emotional lines only appear between adjacent same-row people, the resulting "Relationships not drawn" table, and that large-chart download links expire after about an hour.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Usage guidance and examples are front-loaded, and every sentence carries operational information. The single dense paragraph with long parenthetical enumerations makes it harder to scan than it needs to be, and the return-value sentence partly duplicates the output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, nested relation objects, and hard caps, the description covers inputs, refusals, limits, rendering caveats and output artifacts. An output schema exists, yet the description's brief return summary costs little and leaves nothing an agent needs unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3; the description adds value by enumerating the full vocabulary for relations and kinds and by stating "no label or notes" on people, which is not visible in the schema (additionalProperties is open). It stops short of explaining interaction between fields such as household membership or start/end year semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific trigger condition ("when the user wants a genogram or family diagram with standard symbols") plus two concrete example requests, and immediately states what the tool produces. An agent can tell this renders a chart rather than merely validating one, which is the plausible confusion with the sibling check_genogram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use phrasing and example utterances, and adds a real exclusion ("Relationships only: does not take health or medical details"). It does not name the sibling check_genogram or state when to prefer it, so the alternative-selection guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_genogrammake_genogramTurns a short text description of classes into a UML class diagram you can print.
Turns SQL CREATE TABLE statements into an entity relationship diagram you can print.
Org charts from a team list
Add one secure layer between your agents and this server.