Figs, Relationship Expert

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds "source-grounded" and "warm", useful tone/provenance cues, but says nothing about response shape, length, latency, or the fact that this is not clinical advice.

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?

A single tight sentence with the persona and topic scope front-loaded; every clause carries information, none is filler.

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 one-parameter read-only tool with rich annotations and no output schema, the description covers what the tool is and the domain it answers in. Missing only a note on answer format/citation behavior.

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?

One parameter with 0% schema description coverage; the description only implicitly defines it via the topic list, giving no guidance on phrasing, length, or whether context about the couple should be included. Partial compensation, not full.

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?

Specific verb ("Ask") plus named resource/persona (couples therapist Figs O'Sullivan) and an enumerated topic scope (love, conflict, trust, attachment, intimacy, repair). An agent can tell this is a Q&A/knowledge tool rather than an assessment or action tool, though it doesn't name a sibling to contrast with.

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 topic list implies when to use it (relationship questions on those themes), but there is no explicit guidance on when to prefer it over siblings like repair_right_now or name_conflict_pattern, which overlap in subject matter. Selection is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is well covered. The description adds geographic scope ('US state') and domain ('therapy or coaching option'), but does not describe what 'appropriate' means or what the result looks like beyond annotations.

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 definition is a single front-loaded sentence with no redundant or filler content. Every phrase contributes to purpose and scope.

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 two-parameter read tool with rich safety annotations, the description covers the core matching intent and geographic scope. However, it leaves gaps around parameter formatting and return behavior, which are not covered by an output schema or schema descriptions.

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 0%, so the description must compensate for both parameters. It clarifies that 'state' means a US state and 'concern' means a relationship concern, but it gives no format details, allowed values, or whether either parameter is optional.

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 states a specific verb and resource: 'Find' an 'Empathi therapy or coaching option' scoped by US state and relationship concern. It is clear what the tool does, though it does not explicitly differentiate itself from siblings such as ask_relationship_expert or get_relationship_assessment.

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 phrase 'based on your US state and relationship concern' implies the context in which to use the tool, but there is no explicit when-to-use, when-not-to-use, or sibling alternative guidance. Usage is inferable but not spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the description's only added behavioral fact is that the assessment is free. It does not say whether a call returns questions, a score, or a link, or whether it must be called before the sibling tools.

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?

A single front-loaded sentence with no padding, which is good, but the space is spent on marketing adjectives and a mismatched product name rather than on information that changes how the tool is called.

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?

With no output schema, no annotation explanation of results, and an undocumented parameter, an agent still cannot predict what this call produces or how its result feeds the sibling tools. The description should at minimum say what is returned and whether it is a prerequisite step.

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?

There is one parameter ('context') with 0% schema description coverage, and the description says nothing about it — no hint whether it is a conversation context blob, a user identifier, or optional framing text. Since the param count is not zero, the baseline-4 rule for zero-param tools does not apply.

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 states a specific verb ('Get') and resource ('assessment') and enumerates the domains it covers (attachment, communication, conflict, strengths), which is useful. However, it names the assessment 'Figlet' while the tool name and title say 'Empathi Relationship Assessment', leaving an agent unsure which product this actually returns.

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?

There is no statement of when to use this tool versus the clearly related siblings (ask_relationship_expert, find_couples_therapist, repair_right_now, wisdom_score_preview). The single clue is the word 'free', which implies an entry-point/lead-gen tool but is never framed as a selection rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

The annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the description does not need to repeat safety traits. It adds useful transparency about the returned content, including the named pattern, protected/feared dynamics, and suggested sentences, though it does not mention privacy, limitations, or that this is not therapy.

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 definition is a single tightly written sentence that front-loads the input and then lists the expected outputs. It contains no filler and is appropriately sized for a one-parameter, no-output-schema tool.

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 tool with robust annotations and no output schema, the description is largely complete: it explains what to provide and what the response will contain. It stops short of clarifying limitations or sibling-tool selection, but nothing critical for invocation is missing.

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 0%, so the description must carry parameter meaning. It clarifies that the single required parameter should be a recent conflict with a partner, which maps well to 'what_happened,' but it gives no guidance on length, format, or level of detail.

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 states a specific input (a recent conflict with a partner) and a concrete output bundle: a named repeating pattern, what each partner may be protecting/fearing, and suggested sentences. It is clearly more specific than a generic relationship-advice tool, though it does not explicitly distinguish itself from siblings such as repair_right_now or ask_relationship_expert.

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?

Usage is implied by 'Describe a recent conflict with your partner,' which tells the agent when the tool is relevant. However, it gives no explicit when-not-to-use guidance and does not route the agent toward alternatives like repair_right_now or find_couples_therapist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is fully covered. The description adds real value by disclosing the response shape — an ordered three-step sequence ending in talking when calmer — but says nothing about tone, what it will not do (e.g., no diagnosis, no judgment), or how the input shapes the output.

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?

One sentence that front-loads the deliverable and then lists the steps in order; nothing is padded. Slight redundancy with the title and name ('repair... right now') but it earns its length.

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?

A read-only, two-parameter tool with no output schema needs only modest explanation, and the description covers the character of the response. The unresolved meaning of both parameters is the meaningful gap an agent would hit at invocation time.

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 0%, so both parameters are undocumented anywhere. The description never explains what 'situation' should contain (a description of the fight? the topic? who is involved?) or what 'my_part' means (my contribution to the conflict versus my side of the story) — a critical ambiguity for an advisory tool that shapes its advice from that input.

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?

States a specific resource (a three-step immediate repair) with the exact steps spelled out, so an agent knows it produces a short procedural plan rather than an assessment or a referral. It never names a sibling, so the boundary with get_relationship_assessment or ask_relationship_expert is left implicit, but 'right now' and 'repair' are distinct enough to route on.

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?

'for right now' implies an acute, post-conflict timing that hints at when this applies versus longer-horizon siblings. No explicit when-not condition, prerequisite, or named alternative is given, so the agent must infer the routing from the tool name and framing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds that the result is a single non-numeric insight rather than a score, which is genuinely useful; it does not address input formatting, length limits, or what the insight response looks like.

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?

A single tight sentence with no filler, and the requested input content is front-loaded ahead of the promised output. The slightly oblique phrasing keeps it from being maximally clear.

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?

With no output schema, the description does give a minimal statement of the return ('one non-numeric Wisdom Score insight'), and annotations cover side effects. But for a free-text-input tool it omits everything about how to shape the input string and how the insight is framed.

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 0% and the sole 'responses' string parameter has no description, so the description must compensate. It does partially by enumerating the three things to include (the fight, the partner's inferred feelings, a different action), but never ties that content to the 'responses' field or indicates format/length.

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 sentence never states a verb+resource explicitly (e.g. 'generates a Wisdom Score insight'), but the combination of the input it asks for and the 'one non-numeric Wisdom Score insight' output lets an agent infer the purpose. It is distinguishable from siblings mainly by the 'non-numeric' output qualifier rather than by a stated function.

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?

There is no guidance on when to pick this over get_relationship_assessment, repair_right_now, or ask_relationship_expert, all of which overlap in the couples-reflection space. The 'one non-numeric insight' phrase hints at a lightweight alternative but never frames it as such.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.