ScoreMindset — capital mental

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals only that the result is a daily question drawn from the book's ten questions and includes a work track, but it does not state whether the operation is read-only, how the daily question is selected, or what the 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?

The description is a single compact phrase with no filler, and it front-loads the core idea 'La question du jour' before adding context. It loses a point only because the opening phrase largely repeats the tool name and the description reads more like a label than an instructive sentence.

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 and no annotations, the description should clarify what the agent receives and how to interpret it. It mentions the question and the work track, but leaves unspecified the output format, the meaning of 'piste de travail', and how 'daily' selection works, which is a meaningful gap even for a no-parameter 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 declares zero parameters, so there is nothing for the description to clarify. The baseline of 4 for a no-parameter tool applies; the schema coverage of 100% is vacuously satisfied.

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 identifies the resource as 'La question du jour' and adds provenance ('tirée des 10 questions du livre') plus a component ('avec sa piste de travail'), so it is more than a bare tautology. However, it is a noun phrase with no verb or explicit operation, and it does not distinguish the tool from siblings like get_test or search_book.

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 no guidance on when to use this tool versus alternatives, no exclusions, and no context about selection criteria such as date or randomness. An agent must infer usage from the name alone.

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?

With no annotations, the description carries the full burden. It states what the tool does (details a test) and what it returns (dimensions, profiles, method), but it does not explicitly say whether it is read-only, what side effects (if any) occur, or whether authentication is required. For a 'get' tool, read-only behavior is implied, but not disclosed. It adds minimal behavioral context beyond the action itself; it does not contradict anything, but does not go beyond what is obvious.

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 sentence that efficiently states the purpose, the content of the response, and the parameter source. It is front-loaded with the primary action and includes the essential pointer for the parameter. No filler or redundant information; 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 simple tool with one required parameter and no output schema, the description is complete. It tells the agent what the tool does, what it returns (dimensions, profiles, method), and how to obtain the required slug. There are no obvious gaps that would prevent correct invocation. The tool's simplicity means the description does not need to elaborate on return formats or error handling.

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 has no description for the 'slug' parameter (coverage 0%), so the description must compensate. It does so by stating 'Slug via list_tests', which tells the agent that the slug is a test identifier obtained from list_tests. This adds meaningful context about the parameter's source and format, which is valuable since the schema provides no hints. It does not specify the exact format, but pointing to list_tests is sufficient for correct usage.

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 action ('Détaille un test' – details a test), the specific resource (a test), and what is detailed (dimensions mesurées, profils possibles, méthode). It distinguishes from siblings by indicating that it retrieves a single test's details, while list_tests presumably lists available tests. The phrase 'Slug via list_tests' further clarifies that this tool is for a specific test identified by a slug obtained from list_tests.

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 implicit guidance by saying 'Slug via list_tests', which tells the agent to call list_tests first to obtain the slug. This implies the tool is used when you need details of a specific test and have already identified it via list_tests. It does not explicitly list alternatives or exclusions, but the purpose is clear enough that an agent would not confuse it with list_tests or search_book. A small gap is the lack of explicit 'use this when...' statement.

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?

With no annotations, the description carries the burden of behavioral disclosure. It does add useful scope: only free tests are included and the returned fields are listed. However, it does not disclose potential pagination, ordering, authentication needs, or response shape, though a simple read-only list operation reduces the risk.

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 compact French sentence delivers the action, scope, and expected fields without filler. It is 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 parameterless list operation, the description is nearly complete: it names the resource, limits scope to free tests, and enumerates return fields since no output schema exists. It could add explicit guidance on using get_test for individual test details, but that 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?

The tool has zero parameters, so parameter semantics are not a concern. The description correctly focuses on the output fields instead. Per calibration, 0 parameters earns a baseline 4.

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 ('Liste') and a precise resource ('les tests psychologiques gratuits de ScoreMindset'), and enumerates the returned fields (slug, titre, durée, thème). This clearly distinguishes list_tests from sibling get_test: one enumerates, the other retrieves a single item.

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 context is implicit: this tool is for listing free psychological tests, while get_test likely retrieves a specific test. However, there is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named, so the agent must infer the routing from the name and sibling list.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explicitly state that the tool is read-only or has no side effects, nor does it describe the output format or any potential errors. The verb 'Présente' implies a non-mutating action, but it is not explicit, and nothing is said about response structure or server interaction.

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 that immediately names the tool's purpose ('Présente ScoreMindset') and then lists the covered aspects. It is concise with no filler or redundancy, earning a high score for structure.

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 tool's simplicity (no parameters, no output schema), the description covers its core purpose adequately. It explains what content is presented (mission, tools, pages, limits) and leaves little ambiguity. It could optionally mention that it serves as an introduction or entry point, but that is not essential for correct usage.

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 the baseline for this dimension is 4. The description adds no parameter information because none exists. It correctly omits any discussion of arguments, and the schema fully covers the (empty) parameter set.

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 presents ScoreMindset, specifying the content areas: mission, public tools, key pages, and server limits. It uses a specific verb ('Présente') and names the resource, distinguishing it from sibling tools that focus on individual actions like daily_question or list_tests.

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?

No guidance is given on when to use this tool versus alternatives. The description does not mention that it should be called first for an overview, nor does it mention any conditions or exclusions. It simply describes what it presents, leaving the usage context entirely implicit.

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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It says nothing about whether this is a read-only content lookup, what invoking it returns, or whether any side effects exist—it only names the content.

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 short phrase with no filler, and the core subject—the six dimensions—is front-loaded. For a parameterless content resource, this length is appropriate.

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 with no output schema, the description provides only the identity of the content. It does not explain how an agent should use this information, when it is relevant, or what the tool actually returns, leaving selection among siblings largely to inference.

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 parameter semantics are mostly moot and the baseline is 4. The description's mention of dimensions and levers is content description rather than parameter guidance, but no parameter ambiguity exists.

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 French noun phrase identifies a specific resource: the six dimensions of the Score Mindset /1000 signature assessment, together with their levers. It is not a tautology and gives a clear subject, though it lacks an explicit verb and does not explicitly differentiate itself from sibling tools like list_tests.

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 no guidance on when to use this tool versus siblings such as daily_question, get_test, list_tests, manifest, or search_book. No contexts, exclusions, or alternatives are 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?

With no annotations, the description must carry the burden. It states it returns the most relevant passages, which implies a read-only operation, but does not explicitly declare non-destructive behavior, permissions, or other constraints. It adds scope context but lacks explicit behavioral disclosures.

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 efficiently conveys the purpose and scope without excess 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?

For a search tool with no output schema and no parameter descriptions, the description is incomplete. It does not explain the 'limit' parameter, the query format, or the structure of the returned passages. Significant gaps remain for a 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?

Schema coverage is 0%, so the description must compensate. It indirectly covers the 'query' by describing the search, but completely ignores the 'limit' parameter. The description adds minimal value for understanding the parameters.

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 action (search) and the specific resource (the full text of a specific book), and even enumerates the topics covered. This makes it unambiguous and distinct from the sibling tools, which are about tests, questions, and scoring.

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 when to use it (when you need to search the book's content) and the sibling names make the distinction obvious. However, it does not explicitly state exclusions or alternative conditions, so it stops short of full 5.

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