Caliper

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

The annotations (all false) provide minimal safety profile, so the description carries the burden. It adds valuable behavioral context: 'Free, no payment required,' 'Requests are logged and used to prioritize development,' and a privacy policy link. This discloses the non-destructive, submission-like nature of the tool, though it doesn't describe the response or confirmation mechanism.

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, front-loaded with the core purpose, and includes only essential info: usage guidance, examples, cost note, and privacy link. Every sentence adds value, with no redundant fluff.

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 tool with no output schema, the description is complete. It covers purpose, usage, cost, privacy, and outcome (logged for prioritization). Sibling tools are clearly distinguished, and the description provides enough context for an agent to know when to invoke this 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 coverage is 100%, so the baseline is 3. The description reinforces the parameter meaning with examples (STEP file support, volume comparison) but does not add material new semantics beyond the schema, which already contains the same examples. No additional parameter details are provided in 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 begins with 'Request a feature or format that Caliper doesn't support yet,' which clearly states the action (request) and the resource (feature or format). It explicitly differentiates from sibling format tools by focusing on unsupported capabilities, making it distinct from format_* tools that handle existing formats.

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

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

The description provides explicit when-to-use guidance: 'Use this when you need a capability that Caliper doesn't currently offer — especially unsupported file formats (STEP, IGES) or analysis features not yet available.' It also mentions the request is logged for prioritization, giving clear context for when this tool is appropriate versus alternative format 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?

Annotations already mark the tool as readOnly, idempotent, and openWorld. The description adds substantial behavioral context: it returns metadata such as bounding boxes and triangle counts, has file size thresholds, may require payment for larger files, and requires retrying with payment proof. It also reiterates the read-only nature without contradicting the annotations.

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

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

The description is longer than ideal, but each section (purpose, formats, input modes, pricing, payment) is relevant to invoking the tool correctly. Some phrases like 'STEP and IGES support is planned' and the privacy link are not directly actionable but are minor.

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?

Despite having no output schema, the description names the key returned metadata categories and explains input constraints, supported formats, and the payment/retry workflow. This is sufficient for an agent to select and invoke the tool correctly, especially with the sibling list providing format-specific alternatives.

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% and each parameter already has a detailed description. The description adds a high-level usage rule ('Provide either file_url ... or file_b64') and explains the payment retry flow, which adds meaning beyond the schema's per-field descriptions.

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 opening sentence 'Auto-detect geometry file format and extract metadata statistics' clearly states the tool's function. It also explicitly distinguishes itself from conversion/mesh-repair tools by stating it does not perform mesh repair, format conversion, or boolean operations, and it lists supported formats.

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 for when to use this tool (read-only analysis of geometry files) and states what it does not do (format conversion, boolean operations). However, it never explicitly names sibling tools like format_stl or format_batch as direct alternatives, so the 'vs alternatives' guidance is implicit rather than fully explicit.

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 significant behavioral context beyond annotations: payment requirements (x402/MPP), the two-step flow (initial call returns price, retry with payment), partial success handling, and a privacy policy link. This greatly aids the agent in understanding side effects and expected 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 well-structured and efficient. It opens with a clear purpose, then covers payment, partial success, and privacy in a logical order. Every sentence adds value with no redundancy.

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 explains what to expect: a single quote, structured metadata for all files, and if no payment, a price breakdown. It also addresses partial success and payment flow, making it complete for this 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 coverage is 100%, so both parameters are already documented. The description adds useful context on the payment retry flow ('If no payment is provided, the response includes the total price and per-file breakdown. Retry with the payment argument...') and reiterates the 10-file limit, which enhances understanding 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 clearly states 'Analyze multiple geometry files in a single batch request' with a specific verb ('Analyze') and resource ('geometry files'), and the batch scope distinguishes it from siblings like format_detect or format_stl.

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

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

The description provides clear context for when to use the tool: batch analysis of multiple files with mixed formats, and explicitly states what it does not do ('does not modify, convert, or repair files'). It does not name alternative tools, but the exclusions and batch context are sufficient.

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 complements the annotations (readOnlyHint, idempotentHint) by adding useful behavioral context: it returns the detected format and supported status, and importantly notes 'No payment required.' It does not contradict the annotations and provides transparency beyond the 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?

The description is three concise sentences, each contributing value: what it does, what it returns, and when to use it. No wasted words; the privacy policy link is supplementary and doesn't detract.

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 detection tool with one well-documented parameter, annotations, and sibling context, the description covers the essential behavior, return value, and use case. It is fully adequate for an agent to select and invoke the tool 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?

The schema already provides a complete description for the single filename parameter ('Filename or URL to check. The format is detected from the file extension.'). The description repeats this idea without adding extra syntax or format details, so it meets the baseline for high 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 uses a specific verb 'Detect' and names the resource 'geometry file format from a filename or URL.' It clearly distinguishes itself from sibling format tools by focusing on pre-analysis format checking rather than conversion or processing.

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

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

The description explicitly states when to use the tool: 'Use this to check format support before making a paid analysis call.' It provides clear context but does not explicitly 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?

Annotations already declare readOnlyHint=true, ensuring the agent knows it is a safe read. The description adds valuable behavioral context by specifying what data is returned (asset info, scene graph, counts, feature flags, etc.) and the payment requirements via x402 or MPP. This goes beyond the annotations without contradicting them.

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 of core purpose and output, plus one sentence on payment and privacy. Every sentence earns its place, and the most important information is front-loaded. No irrelevant 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?

With no output schema, the description fully compensates by listing exact return contents (counts, feature flags, primitive modes, extensions). It also covers payment prerequisites and file size limits, making it complete for an agent to decide when and how to invoke.

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 all parameters thoroughly. The description does not add significant parameter-level detail beyond what is in the schema, but it does mention payment methods which relate to the payment parameter. This meets the baseline for schema-heavy 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 'Extract metadata from a glTF or GLB file.' This provides a specific verb (extract), resource (glTF/GLB file), and the tool name and title align perfectly. It distinguishes itself from siblings like format_obj and format_stl by targeting a specific format.

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: it is for glTF/GLB files. It also references format_auto for payment flow details, which provides some cross-tool guidance. However, it does not explicitly state when not to use it or mention alternative format-specific tools, so there is a minor gap in exclusions.

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 provide readOnlyHint=true, idempotentHint=true, and openWorldHint=true. The description adds value by disclosing the specific return fields (point count, scale factors, offsets, bounding box, etc.) and payment methods (x402 and MPP). It does not contradict annotations and offers contextual detail beyond the structured hints, though it omits potential failure modes.

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 three short sentences/paragraphs: purpose first, then the return payload, then payment/privacy. Every sentence carries essential information with no redundancy or filler. It is front-loaded and easy to scan.

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

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

The tool has no output schema, so the description needs to convey what the agent can expect back. It lists the metadata fields comprehensively. It also explains payment prerequisites and points to a sibling for flow details. Some might argue for more depth on output structure, but given the moderate complexity and effective use of annotations, the description is sufficiently 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?

Schema description coverage is 100% — all four parameters (payment, file_b64, file_url, filename) have detailed descriptions in the input schema. The tool description itself adds no parameter-specific information, so the baseline of 3 applies. The schema already explains semantics thoroughly.

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

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

The description uses a specific verb 'Extract metadata' and a precise resource 'LAS or LAZ point cloud file', making it immediately clear what the tool does. It also enumerates the exact metadata returned (LAS version, point format, etc.), which distinguishes it from other format_* sibling 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 first sentence clearly tells the agent when to use this tool (for LAS/LAZ point cloud files), which implicitly separates it from siblings handling other formats. However, it does not explicitly name alternatives or state exclusions, and the reference to format_auto is only for payment flow, not for selecting an analysis tool. So it is clear but not fully explicit.

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 provide readOnly and idempotent hints, so the description doesn't need to restate them. It adds valuable behavioral context by disclosing the payment requirement (x402/MPP) and pointing to format_auto for flow details, which goes beyond the annotations and informs the agent of a necessary precondition.

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 compact paragraphs with no fluff. The first sentence front-loads the purpose, the following sentences list return metrics and payment info concisely. Every sentence serves a clear informational role, and the privacy policy line is a minor but acceptable addition.

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 tool's purpose, return values, and payment requirements, complementing the detailed schema well. It could more explicitly clarify that this tool is for OBJ files only versus the other format_* siblings, but the tool name and first line already convey that, making the description largely complete for an agent to select and invoke 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?

All four parameters have detailed descriptions in the schema, achieving 100% coverage. The tool description itself does not add extra parameter-level meaning, so it neither compensates for gaps nor repeats schema content; this aligns with the baseline 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?

The description opens with 'Extract metadata from an OBJ file', which pairs a specific verb with a well-defined resource. It then enumerates concrete return metrics (vertex counts, bounding box, surface area, etc.), clearly distinguishing it from sibling tools that target other file formats.

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 establishes when to use the tool: for OBJ files, by explicitly naming the format. It also references format_auto for payment flow details, which is useful context. However, it does not explicitly name alternative tools for other formats or state when not to use this tool, so it stops short of full exclusionary guidance.

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 provide readOnlyHint and idempotentHint, so the description need not restate safety. It adds behavioral context about payment requirements (x402/MPP) and the return categories, which are meaningful for an agent deciding whether to invoke the tool and anticipating conditional payment steps. No contradiction with annotations.

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

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

The description is well-structured: purpose, returns, payment info. It is fairly concise, though the privacy policy URL adds slight noise. Every sentence carries useful information, with the return list and payment details being genuinely helpful.

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 rich schema and absence of an output schema, the description compensates by listing key return fields. It also mentions payment methods, which is important for operational context. However, it relies on a cross-reference to format_auto for payment specifics and does not explicitly state the need to provide one of file_b64 or file_url, though this is covered by schema descriptions.

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%, with each parameter having a detailed description. The tool description does not add extra parameter-related meaning, so the baseline of 3 is appropriate. It only mentions return aspects, not parameter semantics.

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 'Extract metadata from a PCD point cloud file,' which is a specific verb+resource combination. It clearly distinguishes itself from sibling format_* tools by naming the PCD format and enumerating the metadata returned, making its purpose unambiguous.

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 clear usage context: use for PCD files when metadata extraction is needed. It does not explicitly contrast with alternatives like format_ply or format_las, but the format-specific scope is sufficiently evident. The reference to 'See format_auto for payment flow details' is a cross-reference about payment, not usage, so it does not serve as an alternative-selection guideline.

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 provide readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is known. The description adds value by detailing the exact metadata returned, the supported file formats, and the payment requirement (x402 or MPP), which are not inferable from annotations alone.

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 appropriately concise and front-loaded: it opens with the core purpose, then lists return values, and finally payment/privacy info. Every sentence contributes necessary information without redundancy.

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 compensates by listing the expected return fields (counts, features, bounding box, centroid, etc.), making the tool's behavior clear. Combined with thorough schema parameter documentation and annotations, it gives an agent sufficient context to invoke the tool correctly, including payment flow reference.

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

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

The schema provides 100% coverage of all four parameters with detailed explanations, so the baseline is 3. The description does not add new parameter-level details but reinforces that the tool handles PLY files in both ASCII and binary forms, which indirectly informs file handling.

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 it extracts metadata from a PLY file, supporting both ASCII and binary formats, and enumerates specific outputs (vertex/face counts, feature detection, bounding box, centroid). This distinguishes it from sibling format_* tools by specifying the PLY file type as the target.

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

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

The description clearly implies usage for PLY files, and the sibling tool list indicates alternatives for other formats. However, it does not explicitly name those alternatives or state exclusion criteria, though it does reference format_auto for payment flow details.

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 annotations (readOnlyHint, openWorldHint, idempotentHint) already establish the tool's safety profile. The description adds meaningful behavioral context by enumerating the exact computed metrics (triangle count, manifold analysis, noise estimate, etc.) and disclosing payment requirements (x402/card). It does not contradict annotations and provides additional transparency about the analysis performed.

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 appropriately concise: a single sentence defining purpose and a list of outputs, followed by a sentence about payment and privacy. Every sentence adds value, no filler. The structure front-loads the core purpose and then details outputs and practical instructions.

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, the description carries the burden of explaining what the tool returns, and it does so comprehensively with a detailed list of metrics. It also covers payment methods, privacy policy, and a pointer to format_auto for payment flow details. It is slightly incomplete regarding when to use this tool versus format_auto or format_detect, but for a read-only analysis tool, the essential context is covered.

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% – all four parameters have detailed descriptions in the input schema. The description does not add significant new parameter semantics beyond pointing to format_auto for payment flow, which relates to the payment parameter. Since the schema already explains each parameter, the description's contribution here is marginal, matching the baseline of 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 clearly states the tool's function: 'Extract metadata from an STL file (ASCII or binary).' It names the specific file format (STL) and the action (extract metadata), which distinguishes it from sibling format_* tools like format_obj or format_ply. The listed output metrics further clarify its purpose.

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 by the tool name and description (use for STL files), but there is no explicit guidance on when to choose this over format_auto or format_detect. The only alternative mentioned is 'See format_auto for payment flow details,' which addresses payment flow, not tool selection. No exclusions or when-not-to-use instructions are provided.

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