wisdom_score_previewShare a recent fight, what your partner may have felt, and what you could do differently for one non-numeric Wisdom Score insight.
| Name | Required | Description | Default |
|---|---|---|---|
| responses | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the result is a single non-numeric insight, which is useful but does not go deeply into behavior beyond that.
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 description is a single, concise sentence that front-loads the input requirements and the output type. Every part contributes to understanding how to use the tool, with no filler or redundancy.
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 simple one-parameter, read-only tool without an output schema, the description is largely complete: it explains the expected input and the nature of the output. It could add more context about what a 'Wisdom Score insight' is or how to route between sibling tools, but those are not critical gaps.
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?
Even though schema description coverage is 0%, the description compensates fully for the single 'responses' parameter by specifying exactly what the user should share: a recent fight, what the partner may have felt, and what could be done differently. This adds clear meaning beyond the raw schema.
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 clearly states what the tool does: it takes a recent fight, the partner's likely feelings, and an alternative action, and returns one non-numeric Wisdom Score insight. This is a specific action and resource, though it does not explicitly differentiate the tool from sibling relationship tools.
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?
The description implies usage context: use this when you have a recent fight and want a 'quick read' or preview insight rather than a full assessment. However, it does not explicitly say when to choose this tool over alternatives like get_relationship_assessment or ask_relationship_expert.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool serves a clearly distinct purpose: general Q&A, finding a therapist, taking an assessment, naming conflict patterns, providing immediate repair steps, and offering wisdom score insights. There is no overlap in functionality, so an agent can select the right tool without ambiguity.
All tool names follow the consistent verb_noun snake_case pattern (ask_, find_, get_, name_, repair_, wisdom_score_preview). The verbs are varied but each clearly indicates the action, and the pattern is uniform across the set.
With 6 tools, the server is well-scoped for a relationship expert domain. Each tool covers a distinct aspect of relationship guidance without excess or redundancy, making the count appropriate for both usability and maintainability.
The tool surface covers core relationship needs: general advice, therapist matching, assessment, conflict analysis, immediate repair, and personalized insight. The only minor gap is the lack of a tool for scheduling sessions or accessing broader educational resources, but the existing set addresses the primary lifecycle without significant dead ends.