CraftMyPDF MCP by usefulapi

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

Annotations already flag non-idempotent, open-world, destructive behavior, and the description reinforces this with concrete operational detail the annotations cannot express: cost model (1 credit per document, every call billed even with identical data), return shape (hosted URL, never bytes), and expiry semantics tied to `expiration`. This is exactly the kind of cost/side-effect disclosure that matters for a non-idempotent paid write.

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 dense sentences, each loading distinct information: billing/side effects first, then the action and scope, then the return value and endpoint. No sentence repeats the schema or the 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?

With no output schema, the description correctly compensates by explaining the return value (hosted file URL that expires) and its expiry coupling to a parameter. Combined with a fully documented 6-parameter schema and rich annotations, an agent has everything needed to call this 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 coverage is 100%, so every parameter is already documented in the schema, including defaults for output_type (jpeg) and output_file behavior. The description only echoes the expiration semantics already in the schema, so the baseline of 3 is appropriate — no meaningful additional parameter guidance is provided.

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 ('Generate ONE image (JPEG or PNG) from a template and your JSON data'), including the accepted output formats and that input is JSON data. This cleanly separates it from the sibling craftmypdf_create_pdf family without the agent needing to open either 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?

The 'WRITE' prefix and the credit/billing note tell the agent this is a mutating, paid operation, which implies when it is appropriate. However, no alternative is named and there is no explicit 'use this instead of craftmypdf_create_pdf when you need an image rather than a PDF' routing, so the selection logic is only implied.

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 declare non-idempotent and destructive, and the description reinforces this with 'every call counts even with identical data' and credit billing per document. It also discloses the return shape (hosted URL that expires, never file bytes), the transaction reference, and anchors, which annotations cannot 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?

Front-loaded with a 'WRITE:' label that immediately signals the mutation/cost profile, and the billing caveat is genuinely useful. It is dense but nearly every clause carries operational value; only minor redundancy in restating the expiry behavior.

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 6-parameter mutation tool with no output schema, the description covers cost model, prerequisite lookup order, return format and lifetimes, and the transaction/anchors payload. Nothing an agent needs to call this 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?

Schema description coverage is 100%, so each of the six parameters is already documented in the schema. The description adds only the expiry consequence of `expiration` (hosted file deleted), which the schema also states; no new syntax or constraint meaning is contributed.

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+resource ('Generate ONE PDF from a template and your JSON data') and the 'ONE' framing implicitly contrasts with the sibling craftmypdf_create_pdf_from_templates. It never names that sibling, so the differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a clear prerequisite chain ('Look the template up with craftmypdf_list_templates / craftmypdf_get_template first') and names the underlying POST /create. It does not, however, say when to choose this tool over craftmypdf_create_pdf_from_templates.

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 only flag it as a non-idempotent write; the description adds material context they don't carry: credit consumption per template rendered, that identical-data retries still bill, hosted URL expiry tied to `expiration` minutes, and latest-version resolution. No contradiction with destructiveHint=true since the billable write profile is disclosed.

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?

Front-loaded with a 'WRITE:' signal and the credit warning, then the operation, then the return value and endpoint. No filler sentences, but the parenthetical cost clause is dense enough that it competes with the core purpose statement for attention.

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, the description still explains the return (expiring hosted URL), the cost model, count limits, and the underlying endpoint. Minor gaps remain — no mention of failure/retry behavior or what happens if a template id is invalid.

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 baseline is 3. The description adds the cost consequence of the `templates` array size, the data fallback relationship, and expiry semantics behind `expiration` — meaningfully more than restating the fields, though `paging` and `output_file` get nothing.

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 with exact scope: 'Generate ONE combined PDF from 2-10 templates, each with its own data (or the shared `data`)'. This clearly distinguishes it from sibling craftmypdf_create_pdf (single template) and craftmypdf_merge_pdfs (existing PDFs) without needing the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear conditions for use — 2-10 templates, per-template data with shared fallback, latest template versions — and connects cost to template count. It never explicitly names the alternatives (create_pdf, merge_pdfs) or states when NOT to use it, so routing still requires inference from sibling names.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds meaningful context beyond that by disclosing exactly what account data is returned and scoping it to the API key's account. It does not mention auth requirements or rate limits, so it is not top-tier.

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 sentences with no filler: the resource and its returned fields come first, the usage hint second, and the endpoint path is a useful trailing anchor. 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?

With no input parameters and no output schema, the description does the necessary work by enumerating the response fields an agent would care about (quota usage and limits, template counts). It omits any mention of error behavior or auth expectations, which keeps it just short of complete.

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 the schema carries no semantics to explain and the baseline of 4 applies. The description correctly implies a parameterless call scoped by the API key.

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 CraftMyPDF account behind the API key') and enumerates the returned fields (username, quota_counter, quota_max, template count/limit, creation date). This clearly separates it from siblings like get_pdf_info, get_template, and list_transactions.

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?

Explicitly tells the agent when to call it: 'Check the quota before generating many documents.' That is a concrete triggering condition. It stops short of naming an alternative or a when-not-to-use case, so it is not a full 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, openWorldHint=true, and destructiveHint=false, covering safety and openness. The description adds that the PDF is fetched from a public https URL and warns that the call may count against the account's rate limit, providing useful context beyond annotations. It could have disclosed timeout or error behavior but is sufficient.

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 two concise sentences: one detailing what metadata is returned and the source, and a second noting rate limit and the API endpoint. No wasted words; the purpose is front-loaded.

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 a single fully documented parameter and rich annotations, the description is largely complete. It covers the source (public https URL), returned fields, and rate limit warning, but does not mention potential errors for invalid URLs or output format details (though no output schema exists).

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 parameter is fully documented in the schema. The description adds that the URL must be public and https, reinforcing the constraint, but does not add much beyond that. Baseline is 3, but the extra 'public https' qualifier earns a 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 states a specific verb (retrieves metadata) and resource (PDF downloaded from a public https URL) and lists the exact metadata fields returned. This clearly distinguishes it from siblings like craftmypdf_create_pdf or craftmypdf_merge_pdfs.

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 the tool is used when you need metadata about an external PDF, but does not explicitly state when to choose this over alternatives or any preconditions such as the URL must be public and https. Usage is only loosely implied.

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, openWorldHint=true, destructiveHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: the sample JSON is what fills in at generation time, and the full layout body is only fetched with include_body and may be truncated because it is very large.

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?

Front-loads the return payload before the include_body caveat, and every clause carries information. The trailing 'GET /get-template' is mildly redundant but harmless for orientation.

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, the description steps in to say what is returned (name plus sample JSON) and what include_body conditionally adds, which is enough for correct invocation. It does not cover error behavior or pagination, but neither is relevant for a single-resource fetch.

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 template_id, version, and include_body in detail (including the 40000-char cutoff and version source). The description's mention of include_body and the sample-data payload adds only marginal meaning on top of that, 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?

States a clear verb (get) and resource (one template), and specifies exactly what comes back: the name and the sample JSON placeholder data. The phrase 'One template' distinguishes it from the sibling craftmypdf_list_templates without the agent opening either 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?

Usage is implied (fetch a single template's detail), but there is no explicit when-to-use guidance and no named alternatives such as craftmypdf_list_templates for discovery or craftmypdf_list_template_versions for version history. The include_body note hints at a tradeoff but never frames it as a decision rule.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the description's "Read only" line largely restates structured data. It adds the concrete endpoint (GET /list-templates) and the fact that editing is not possible here, but says nothing about pagination behavior, ordering, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with what is listed, then why it matters, then the constraint. 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?

No output schema exists, and the description compensates by naming the fields returned. Combined with complete schema descriptions and read-only annotations, an agent has everything needed to call this 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% — limit, offset (with next_offset guidance) and group_name are all documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.

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 (list account PDF/image templates) and enumerates the returned fields (template_id, name, status, group, timestamps), which distinguishes it from sibling craftmypdf_get_template and craftmypdf_list_template_versions.

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 template_id is what the generation tools need" gives clear context for why an agent would call this before craftmypdf_create_pdf, and "templates cannot be edited here" rules out a mutation use case. It stops short of explicitly contrasting with get_template or list_template_versions, so it is not a full when/when-not/alternative 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by describing the returned fields (version number, description, time, retention) and the pinning workflow, but doesn't mention pagination or retention semantics. With annotations carrying the core behavioral load, a 3 is appropriate.

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 zero waste: the first states what is returned, the second states how to use it, and the endpoint is tacked on without disrupting flow. It is front-loaded with the resource definition.

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 tool with no output schema, the description is nearly complete: it tells the agent what fields come back and the key operational use case. It could mention that the list is scoped to a single template or whether versions expire, but the gap is minor.

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 template_id parameter is fully documented in the schema. The description doesn't redundantly explain the parameter, which is fine. However, it conveys the semantic link between the returned version number and downstream usage, adding faint conceptual value 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 opens with a specific verb+resource: 'The saved versions of a template.' It enumerates the returned fields and even the endpoint, so an agent can distinguish this from siblings like craftmypdf_get_template or craftmypdf_list_templates without opening the 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 provides a clear usage context ('Use a version number when generating to pin the layout'), which tells the agent why and when to call it. It doesn't name an explicit alternative to avoid, so it falls short of a 5, but the operational purpose is clear.

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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint), so the description only needs to add context – and it does: result ordering ('newest first'), the transaction type values (PDFGEN, PDFPREVIEW), and the underlying route (GET /list-transactions). It stops short of noting pagination/next_offset behavior, but that is documented in the schema.

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 the resource and field inventory front-loaded, followed by a short usage clause and the route. The field list is dense but earns its space since there is no output schema; only minor trimming possible.

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, the description carries the return-value burden and does so by enumerating the returned fields, which is exactly what an agent needs. Ordering, field set, and route are covered; pagination is handled in the schema, so the gap is small.

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 limit and offset are already fully documented in the schema, including the next_offset chaining hint. The description adds nothing about either parameter, so the baseline 3 is the correct score.

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?

Clear verb+resource ('Recent generation transactions of the account') plus a full enumeration of returned fields (transaction_ref, type, execution time, credits used, etc.), so the agent knows exactly what comes back. It does not, however, differentiate itself from the sibling craftmypdf_query_template_usage, which plausibly overlaps on the 'what was billed' theme.

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?

'Use it to see what was billed' supplies a concrete use case, which is more than no guidance. But there is no when-not condition and no routing to the overlapping sibling query_template_usage, leaving the agent to infer which of the two to pick for usage/billing questions.

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?

Adds substantial context beyond the annotations: billing behavior (credits, every call counts even with identical data, consistent with idempotentHint=false), that CraftMyPDF downloads the files server-side, and that the returned hosted URL expires. This goes well past the destructiveHint/readOnlyHint flags and materially affects how an agent should invoke it.

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?

Front-loads the WRITE/billing warning, then covers input, processing, and output in tight sentences. Every sentence carries information and the endpoint is appended cleanly.

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 tool with no output schema, the description fully specifies the return contract (hosted file URL that expires after `expiration` minutes), the input contract, and the account-credit implications. Nothing an agent needs to call 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?

Schema description coverage is 100%, so urls, expiration, and output_file are already documented, including the 2-10 range, the default, and the naming pattern. The description adds only a marginal note tying output expiry back to `expiration`; no syntax or format detail 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?

States a specific verb and resource ('Merge 2-10 existing PDFs ... into ONE PDF'), names the input format (public https URLs) and the output (one PDF). It clearly distinguishes itself from the creation siblings like create_pdf and create_pdf_from_templates, which generate new documents rather than combining existing ones.

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 makes clear the scenario: you must already have existing PDF URLs to merge, ruling out the create_* siblings implicitly. It does not, however, explicitly name an alternative tool or state when-not to use it, so the guidance is contextual but not exhaustive.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without description help. The description adds the 20-template ceiling and optional date-range scoping, but says nothing about the shape of the statistics returned or whether the count is aggregated over the range, so it adds only modest context beyond structured data.

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 compact sentences with the resource and scope front-loaded and the format example tucked in afterward. The trailing endpoint string is mildly redundant but costs almost nothing.

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 a fully covered schema, annotations handling the safety profile, and no output schema to describe, the definition covers what an agent needs to invoke the call. The only shortfall is that it does not hint at the returned statistic's structure, which would be helpful given there is no output schema.

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 documents template_ids (with example and pattern), start_date and end_date. The description restates the ISO 8601 UTC format with an example but offers no additional semantics such as what happens when dates are omitted or how the range is applied. Baseline 3.

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 — usage statistics (generation counts) for templates over an optional date range — and even includes the underlying endpoint. It is clearly distinguishable from mutation/inspection siblings like craftmypdf_get_template or craftmypdf_merge_pdfs, though it does not explicitly contrast itself with potential lookalikes such as craftmypdf_list_transactions.

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 explicit when-to-use or when-not-to-use guidance and no named alternatives. The 'optional date range' note implies a use case but the agent is left to infer that this is the tool for reporting/metering purposes versus merely listing resources.

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