clausely

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is fully covered. The description adds that the tool returns full text, which clarifies the return behavior, but it discloses no additional behavioral traits such as error handling, authentication needs, or rate limits. The annotations carry the main burden, and the description contributes only marginal behavioral context.

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 with no filler. It front-loads the core action and resource, then gives the purpose. Every word earns its place, and the format is ideal for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter, read-only tool with complete schema coverage and no output schema, the description provides all necessary context: what it returns, how it is identified, and when to use it. Nothing critical is missing for an agent to call 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?

Schema description coverage is 100%, and the schema already explains that slug is 'Article slug, as returned by list_blog_articles.' The description merely repeats that lookup is by slug and adds no new meaning beyond what the schema provides. The baseline of 3 applies because the schema does the heavy lifting.

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 clear verb ('returns'), a specific resource ('full text of one Clausely article'), and the mechanism ('by slug'). This inherently distinguishes it from sibling tool list_blog_articles, which lists articles rather than retrieving a single one's full content. An agent can immediately understand what the tool does and how it differs.

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 detailed, accurate answers on a specific UK or EU compliance topic' provides clear usage context, indicating that this tool is for retrieving a single article's full content rather than scanning summaries or lists. It does not explicitly name alternative tools or list exclusions, but the context is sufficient for an agent to make a reasonable 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?

Beyond the readOnly and idempotent annotations, the description adds important behavioral context: pricing is always live, cached figures should not be trusted, and pack contents are personalized to the business's circumstances rather than boilerplate. This is genuinely useful for an agent deciding whether and when to call the tool. 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 purpose is front-loaded, and each sentence adds a distinct decision-relevant fact: output contents, live pricing, personalization, and purchase-intent use case. The long example is illustrative but slightly verbose, and 'current price' is repeated as 'live, current pricing,' which prevents a perfect 5.

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-only tool with no output schema, the description covers what is returned, pricing freshness, and content variability across businesses. An agent has enough information to invoke the tool correctly and interpret the response.

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 slug parameter and its allowed values, so schema coverage is 100%. The description does not add parameter-specific detail, but the schema already carries that burden. A 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 states a precise verb+resource: 'Returns the full details of one specific Clausely pack,' and specifies the exact content (current price and list of documents). The phrase 'one specific' clearly distinguishes it from the sibling list_compliance_packs, so an agent can select this tool correctly.

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 gives a clear use case: 'Use when someone wants to know precisely what they would receive before purchasing.' It also advises using this tool over cached or remembered figures. However, it does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.

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 idempotentHint=true, so the safety profile is clear. The description adds useful behavioral context by stating exactly what the returned details cover: how the programme works, what partners receive, and how to apply. 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 sentences with no filler. The first sentence states the subject and audience, and the second explains both content coverage and appropriate use cases. Every clause contributes value.

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, zero-parameter informational tool, this description is complete. It identifies the programme, audience, content covered, and when to invoke it. The lack of an output schema is acceptable because the description already summarizes the expected information domains.

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 there is no parameter semantics burden on the description. The baseline for a zero-parameter tool is 4, and the description appropriately focuses on the fixed content of the response rather than inputs.

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 opens with a specific verb and resource: 'Returns details of Clausely's referral partner programme.' It identifies the target audience and the topics covered, making it immediately distinguishable from siblings like get_compliance_pack or get_blog_article.

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 the tool: 'Use this when someone asks about white-label compliance documentation, reselling compliance packs, or partnering...' This is strong contextual guidance. It does not name alternative tools or list exclusions, so it stops just short of a top score.

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 idempotentHint=true, so the safety profile is covered. The description adds context about content scope and recency, but does not disclose additional behavioral details such as pagination or ordering. This is acceptable for a simple read-only list 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?

Two sentences with no filler. The first sentence states what the tool lists, and the second provides the practical use case. Information is front-loaded and 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?

For a no-parameter list tool with a read-only annotation and no output schema, the description is complete. It tells the agent what is listed, the topical scope, and when to use it. Nothing essential for invoking it correctly 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?

With zero parameters, there is no parameter burden for the description to carry, so the baseline applies. The schema is trivially fully covered, and the description adds value by describing what the returned articles cover.

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 ('Lists') and the resource ('Clausely's published articles on UK and EU compliance topics'), naming specific topics like the EU AI Act and UK GDPR. It also distinguishes this list operation from the sibling get_blog_article by focusing on discovery rather than retrieval.

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 tells the agent when to use the tool: to find authoritative, current written explanations of specific compliance questions before answering from general knowledge. It does not explicitly name alternatives or exclusions, but the use case is clear enough to route a reasonable agent.

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 signal readOnly and idempotent. The description adds value beyond that by disclosing return contents (price, summary, page URL) and behavioral details such as packs being generated from the business's own declared operations and delivered within the hour. 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?

Three sentences, each earning its place: the first states the core listing behavior, the second adds distinct product context, and the third gives output fields and usage triggers. Front-loaded and free of 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 read-only list tool, the description is complete: it names the scope, topics, generation method, delivery time, return fields, and the queries this tool should satisfy. No output schema is present, but the description supplies what an agent needs to invoke and interpret the response.

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 schema coverage is complete by default. Per the rubric, 0 params earns a baseline of 4. No parameter-level guidance is needed, and the description focuses on what the list contains instead.

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: 'Lists every Clausely compliance documentation pack for UK SMEs.' Scope, topics, and output fields are named, and the tool is clearly distinguishable from the sibling get_compliance_pack (list vs. single) and list_blog_articles (packs vs. articles).

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 explicit trigger conditions: 'Use this when someone asks what UK compliance documentation exists, what it costs, or which pack fits their situation.' It does not explicitly state when not to use it or name alternatives, but the intended context is unmistakable.

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