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

With no annotations, the description carries the behavioral disclosure burden. It clearly reveals that this is a POST/mutating operation, that it advances the sequence by its configured step, and that it returns the updated record. It does not mention authentication, idempotency, or irreversibility, but the core side effect is explicitly 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?

Two short sentences contain the endpoint, the action, the sequencing behavior, and the return value. There is no filler, and the most identifying information 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?

This is a simple tool with one required parameter and no output schema or annotations. The description covers what the tool does, how it does it via the endpoint, and what it returns. Minor gaps such as error behavior and prerequisite existence of the sequence prevent a perfect score, but the essential calling context is present.

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 0%, so the description must compensate. The path segment '/sequences/{name}/bump' indicates that 'name' is the sequence name, which is useful, but it does not explain what sequences are eligible, whether the name must already exist, or any formatting constraints. It adds some meaning beyond the bare schema but not complete parameter guidance.

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 ('bump'), a specific resource ('sequence'), and gives the exact HTTP endpoint. It also states the observable effect—advancing the sequence by its step and returning the updated record—making it clearly distinct from sibling operations like update_sequence or get_sequence.

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

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

There is no guidance on when to use this tool versus alternatives such as update_sequence, get_sequence, or create_sequence. The action is described, but no context, prerequisites, or exclusions are provided, so an agent must infer when bumping is appropriate.

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, and it reveals important behavior: response differs by batch size (200 with results vs 202 with only batchId/status/seed) and requires polling for larger batches. It also mentions optional relations cross-referencing. It stops short of noting permissions or side effects beyond creation, so not a 5.

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 three-sentence description is tight and front-loaded: endpoint, purpose, then the sync/async split with follow-up action. No filler or repetition.

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

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

The description covers the core request/response lifecycle and even names the polling sibling, which is strong. However, for a 4-parameter tool with nested document objects and 0% schema description coverage, leaving namespace and seed semantics unexplained makes it incomplete 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?

Schema description coverage is 0%, so the description must compensate, but it only clarifies `relations` and the response `seed`; it does not explain the `seed` input, `sequenceNamespace`, or `variableNamespace`, nor per-document `alias`, `count`, or `params`. The schema gives types only, so an agent would still guess at key parameter meanings.

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?

Description names the HTTP endpoint and a specific verb ('Generates multiple documents from one or more templates in one call'), making the batch-generation intent unmistakable. It also distinguishes itself from siblings by noting single-call multi-document generation and the polling path via jsonfabrica_get_batch, which separates it from single-document/generation tools.

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 concrete context for when the synchronous vs async behavior applies ('small batches run synchronously... larger batches are queued') and tells the agent to poll jsonfabrica_get_batch in the async case. It does not explicitly enumerate when not to use this tool versus generate_adhoc or generate_from_template, but the batch/multi-template framing implies the primary use case.

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 behavioral burden. It does disclose persistence ('durable') and the template-integration behavior, which goes beyond a bare 'create' statement. However, it does not say what happens on duplicate names, whether step/start are honored, or what the response contains.

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

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

The description is one tightly written sentence that leads with the HTTP method and endpoint, then states what is created and how it is used. There is no filler or repetition of the tool name.

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

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

Given four parameters with zero schema descriptions, no output schema, and no annotations, the description is not complete enough to call the tool with confidence. It communicates the high-level purpose but leaves parameter semantics, error behavior, and return value unspecified.

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 0%, and the description only loosely maps to the parameters: '(number/string/uuid)' explains the type enum and 'named' implies the name parameter. The optional step and start parameters are not explained at all, and the description fails to compensate for the schema's lack of property documentation.

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 the explicit endpoint 'POST /v1/sequences' and a clear verb-resource pair: 'Creates a durable named sequence'. It also clarifies the sequence's role in templates via createSeq()/getSeq(), which helps distinguish it from sequence management siblings like get, update, or delete.

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 context: this tool creates sequences that templates can reference through createSeq()/getSeq()-style functions. It does not explicitly state when not to use it or name alternative tools, but the template-referencing context is enough to signal its primary use case among the many 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?

With no annotations provided, the description carries the full burden and does well: it discloses the HTTP call, the response shape when generate is provided vs omitted, and documents the placeholder syntax with examples. It does not mention error conditions, authentication, or idempotency, but the create semantics are straightforward.

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-loads the endpoint and core action, then explains the placeholder syntax and the conditional behavior of generate. The examples and conditional explanation are valuable, but the sentence is long and could be split for easier scanning.

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 nested generate object and no output schema, the description covers the most important context: endpoint, placeholder syntax, and the two distinct request/response modes. It lacks an example of a full request object and does not explain tags, but the core usage is sufficiently complete for an agent to invoke creation 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 40%, and the description adds meaning for body and generate, including examples of placeholder syntax and the shape of the response. However, it does not add semantics for name, tags, or description beyond what the schema provides, and the generate object's seed/params/context fields rely fully on 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 explicitly names the HTTP endpoint (POST /v1/templates), the verb (creates), the resource (a reusable template), and the key behavior (reusable template with placeholder syntax). It differentiates from siblings like generate_from_template and update_template by framing creation 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?

It clearly states when to use this tool: to create a template, with an optional same-call generation. It does not explicitly name alternatives like update_template or generate_from_template, but the purpose is distinct enough that an agent can infer when to choose it. The optional generate behavior is clearly explained.

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 behavioral transparency burden. It discloses the DELETE method and the success response (no content), which signals a destructive operation. It does not explicitly state that deletion is permanent or irreversible, nor does it cover auth requirements or error behavior.

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 with no filler. It front-loads the essential HTTP call and immediately states the success response, making every word valuable.

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 delete operation with no output schema, the description covers the crucial invocation details: HTTP method, resource path, required parameter, and success response. It omits non-essential details like 404 behavior or idempotency, which are less critical for correctly invoking the 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?

Schema description coverage is 0%, but the description compensates by showing that `name` is the path parameter in `/v1/sequences/{name}`. This tells the agent that the parameter identifies the sequence to delete, which is meaningful beyond the bare schema field of type string.

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 the exact HTTP DELETE call and resource path, making it clear that this tool deletes a specific JsonFabrica sequence by name. It is immediately distinguishable from sibling tools like create_sequence, update_sequence, and delete_template because the endpoint and resource are explicit.

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 the tool: when a sequence needs to be deleted by name. However, it does not explicitly provide when-to-use or when-not-to-use guidance, mention prerequisites, or contrast itself with alternatives such as delete_template.

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 behavioral disclosure burden. It reveals the destructive HTTP method and states that the removed template record is returned, but it does not mention whether deletion is permanent, what happens to dependent resources, or error behavior for invalid templateIds.

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 short sentences deliver the operation, endpoint, and return value with no unnecessary wording. The most important behavioral information 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?

For a simple one-parameter delete tool with no output schema, the description covers the call semantics and return value adequately. It omits an explicit irreversibility warning and error handling, but the core context an agent needs to invoke the tool correctly is present.

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%, but the URL template /v1/templates/{templateId} clearly indicates that templateId is the path identifier of the template being deleted. This adds meaning beyond the bare schema field, though it does not explain how to obtain the ID or specify any format constraints.

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 operation: it calls DELETE on the template resource identified by templateId. The HTTP method and resource path unambiguously distinguish it from create, update, generate, and get tools for templates and sequences.

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

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

The intended use is implied by the name and DELETE verb: remove a JsonFabrica template. However, the description does not explicitly say when to prefer it over sibling delete_sequence or mention prerequisites such as obtaining a valid templateId.

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 and does an excellent job: it discloses that no template record is created, that billing/usage metering still applies, and that createSeq()/durable sequence side effects still occur with advice on avoiding namespace collisions. This goes well beyond the obvious and is genuinely useful for safe invocation.

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 with no filler: endpoint, core behavior and use case, then the two most important caveats. The 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?

The description is strong for a complex tool with no annotations and no output schema: it covers side effects, billing, and namespace safety. The main gaps are the unaddressed seed/params/context parameters and the lack of any detail about the response shape, but the core invocation guidance is solid.

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 0% description coverage, but the description adds meaning for body (raw template string) and for sequenceNamespace/variableNamespace (isolation from real tenant sequences). However, seed, params, and context remain unexplained, so the description only partially compensates for the lack of schema documentation.

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: it calls POST /v1/templates/generate and produces a document from a raw body string without persisting a template. This directly distinguishes it from siblings like jsonfabrica_create_template and jsonfabrica_generate_from_template, so an agent can tell them apart.

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 frames the tool as useful for quickly iterating on template syntax and warns that it is not a billing bypass compared to persisted-template generation. It does not explicitly name alternative tools or say 'use X instead', but the intended context 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that generation can have sequence/variable side effects and explains how to isolate them across environments. However, it does not describe the response format, whether the operation is idempotent, or how seed, params, and context affect generation.

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 concise: two sentences, no filler, with the core operation and endpoint first and the namespace guidance second. It is efficiently structured, though the endpoint duplication is slightly redundant with 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 six parameters, no annotations, no output schema, and nested objects, the description is too sparse to be fully actionable. It provides minimal context about parameter semantics, return values, and edge cases, leaving significant gaps for an agent to infer.

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 0%, so the description must compensate for parameter meaning. It only clarifies sequenceNamespace and variableNamespace, leaving seed, params, context, and even templateId without added explanation. With two nested object parameters and no semantic guidance, an agent cannot confidently construct a correct invocation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Generates a document using a persisted template.' The endpoint is also given, making the operation explicit. It hints at a distinction from generate_adhoc via 'persisted template,' but the sibling tool is not named, so differentiation is not fully explicit.

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 concrete configuration instruction: 'Set sequenceNamespace/variableNamespace to isolate sequence/variable side effects between environments.' However, it does not explain when to choose this tool over generate_adhoc or other siblings, nor does it state any exclusions or prerequisites. The use case is implied by 'using a persisted template,' but not elaborated.

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 provided, so the description carries the full burden. It discloses that the tool performs a GET, returns batch status, and only returns generated documents once the batch is complete. The async 202 polling context is useful behavioral information beyond the bare endpoint.

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 tightly written sentences that lead with the HTTP operation and endpoint, then describe the return value and the intended polling use case. No filler or redundant content.

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/poll tool, the description covers the endpoint, what is returned, and when to call it. It does not describe error conditions, status values, or auth requirements, but those are not essential for basic 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% and the only parameter, batchId, has no description beyond its type. The description adds the URL path context (/v1/batches/{batchId}), confirming batchId is a path parameter, but it does not explain where the batch ID comes from or any format constraints.

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 the exact operation ('Calls GET /v1/batches/{batchId}') and the resource (batch), and explains what it returns. The description distinguishes it clearly from siblings like create_batch and generate_from_template by focusing on retrieval and polling.

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 use it: 'Use this to poll a batch that was accepted asynchronously (202).' This is clear contextual guidance, though it does not mention when not to use it or name alternative tools.

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 provided, so the description carries the burden. It discloses that this is a GET (read-only) operation and that it returns a sequence record. It does not cover error behavior, authentication, or not-found semantics, but the core behavior is stated.

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

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

The description is one concise sentence with no filler. It front-loads the HTTP method and resource, and the return value is stated immediately afterward.

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 GET-by-name tool with one required parameter and no output schema, the description is largely sufficient. It names the resource, the action, and the return value. It lacks examples or failure behavior, but the low complexity means no major gaps exist.

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 add meaning. The endpoint template '/v1/sequences/{name}' shows that 'name' is the path identifier of the sequence to retrieve. It does not explain naming rules or constraints, but it gives enough context to invoke the tool correctly.

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 HTTP verb and resource ('GET /v1/sequences/{name}') and what it returns ('the sequence record'). This clearly distinguishes it from sibling tools like list_sequences, delete_sequence, and bump_sequence.

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 usage is implied by the GET endpoint and the singular resource path: use this to fetch one sequence by name. However, there is no explicit guidance about when to choose it over list_sequences or other sibling tools.

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 available, the description carries the behavioral burden. It is transparent enough: the GET method clearly signals a read-only operation, and 'returns the full template record' states what the agent will receive. It does not mention error cases, but for a simple fetch this is only a minor gap.

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 short sentences with no filler. The HTTP endpoint is front-loaded, and the return value is stated immediately. 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 one-parameter GET tool with no output schema and no annotations, the description is complete enough: it specifies the exact endpoint, how the parameter is used, and what is returned. No additional context is needed to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It adds some meaning by showing templateId is used in the URL path, but it does not describe the expected format, constraints, or provide an example. The parameter name is self-explanatory, so the practical impact is small, but the description could still do more.

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 the exact HTTP verb and resource path, 'Calls GET /v1/templates/{templateId}', and states the outcome, 'Returns the full template record.' This clearly identifies a single-template retrieval operation and distinguishes it from list_templates or mutation tools.

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 GET path implies this should be used when the agent has a templateId and wants one full template record, but the description gives no explicit guidance about when to prefer this over list_templates or when not to use it. Usage context 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?

With no annotations, the description carries the full burden of behavioral disclosure. It states the HTTP method (GET, implying read-only), the exact endpoint, the returned fields, and that it applies to the configured API key. It does not discuss rate limits or error behavior, but for a zero-parameter read-only endpoint this is reasonably transparent.

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

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

A single sentence that front-loads the HTTP call, states the return shape, and clarifies authentication context. Every element earns its place with 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 parameterless GET endpoint with no output schema, the description is complete: it gives the endpoint, response shape, and auth context. Nothing critical is missing for an agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters and schema description coverage is 100%, so there is nothing for the description to add semantically. The description appropriately focuses on the endpoint and response instead of 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 names a specific verb-resource pair ('Calls GET /v1/usage') and specifies what it returns (`{ tenantId, usageTotal, asOf }`). This clearly differentiates it from sibling tools like health or whoami because it is the only tool targeting tenant usage.

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 signals the tool's purpose: retrieving tenant usage for the configured API key. It does not explicitly mention when not to use it or name alternatives, but the endpoint and return shape make the intended context obvious.

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 behavioral disclosure burden. It reveals the HTTP call type, the lack of authentication requirements, and the practical purpose of validating endpoint reachability. It does not describe response shape or error behavior, but for a simple health check the disclosure is reasonably complete.

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 convey the endpoint, authentication status, and intended use with no filler. The most important detail, the HTTP call, 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?

For a zero-parameter, no-output-schema health check, the description provides everything an agent needs: the endpoint, authentication requirement, and the exact verification scenario. Nothing critical 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, so there are no parameter semantics to clarify. The schema already fully covers the empty parameter list, and the description adds context about the endpoint and environment variable without needing to explain 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 names the exact HTTP method and resource ('GET /health'), and the scope is unmistakably a health check for the JsonFabrica gateway. It clearly stands apart from sibling tools, which all deal with templates, sequences, batches, or usage rather than connectivity.

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 it: to verify JSONFABRICA_API_URL points at a reachable gateway. It also notes that no authentication is required, giving useful operational context. It does not enumerate when not to use it or mention alternatives, but no sibling competes directly for this purpose.

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 behavioral burden. It discloses the HTTP method, the admin requirement, and the 403 failure mode, which is useful. However, it does not describe the success response contents, pagination, or any read-only guarantee beyond the GET verb.

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 endpoint is front-loaded and the auth caveat is immediately useful. Every word earns its place.

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

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

For a zero-parameter GET endpoint, the description covers the call target, the required auth role, and the error condition. The only notable omission is an explicit statement of the successful response format, but the title and endpoint strongly imply a list of weights.

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 fully covers everything. The baseline of 4 applies because there is no parameter meaning to convey and nothing to compensate for.

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: 'Calls GET /v1/admin/function-weights' and the title states 'List JsonFabrica generator function weights'. This unambiguously differentiates it from sibling update_function_weight and other list tools.

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 admin-role prerequisite is clearly stated, but there is no explicit guidance on when to choose this over alternatives. Usage is implied from the name and endpoint, but no when/when-not or alternative tool references are provided.

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 provided, so the description carries the full burden. It discloses that the operation is a GET (read-only) and that it returns a page with a nextCursor, which is important pagination behavior. However, it does not mention authentication requirements, default limit, ordering, or what happens when there are no sequences, which would provide fuller 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?

Two sentences, no wasted words. The endpoint is front-loaded, and the response shape is given compactly. Every sentence provides necessary 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 simple list endpoint with no output schema, the description is nearly sufficient: it gives the HTTP method, endpoint, and response pagination shape. It does not elaborate on parameter details or additional list behavior, but the core information an agent needs to call and interpret the response is present.

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 0%, so the description must compensate for the undocumented `limit` and `cursor` parameters. The mention of `nextCursor` strongly implies that `cursor` is a pagination token, and `page` implies `limit` controls page size. Yet the description does not explicitly define either parameter, leaving some inference required.

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 the exact endpoint (GET /v1/sequences) and explicitly states the return value: a page of sequences with `{ items, nextCursor }`. This is a specific verb+resource that clearly differentiates it from sibling tools like jsonfabrica_get_sequence (single sequence) or jsonfabrica_list_templates (different resource).

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: it lists sequences via the named endpoint. However, it does not explicitly state when to prefer this over alternatives, such as using get_sequence for a specific sequence or list_templates for templates. The guidance is present only by implication from the endpoint and resource.

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 behavioral disclosure burden. It does disclose that the operation is a GET and returns a page shape, which signals a read-only, paginated call, but it does not explain default filtering by status, ordering, or how name/tags affect results.

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 with no filler, front-loading the endpoint and core response shape. Every phrase 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?

An agent can make a basic list call, but with 5 optional parameters, no annotations, no output schema, and only 20% parameter documentation, the description is incomplete. It does not clarify name matching, cursor usage, status defaults, or how tags combine with other 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 description coverage is only 20%: only `tags` has a description in the schema. The prose description adds nothing about `name`, `limit`, `cursor`, or `status`, so the description fails to compensate for the low schema coverage.

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 the exact endpoint (GET /v1/templates) and clearly states it returns a paginated list of templates with `{ items, nextCursor }`. This distinguishes it from get_template, create/update/delete, and list_sequences by resource and verb.

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 verb 'List' and endpoint suggest it is the tool for retrieving multiple templates, and the paginated response implies it covers page-based browsing. However, there is no explicit statement of when to use it versus get_template, and no mention of alternatives or exclusions, so guidance 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?

Without annotations, the description carries the disclosure burden, and it does disclose the HTTP method, exact endpoint, auth role requirement, and the 403 error case. It does not describe success response or side effects beyond 'update', but the admin/403 detail is meaningful and non-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?

Two short sentences with no filler; the endpoint and auth constraint are front-loaded. 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 two-parameter PATCH with no output schema and no annotations, the description is serviceable: it pins down the resource, method, and auth. It omits the response shape and any detail about valid weight values, and does not point to list_function_weights as a way to discover function names, so an agent is left to infer these.

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 0%, so the description must provide meaning. functionName is inferable from the path template, but the description never explains what weight represents, its allowed range, or how it affects generation. An agent cannot tell whether weight is a ratio, percentage, or arbitrary multiplier.

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 concrete verb and resource: it calls PATCH on /v1/admin/function-weights/{functionName}, which unambiguously conveys an update operation. It is clearly distinct from the sibling list_function_weights because the method and endpoint indicate mutation rather than listing. The title's '(admin)' is reinforced by the description.

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 a clear prerequisite: the API key must have role=admin, and it names the failure mode (403) if not. However, it never states when to prefer this over related tools such as list_function_weights, nor does it explicitly exclude non-admin use beyond the implied auth requirement.

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 disclosure burden. It does reveal a key trait — partial update semantics, meaning unspecified fields are left untouched. However, it omits other behavioral facts: behavior on a nonexistent name, error status codes, response format, or whether updating currentValue affects future generation.

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

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

A single sentence that front-loads the HTTP method and endpoint before stating the change scope. Every word carries information and there is 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 simple 3-parameter PATCH tool with no nested objects and one required param, the description is largely adequate. But with no output schema and no annotations, it should have noted the return value (updated sequence vs empty response) and error behavior for missing sequences. It is also silent on how this differs from jsonfabrica_bump_sequence.

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 0%, so the description must compensate. It adds useful mapping by indicating name identifies the target sequence (path parameter) and that currentValue and step are the only mutable fields. But it still does not define what currentValue or step mean (e.g., that step is the increment size), leaving the agent to infer their roles.

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+resource: 'Calls PATCH /v1/sequences/{name}' with the scope 'Only the provided fields (currentValue, step) are changed.' This clearly distinguishes it from sibling operations like jsonfabrica_create_sequence, jsonfabrica_bump_sequence, jsonfabrica_get_sequence, and jsonfabrica_delete_sequence.

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 context is implied rather than stated: the PATCH semantics and 'Only the provided fields... are changed' indicate partial updates to an existing sequence, but the description never explicitly says when to choose this over alternatives such as jsonfabrica_bump_sequence for increments. No exclusions or alternative routing are given.

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

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

The description discloses a key behavioral trait: only provided fields are changed, indicating partial-update rather than full-replace semantics. It also reveals the HTTP method and endpoint. However, with no annotations at all, it does not cover authentication requirements, return values, error behavior, or side effects, leaving notable transparency gaps.

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

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

The description is extremely concise: two short sentences with no filler. The endpoint and the partial-update behavior are both front-loaded and meaningfully informative.

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 there is no output schema, no annotations, and 0% parameter documentation, the description is too sparse for an agent to call the tool correctly with confidence. It provides the endpoint and partial-update semantics but omits parameter meanings, required identifiers, return shape, and operational context.

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 0%, so the description must compensate, but it does not. It never mentions templateId, body, name, tags, or description, and 'provided fields' is only a generic abstraction. An agent gets no parameter-level guidance from the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the operation: updating a JsonFabrica template via PUT /v1/templates/{templateId}. The phrase 'Only the provided fields are changed' also signals partial-update semantics, which helps distinguish it from create or delete siblings. However, it does not explicitly name alternative tools or contrast them.

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

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

There is no guidance on when to use this tool versus jsonfabrica_create_template, jsonfabrica_get_template, or jsonfabrica_delete_template. No usage context, prerequisites, or exclusion conditions are provided. The description implies an update scenario but never states 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?

With no annotations provided, the description carries the behavioral burden. It clearly discloses the HTTP method, that the operation uses the configured API key, and the return shape. It does not mention error behavior for invalid keys, but for a simple read-only GET this is a minor gap.

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 sentence contains all essential information: endpoint, authentication context, and return fields. No filler or redundant wording.

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 identity-check tool, the description is almost complete: it states what is called, what auth is used, and what is returned. It could mention possible failure modes or that no side effects occur, but the low complexity makes this acceptable.

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 is empty, so there is no parameter information to add. The baseline of 4 applies because with no parameters, the description cannot be expected to explain 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 names a specific verb and resource ('Calls GET /v1/whoami') and states the exact return payload ({ tenantId, role }). This is immediately distinguishable from all sibling tools, which are focused on templates, sequences, batches, and usage rather than identity.

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 explicit guidance on when to use this tool versus alternatives, and no exclusions. The whoami concept implies checking the configured API key's identity, but that is left for the agent to infer rather than stated.

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