CHRP EPI Authority

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the tool's safety profile. The description adds context about the data source but does not disclose output format, ordering, or any pagination or error behavior. There is no contradiction with 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?

The description is one focused sentence with no filler. The core result type, 'canonical URLs,' is front-loaded, and the source qualifier directly follows it. Every phrase contributes useful context.

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 zero-parameter, read-only retrieval tool with strong annotations, the description is largely complete: it states both the result type and the source scope. Since there is no output schema, a bit more specificity about what counts as a canonical source or the expected URL format would improve completeness, but this is not a significant gap.

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?

The input schema is empty with 100% coverage, so there are no parameters to document. Per the rubric, a zero-parameter tool receives a baseline of 4 because parameter semantics impose no additional burden on the description.

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 identifies the operation: retrieving canonical URLs from CHRP's public authority graph and reference documents. It is distinguishable from sibling tools like get_science or get_states, which target different resources. The resource scope is specific enough, though the term 'public authority graph' is left somewhat unexplained.

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 this tool should be used when an agent needs canonical source URLs from CHRP, but it gives no explicit when-to-use guidance and names no alternatives. Since the tool has no parameters and the siblings are quite distinct, the implied usage is acceptable but not strongly instructive.

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, closed-world behavior, so the safety bar is low. The description adds real value beyond that by specifying the content is public and enumerating the five content areas returned — useful since there is no output schema. It stops short of describing format or structure.

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 the verb-first framing and the content enumeration inline. No filler sentences and nothing 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?

With no parameters, no output schema, and annotations already covering the safety profile, the description supplies the remaining needed context — what content comes back and what the resource covers. Only the return shape/format is left unspecified, which is a minor gap for this simple tool.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level gaps exist.

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 ('Get public CHRP use cases') and enumerates the content areas covered (solution pages, churches, demo, MyCHRP, Song Analyzer). It does not explicitly contrast itself with siblings like get_science or get_mychrp_download_link, so it falls short of 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?

The description implies usage — retrieve public use-case examples of CHRP — but gives no explicit when-to-use or when-not-to-use guidance relative to the many sibling getters (get_science, get_states, get_epi_canon). An agent must infer the routing decision.

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 description discloses no behavioral traits. Annotations are empty, so the description carries the full burden, and it fails to mention whether this is a read-only lookup, whether it returns a list or a single object, or any side effects. There is no contradiction with annotations, but there is also zero added value.

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 extremely short, but this is under-specification rather than conciseness. A single vague phrase 'Get the science' does not earn its place because it adds no information beyond the tool name.

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 annotations, no output schema, and no parameter details, the description is completely inadequate. An agent cannot determine what this tool returns, what input it needs (even though there are 0 params, the meaning of the output is unknown), or how it relates to the sibling tools.

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?

The tool has 0 parameters, so the schema has nothing to document. The baseline for 0 params is 4, and the description does not need to add parameter meaning. It could have clarified what 'science' refers to, but parameter semantics are not a gap here.

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 is a tautology: 'Get the science' restates the tool name 'get_science' without any specific verb-resource detail. It does not distinguish this tool from siblings like get_canonical_sources or get_epi_definition, and provides no information about what 'science' means in this context.

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 use this tool versus alternatives. The sibling tools cover related scientific/epi concepts, but the description gives no context, exclusions, or selection criteria.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds that the content is 'versioned' and enumerates its scope, which is useful context, but says nothing about return shape, size, or whether the canon is returned whole.

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?

Two sentences, front-loaded with the verb and resource before the content enumeration. The long list of included artifacts is dense but each item is substantive; nothing reads as 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 zero-parameter, read-only lookup whose annotations cover the safety profile, the description is nearly sufficient. Its only real gap is not stating what the call returns (full canon document vs. summary) and not resolving overlap with the closely related sibling lookups; no output schema exists to fill that in.

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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate and no parameter documentation is needed.

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 ('Get the versioned EPI™ Canon') and enumerates the contents it carries (definition of record, EPI Score boundary, approved vocabulary, routing, prohibited inferences, Answer Protocol reference). It does not, however, differentiate itself from siblings like get_epi_definition, get_epi_score_definition, or get_claim_boundaries, whose subject matter overlaps heavily with the listed contents.

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 'for questions about EPI or how repeated music listening relates to personal patterns, mood, confidence, focus, readiness, reset, or recovery' gives a usage context, but it is broad enough to swallow most sibling tools. No alternatives are named and no 'when not to use this' guidance is offered, so an agent cannot tell when to prefer get_epi_definition or get_claim_boundaries instead.

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, and non-destructive behavior. The description adds valuable context beyond those annotations by specifying the definition is 'canonical' and 'public', implying authority and no-auth access. No contradiction exists.

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 that immediately names the action and resource. Every word earns its place, and there is no redundant restatement of the tool name.

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 no-parameter, read-only, idempotent tool, the description is nearly complete. It identifies what the agent will receive (the EPI definition) and its authority/publicness. It does not describe output format, but given the simplicity and annotations, this is a minor gap.

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 are zero parameters and the schema is empty, so the baseline is 4. The description does not need to add parameter semantics because there is nothing to configure or explain.

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'), a specific resource ('CHRP’s canonical public Emotional Performance Intelligence definition'), and the 'canonical public' qualifiers distinguish it from the sibling get_epi_score_definition. An agent can tell this is the general authoritative definition rather than the score-specific one.

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 clearly implies when to use it: whenever an agent needs CHRP's authoritative public EPI definition. It does not explicitly name alternatives or exclusions, but the 'canonical public' framing provides enough context for this simple, zero-argument read tool.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful 'public' and 'canonical source' context, indicating access expectations and provenance, which goes slightly beyond the structured fields.

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, front-loaded sentence with no filler. It communicates both the action and the return scope efficiently.

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 zero-parameter, read-only retrieval tool with no output schema, the description is sufficiently complete: it names the exact resource and the canonical source. There is no missing information an agent would need to invoke it correctly.

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?

The tool has zero parameters and schema description coverage is 100%, so the baseline is 4. The description does not need to explain parameter semantics and does not introduce any ambiguity.

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: 'Get the public EPI Score definition and its canonical source.' It clearly identifies what the tool returns, but it does not explicitly distinguish itself from the sibling get_epi_definition, so the differentiation relies on the 'EPI Score' phrasing rather than an explicit contrast.

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 provides no guidance on when to use this tool versus alternatives such as get_epi_definition or get_canonical_sources. It states only what the tool does, with no mention of contexts, exclusions, or routing conditions.

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, and destructiveHint, so the safety profile is covered. The description adds the qualifier 'approved,' implying a curated/official link, but provides no details on output format or link stability. This is acceptable for a zero-parameter read-only tool.

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 entire description is one short sentence with no filler. The action and object are front-loaded and every word earns its place.

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 zero-parameter tool, the description is nearly complete, but it leaves ambiguity about what the returned link is and why it is 'approved.' Since there is no output schema, a bit more context about the result's purpose or form would improve completeness.

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?

The input schema has no properties and schema description coverage is 100%, so there are no parameters to explain. The description rightly reflects that this is a parameterless retrieval operation.

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 action and resource: 'Get the approved MyCHRP / EPI Score conversion link.' It is concrete enough to distinguish the tool from siblings focused on definitions and sources, though it does not explain what the link is for.

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 use this tool versus siblings such as get_epi_score_definition or get_chrp_use_cases. An agent must infer selection purely from the tool name and brief description, with no exclusions or alternatives mentioned.

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, and destructiveHint=false, so the description does not need to cover safety. It adds context by specifying the content returned ('approved public summary and source'), but does not describe return format or any other behavior beyond what annotations already convey.

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 front-loaded sentence with no filler or redundant detail. Every word earns its place.

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 parameterless, read-only getter, the description names the two return elements (summary and source) and the 'approved public' scope, which is the core information an agent needs. Without an output schema, it could be slightly more explicit about the return shape, but the simplicity of the tool makes this adequate.

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?

The input schema has zero parameters, so there is no parameter semantics for the description to add. This is the correct baseline for a parameterless tool.

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 uses the specific verb 'Get' and names the resource ('approved public science summary and source'), which is clear and not a tautology. It does not explicitly differentiate from siblings like get_canonical_sources, but the resource is distinct enough to be understood.

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 about when to choose this tool over the sibling getters, nor any exclusions or prerequisites. The description only states what it does, leaving the agent to infer usage from the name and context.

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 that the tool is read-only, idempotent, and non-destructive. The description adds useful behavioral context by noting the data is 'published public' and sourced from a 'canonical data page,' implying a stable, authoritative, publicly accessible dataset. It does not describe the return format, but the content being returned is clear.

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, well-structured sentence that front-loads the purpose and then names the source. Every word earns its place, and there is no unnecessary detail or repetition.

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 zero-parameter, annotation-covered read tool, the description names exactly what is returned ('state names and descriptions') and where it comes from ('CHRP’s canonical data page'). The only minor omission is the exact return shape, such as whether results are returned as a list or object, which is not a significant blocker.

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?

The tool takes zero parameters and the schema is an empty object with high coverage, so there is no parameter documentation burden for the description. The baseline of 4 applies here since no parameter explanation is needed.

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 identifies the tool's action ('Get') and resource ('published public state names and descriptions from CHRP’s canonical data page'). It is specific enough to convey the primary purpose, though it does not explicitly distinguish itself from the related sibling get_canonical_sources, which might also reference the canonical data page.

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 intended use is implied by the description and tool name, but there is no explicit guidance on when to choose this tool over alternatives such as get_canonical_sources or get_claim_boundaries. For a simple zero-parameter read tool this is a minor gap, but some routing context would improve it.

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 that this is a safe, idempotent, closed-world read, so the description focuses on behavior that structured fields cannot express: it explicitly disclaims measuring, scoring, inferring current state, drawing clinical conclusions, or explaining a specific song. It also discloses the degraded-path behavior (returns one short question when the goal is unclear) and what the output includes (public sources plus the limits of the evidence).

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 in the first clause, followed by the goal list, the mapping behavior, and the disclaimers in a logical order. It is dense but nearly every clause carries information; the 'Guidance only:' clause runs slightly long with four enumerated negatives, though each rules out a plausible misuse.

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?

There is no output schema, yet the description fully characterizes the return: one of four states, bounded guidance, public sources, evidence limits, or a single clarifying question. For a two-parameter read-only tool that is everything an agent needs to invoke it and 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% and the schema already spells out that 'goal' is the person's own words rather than a mood or song, and that 'service' is apple_music/spotify/unknown. The description's framing largely restates that instead of adding new meaning. Baseline 3 applies because the schema carries the parameter burden.

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 and resource: it maps a stated listening goal onto one of four named CHRP states (Flow, Ready, Recharge, Recover) and returns bounded guidance. The states are enumerated explicitly, so an agent can distinguish this from sibling lookups like get_states or get_science without opening a schema.

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 opens with a clear triggering condition ('Use when someone says what they need their music to help them do next') and enumerates concrete goal categories (focus, game prep, workout, reset, recovery). It also states exclusions ('Not for trivia, playlist generation, or entertainment-only requests') and the unclear-goal fallback. It stops short of naming which sibling to call instead for the excluded cases, so the routing is implied rather than explicit.

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