Juno Open Health Tools

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

Annotations already declare readOnly/non-destructive, and the description adds real context beyond them: consent gating, transient (non-persistent) processing, non-identifying input constraints, and preservation of uncertainty. It stops short of explaining retention specifics or failure behavior if consent is missing.

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?

Three tight sentences; the core operation is front-loaded and each sentence adds a distinct constraint (chronology, consent, scope). No 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?

With an output schema covering return values and annotations covering the safety profile, the description is nearly complete for a 2-param tool. Remaining gaps are minor: it does not clarify what 'transient processing' means for data retention or describe the observation item structure.

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 50%: consentConfirmed is well documented in-schema, but the nested observation fields (date, impact, category, uncertainty) lack descriptions. The phrase 'preserving supplied dates and uncertainty' marginally documents two of those fields, but the description mostly does not compensate for the coverage gap.

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 verb and resource: sorts user-authored observations into a factual chronology while preserving dates and uncertainty. The scope exclusion (PHI and diagnosis out of scope) helps an agent distinguish it from siblings like reflect_on_flare or prepare_appointment_brief, though no sibling is named directly.

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?

Gives a clear prerequisite (explicit consent for transient processing) and a scope boundary (PHI and diagnosis excluded), which tells the agent when not to use it. It never names an alternative tool for cases outside its scope, so routing is left partly 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant behaviour: processing is transient, explicit user consent is mandatory, and PHI/diagnostic inference are rejected. That is real operational context beyond the 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?

Three short sentences, front-loaded with the core action and followed by the two hard constraints (consent, scope exclusions). No filler, and the most important safety caveat is not buried.

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?

An output schema exists, so return values need no explanation, and the consent/PHI constraints are adequately covered. What is missing is guidance on the four undocumented input fields, which for a five-parameter tool with 20% schema coverage is a noticeable hole.

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 only 20% (just consentConfirmed is documented), so the description must carry the load for the other four parameters. It gestures at 'timing' and 'impact' vocabulary, which map to two parameters, but leaves 'description' and 'bodyArea' unexplained and gives no format or length expectations. Partial compensation for a large coverage gap.

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 names a specific transformation: organising a user-authored sensation description into neutral sensation, timing, pattern and impact vocabulary. That is more concrete than the name 'find_symptom_words' alone and tells an agent this is a vocabulary-normalisation step. It does not, however, contrast itself with siblings like build_health_timeline or reflect_on_flare, so differentiation is left to inference.

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 rather than stated: the agent can infer this is the first-pass normalisation step, and the exclusions ('PHI and diagnostic inference are outside its scope') plus the consent requirement act as partial when-not guidance. No alternative sibling tool is named and no explicit triggering condition is given, so routing between this and its siblings remains guesswork.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: processing is transient, explicit user consent is a hard gate, and PHI/diagnosis/treatment content must not be submitted. It doesn't say what happens to the produced brief or how long it persists.

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?

Three sentences, zero filler, front-loaded with the purpose before the consent constraint and the scope boundary. Each sentence carries distinct information (what it does, the consent gate, what is excluded).

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?

An output schema exists, so return values need no explanation, and the description covers purpose, consent, and privacy scope. The gaps are the undocumented 'detailsToBring' parameter and the relationship to the sibling render step, neither of which is addressed.

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 only 14% (just consentConfirmed), so the description carries most of the load; it does enumerate goals, changes, impacts, medicines and questions, which maps to five of seven parameters. However, 'detailsToBring' is never mentioned, and no format or granularity guidance is added beyond the field names. Baseline-plus given low coverage.

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 names a specific verb ('Structures') plus the target artifact ('appointment brief') and enumerates the input content types (goals, changes, impacts, medicines, questions). This is unambiguous about what the tool does. It does not distinguish itself from the sibling 'render_appointment_brief', so an agent must infer whether prepare feeds render.

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 a clear precondition (explicit consent required for transient processing) and an explicit scope exclusion (PHI, diagnosis, treatment advice are out of scope), which tells the agent when not to use it. It stops short of naming an alternative or the follow-on sibling tool (render_appointment_brief), so routing to the next step 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 establish read-only, non-destructive, closed-world behavior. The description adds genuinely non-obvious traits: transient processing, consent gating, PHI exclusion, and the deliberate framing of suspected patterns as questions rather than causes. It does not, however, describe what the user gets back (deferred to the output schema) or anything about retention beyond 'transient'.

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?

Three short sentences, no filler, with the output framing front-loaded and the safety constraints following. 'Structures' is the one slightly abstract word, but the rest of the sentence pins it down, so the density is earned.

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?

An output schema exists, so return values need not be spelled out. For a 5-parameter health-reflection tool the description covers the safety posture, scope boundary, and output framing, which is most of what an agent needs. Remaining gap is the precise role of possiblePatterns and any statefulness across calls.

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 only 20%, so the description must carry weight here. It maps cleanly onto baselineBefore/during/recoveryAfter via 'before, during and recovery observations' and reinforces the consentConfirmed gate, but 'possiblePatterns' is left unexplained beyond a hint in 'presenting suspected patterns as questions,' and item-level constraints (25 items, 1000 chars) are schema-only.

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 concrete verb and resource: it structures before/during/recovery observations and reframes suspected patterns as questions. That is specific enough to distinguish it from build_health_timeline (raw timeline assembly) and find_symptom_words (vocabulary lookup). It stops short of explicitly naming a sibling, so it does not reach a 5.

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 supplies hard preconditions (explicit consent, transient processing, PHI out of scope) which is more than generic guidance, but it never says when to reach for this tool versus prepare_appointment_brief or build_health_timeline. Usage is implied by the phase-based inputs rather than stated.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes further by disclosing the consent prerequisite, the transient (non-persistent) processing model, the preservation of supplied fields and disclaimer, and the explicit PHI exclusion — meaningful data-handling context beyond the 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?

Three short sentences, front-loaded with purpose followed by the consent requirement and the scope boundary. Every sentence adds a distinct fact with no 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?

An output schema exists so return values need no explanation, and the consent/PHI behavior is covered. However, with eight required parameters at 13 percent schema coverage, the description leaves most input semantics for the caller to infer from names alone.

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 only 13 percent (only consentConfirmed is documented in the schema), so the description carries most of the burden. It adds scope constraints around disclaimer/consent and PHI, but says nothing about the six content parameters (mainGoal, changes, impacts, medicines, questions, detailsToBring) beyond a generic "preserves the supplied fields."

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 verb ("renders") and resource ("appointment brief") plus the output form ("accessible card"). The qualifiers "supplied" and "complete" implicitly distinguish it from the sibling prepare_appointment_brief, which would build the brief, though no sibling is named explicitly.

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?

Gives clear preconditions ("supplied, complete, non-identifying" brief plus explicit consent for transient processing), which tells the agent when the tool is applicable. It never names an alternative tool or states when not to use it, so usage is implied rather than routed.

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