performix-site

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds useful context beyond that: the returned profile is 'grounded', includes the record's own argument, metadata, and cross-links, and is publicly available at a known URL. No contradiction with 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?

Two tight, information-dense sentences. The core action and source are front-loaded, followed by a compact summary of the response content and a public URL reference. No wasted words.

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 single-record read tool with one well-documented parameter, an output schema present, and safety annotations already covering read-only behavior, the description provides all necessary context. It even gives the public URL as an additional reference for the same content.

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 already fully describes the single 'slug' parameter with an example, so the baseline is 3. The description adds extra value by telling the agent that the slug should come from list_books results, which helps the agent know where to find valid values.

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 a specific verb ('Get') and resource ('Performix book profile by slug'), clearly identifying the input source ('from list_books') and the content of the result (argument, metadata, cross-links). This distinguishes it from sibling tools like list_books and get_guide, which are collection or other-profile operations.

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 explicitly says the slug comes from list_books, giving an agent clear direction on how to obtain the required parameter. It also notes the same content is public, but it does not explicitly say when to prefer this over get_guide or when not to use 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond the annotations: it discloses the honesty caveat about placeholder titles and the citationPlaceholder field, plus it notes the content matches a public URL. This is meaningful additional transparency.

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 compact and front-loaded: the primary purpose and full content scope appear in the first sentence, and the important honesty caveat is cleanly separated in the second. Every clause earns its place, and there is no redundant repetition of the tool name or title.

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?

The tool has one required parameter, a complete input schema, an output schema, and clear read-only annotations. The description fully explains what the agent will receive, how to identify the source, and even flags a known data-quality issue. Nothing needed for correct 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 100%, and the id parameter is already well documented in the schema with a concrete example and provenance ('from list_evidence_sources'). The description reinforces this but does not add new parameter-level meaning beyond what the schema already provides, so baseline 3 is appropriate.

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 ('Get') and a precise resource ('full source → finding → construct → survey-item evidence chain for one source by id'), and enumerates exactly what is included. It clearly differentiates this single-source retrieval tool from the sibling list tool list_evidence_sources by emphasizing 'one source by id'.

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 this tool: when you need the complete evidence chain for a specific source, and it directs the user to obtain the id from list_evidence_sources. It does not explicitly state when not to use it or name alternative tools, but the context is unambiguous enough for an agent to select it correctly.

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 and destructiveHint, so the safety profile is covered. The description adds valuable behavior beyond annotations: the content is 'the same content rendered publicly' at the web URL and is 'never the entitlement-gated depth layer', plus it enumerates exactly which sections are included. No contradictory statements.

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 front-loaded with the core action ('Get the full free content of one capability guide by slug') and then details the content structure in an organized list within the sentence. Every clause earns its place, though the sentence is long and dense; splitting it into two sentences could improve readability without losing information.

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 read-only single-item retrieval tool with one parameter, a full output schema, and annotations covering safety, the description is complete. It explains exactly what the returned content includes (sections, tensions, sources), the public vs. gated scope, and the slug provenance. No essential call-time information 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 coverage is 100% for the single slug parameter, giving baseline 3. The description adds meaning by stating the slug is obtained '(from list_guides)', revealing a cross-tool prerequisite and implying the slug must be a known guide identifier, not an arbitrary string. This goes beyond the schema's simple example.

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 the tool retrieves 'the full free content of one capability guide by slug' — a specific verb, resource, and retrieval mechanism. It distinguishes itself from siblings like list_guides (plural listing) and get_guide_part (part retrieval) by emphasizing 'full' guide content and naming the five-movement structure that constitutes the whole.

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 tells the agent the slug must come from list_guides and explicitly excludes the entitlement-gated 'depth' layer, conveying when not to use this tool. However, it does not explicitly name alternatives like get_guide_part for when only a section is needed, so the guidance is strong but not fully explicit about sibling routing.

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 mark the operation as read-only and non-destructive. The description adds valuable behavioral detail beyond annotations: stubs return an error instead of a placeholder, and content matches performix.app/learn/<slug>. This clarifies failure modes without contradicting 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 compact and front-loaded: the primary action comes first, the content equivalence note is one short sentence, and the stub caveat is clearly separated. Every sentence contributes practical information 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?

For a single-parameter read tool with an output schema, the description covers the essential context: how to identify the part, what content to expect, and the important error case for stubs. Nothing needed for correct 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?

The input schema fully documents the single slug parameter, including an example and a source note. The description reinforces that the slug comes from list_guide_parts, but does not add substantial new meaning beyond the schema, so the baseline of 3 is appropriate.

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 ('full body of one Team Performance Science Guide part'), and identifies the key identifier ('by slug'). It also names the sibling list operation it depends on, making it easy to distinguish from list_guide_parts and get_guide.

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 gives clear usage context: call with a slug obtained from list_guide_parts, and check the status field first to avoid stub errors. It stops short of explicitly naming alternative tools or saying when not to use this tool, but the guidance is sufficient for correct selection in most cases.

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?

Beyond the readOnlyHint and destructiveHint annotations, the description discloses a critical behavioral rule: driver r values are null unless the tier is T3, VOI figures and overlap-corrected variance contributions are never exposed, and the tool withholds exactly what the public page withholds. This is substantive behavioral context that annotations alone could not 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 long but densely informative and well-structured: the core purpose is front-loaded, followed by the integrity caveat. It earns its length by documenting an important data-withholding rule, though it could be tightened slightly.

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?

Given one required parameter, a rich output schema, and simple annotations, the description fully covers what the tool returns, where the id comes from, what is withheld, and the parity with the public page. Nothing essential for correct 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 100%, and the single id parameter is already documented with an example and source ('from list_outcome_models'). The description repeats the source reference but adds little new meaning beyond the schema, so the baseline 3 is appropriate.

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 a specific verb and resource ('Get one outcome's full driver table by id') and enumerates exactly what is returned: driver name, definition, CAMS dimension, lens role, evidence grade, study count, tier, uncited-effect drivers, and personas. It clearly differentiates itself from list_outcome_models by being the single-item fetch counterpart.

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 explicitly says the id comes from list_outcome_models, establishing the correct retrieval sequence and clarifying that this is the one-outcome lookup tool. It does not explicitly state when not to use it, but the purpose is clear enough that an agent can infer the alternative is the list 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 and destructiveHint=false, covering safety. The description adds valuable behavioral context by disclosing the output structure (stances: ally, orthodoxy, mixed, leave-out; one-line summaries) and the exact filtering behavior (case-insensitive substring match across title/authors/tradition/blurb). No contradictions with 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?

Two sentences with no wasted words. The first sentence front-loads the tool's core purpose and output, and the second explains the single optional parameter. Every sentence 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?

Given the read-only annotations, a fully described query parameter, and the existence of an output schema, the description covers everything an agent needs to call the tool correctly. It names the stance categories and filter fields, leaving no actionable 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?

Schema description coverage is 100%, so the schema already fully documents the query parameter. The description repeats the case-insensitive substring filter nearly verbatim and adds only the word 'Optional,' providing no additional semantic depth beyond the 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 uses a specific verb ('List') with a clear resource ('the performance-science reading corpus behind Performix') and details the output contents (book/cluster profiles, stance categories, and one-line summaries). It is clearly distinct from sibling tools that fetch a single book or list guides.

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 when an agent needs an overview of the book corpus, and the optional query filter indicates a filtering use case. However, it does not explicitly contrast with sibling tools like get_book or list_guides, so the when-not/alternatives guidance 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 mark this as read-only and non-destructive, so the description does not need to repeat that. It adds genuinely useful behavioral context: 132 of 196 sources have placeholder citation titles pending backfill, and the agent is told to check `citationPlaceholder` before trusting `title`/`venue`. It also discloses the inclusion criterion that every source has at least one derived finding.

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 front-loaded with the core action and object, then gives the important data-quality caveat and optional filters. Two sentences carry a substantial amount of relevant information with no filler. Every clause 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 read-only list tool with a full output schema present, the description is complete: it defines the source set, the inclusion rule, the optional filters, and the critical placeholder-data warning. An agent has everything needed to decide whether to call this tool and how to use its filters.

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 100%, so the schema already documents both parameters. The description still adds value by clarifying that `query` is a case-insensitive substring over authors/title/venue and that `camsDimension` restricts to sources with at least one finding on that dimension. This reinforces and slightly extends the schema descriptions without contradicting them.

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 has a specific verb and resource: 'List the 196 source records behind Performix's Performance Science Library.' It clearly defines what each source is (a book, paper, or corpus item with at least one derived finding) and the CAMS dimensions touched. This distinguishes it from sibling list tools like list_books or list_guides by focusing on evidence sources specifically.

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 explains the optional filters and the data context ('Same source list rendered at performix.app/learn/evidence'), so an agent can infer when listing makes sense. However, it never explicitly says when to prefer this over sibling tools like get_evidence_source or list_books, nor does it give an exclusion condition. Usage guidance is implied 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 mark it read-only and non-destructive. The description adds useful behavioral context beyond that: each row exposes a status of live/draft/stub, enabling the caller to determine publishability before fetching a part.

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 dense sentence that front-loads the core purpose and then adds useful context about status and the sister call. Slightly long, but every clause contributes to correct invocation and interpretation.

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?

Given zero parameters, read-only annotations, and an existing output schema, the description fully covers what an agent needs: the exact list scope, the status semantics, and the relationship to get_guide_part. Nothing material 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?

The tool has zero parameters and the schema has 100% coverage, so the description doesn't need to explain parameters. It focuses on output semantics instead, which is appropriate and adds value.

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 the verb 'List' and the exact resource: the 12 parts (8 numbered + 4 appendices) of the Team Performance Science Guide. It also distinguishes this from get_guide_part and list_guides by specifying the full table of contents scope.

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 explains a concrete usage context: call this before get_guide_part to check which parts are publishable via the status field. It doesn't enumerate all sibling alternatives or explicitly say when not to use it, but the guidance is clear enough for selection.

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 and destructiveHint=false, so the safety profile is clear. The description adds useful access context by stating the guides are public, free to read in full, and require no authentication—information not present in the annotations. This goes beyond what the structured fields provide.

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 core action and resource, then adds valuable context about content type and access. Every clause earns its place: public scope, evidence-based grounding, cross-book nature, and no-auth requirement. There is no redundancy or 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 parameterless list tool with an output schema and readOnly annotations, the description is complete. It tells the agent what will be listed, where it is published, what kind of content it is, and that no authentication is needed. There are no gaps that would prevent correct invocation or interpretation.

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, so the schema provides no parameter semantics to supplement. The description appropriately focuses on what is being listed rather than on parameter details, which are irrelevant here. The baseline of 4 applies because there is nothing for the description to clarify.

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 begins with a specific verb ('List') and names the exact resource ('public, grounded capability guides published on performix.app/guide'). It also distinguishes guides from books by explaining they are 'cross-book model[s]' of evidence for individual executive capabilities, which separates it from list_books and get_book. The example capability ('leading an R&D team') further clarifies the content domain.

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 conveys the context for using the tool: listing publicly available guides, with no authentication required. It does not explicitly name when to use get_guide or list_books instead, but it gives enough contextual signals ('list', 'guides', 'public') for an agent to make a reasonable selection among siblings.

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?

Beyond the readOnlyHint and non-destructive annotations, the description discloses a key behavioral trait: the list intentionally omits effect sizes due to measurement integrity, and it also returns the additional 'namedUnmodellable' payload. It even explains the sibling's withholding behavior, giving the agent a complete picture of what this endpoint does and does not return.

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 longer than average but every component earns its place: it clarifies scope, data fields, a public URL analogy, the namedUnmodellable extra return, and the critical no-effect-sizes caveat. It is front-loaded with the core purpose and uses punctuation to group details effectively.

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 present and no parameters, the description covers everything an agent needs: what is returned, the number and nature of models, key fields, the important absence of effect sizes, and the route to a sibling tool for richer data. This is fully self-sufficient for correct invocation.

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, so there are no parameters to document. Baseline for zero parameters is 4, and the description adds no irrelevant parameter detail, which is appropriate.

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 a specific verb ('List') and names a concrete resource ('constructed outcome-model register behind Performix diagnostics'), then enumerates the fields each model carries. It also distinguishes itself from the sibling get_outcome_model by stating that this list has no effect sizes and directs the agent to get_outcome_model for a driver table.

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 explicitly states when to use the alternative: 'call get_outcome_model for a driver table' and explains that this list 'carries no effect sizes at all,' making the choice between list_outcome_models and get_outcome_model unambiguous.

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 indicate readOnlyHint=true, but the description goes beyond by explaining the function is the same as performix.app, notes that it is N=1 self-report and not psychometrically calibrated (tier INFERRED), and explicitly states it refuses degenerate ratings. This is excellent disclosure of behavior 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?

The description is a single long sentence but front-loads the key purpose and computation. It reads densely, but every part earns its place. Some might prefer it broken into two sentences for readability, but it's not wasteful.

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?

Given the complexity (2 params, one nested) and the presence of an output schema, the description covers the essential inputs, constraints, and behavioral notes. The output schema presumably details the return format, so not explaining it is acceptable. Minor gap: it doesn't explain what 'tier INFERRED' means or how to interpret the ranked output, but the output schema may cover that.

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 schema already provides 100% coverage, describing slug as an exec-shelf book slug and ratings as a mapping of lever id to rating. The description adds the example slug and reinforces the requirement to rate at least two levers, but mostly it re-states what the schema already says.

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 a specific verb ('self-diagnose'), the resource (a book's model), and the computed output (ranked weakest lever). It distinguishes itself from siblings like list_books by explicitly noting the lever slugs come from list_books' exec-shelf slugs.

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 explicitly states when to use this tool (for a self-diagnosis against a book) and what it computes, and it implies when not to use it (when you just need to list books, use list_books). It also provides clear constraints: rate at least two levers, ratings between 1-5, and not all equal, which is practical usage guidance.

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