Caliper
Server Details
Geometry and CAD file metadata extraction for STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 10 of 10 tools scored.
Every tool has a clearly distinct purpose with no ambiguity. The general-purpose format_auto and format_batch tools cover multiple formats, while the format-specific tools (format_gltf, format_las, etc.) target individual formats, and feature_request serves a completely different administrative function. The descriptions clearly differentiate between auto-detection, batch processing, format detection, and format-specific analysis.
All tools follow a consistent snake_case naming pattern with clear verb_noun structure. The format_ prefix is used consistently for 9 out of 10 tools (format_auto, format_batch, format_detect, format_gltf, etc.), while feature_request follows the same naming convention for the remaining tool. There are no deviations in naming style or convention.
With 10 tools, this is well-scoped for a geometry file analysis server. Each tool earns its place by covering different aspects of the domain: general analysis (format_auto), batch processing (format_batch), format detection (format_detect), format-specific analysis (7 tools for different formats), and feature requests (feature_request). The count is neither too sparse nor overwhelming for the domain.
The tool surface provides excellent coverage for geometry file metadata extraction across multiple formats, with both general and format-specific tools. The inclusion of batch processing and format detection adds useful workflow support. The only minor gap is the lack of tools for actual mesh manipulation, repair, or conversion operations, but the server's stated purpose appears focused on analysis rather than modification, and feature_request allows users to request missing capabilities.
Available Tools
10 toolsfeature_requestRequest a FeatureAInspect
Request a feature or format that Caliper doesn't support yet.
Free, no payment required. 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. Requests are
logged and used to prioritize development.
Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| description | Yes | A short description of the feature or format you need. Examples: 'STEP file support', 'volume comparison between two files', 'export to USD format'. This helps prioritize development. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations indicate this is a non-destructive, non-idempotent write operation, the description reveals that requests are 'logged and used to prioritize development,' provides a privacy policy link, and states 'Free, no payment required.' This gives important context about the tool's impact and constraints that annotations alone don't cover.
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 efficiently structured with zero wasted sentences. It opens with the core purpose, immediately provides usage guidelines with specific examples, explains what happens to requests, and includes necessary policy information. Every sentence serves a clear purpose in helping an agent understand when and how to use this tool.
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 tool with good annotations and no output schema, the description provides complete contextual information. It explains the tool's purpose, when to use it, what happens to submissions, cost implications, and privacy considerations. The description compensates well for the lack of output schema by explaining the expected outcome (requests are logged for development prioritization).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents the single 'description' parameter. The tool description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation but doesn't provide extra value regarding 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 clearly states the tool's purpose: 'Request a feature or format that Caliper doesn't support yet.' It specifies the verb ('request') and resource ('feature or format'), and distinguishes it from sibling tools (which are all format-specific tools) by focusing on requesting unsupported capabilities rather than processing 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 usage 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 clearly defines when to use this tool versus the format-specific sibling tools, and mentions the alternative (existing supported formats).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_autoAuto-Detect and AnalyzeARead-onlyIdempotentInspect
Auto-detect geometry file format and extract metadata statistics.
Accepts a 3D geometry file via URL or base64 and returns structured
metadata: bounding boxes, triangle counts, manifold analysis, point
cloud statistics, and more. This is a read-only analysis tool — it
does not perform mesh repair, format conversion, or boolean operations.
Supported formats: STL, OBJ, PLY, PCD, LAS/LAZ, glTF/GLB.
STEP and IGES support is planned.
Provide either file_url (preferred for large files) or file_b64
(for files under 200KB). Include filename for format detection if
using file_b64. When using file_url, the format is detected from
the URL path extension; filename is not required.
Files under 150KB are free. Larger files cost $0.02/MB via x402
(USDC on Base) or card via MPP (Stripe; adds $0.35 surcharge).
If payment is required, the response includes payment details.
Retry with the payment argument containing the payment proof.
Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. The description adds significant context beyond annotations: it clarifies that the tool is read-only analysis, explains the exact return type (structured metadata), details the payment mechanism (free under 150KB, $0.02/MB thereafter, with two payment methods), and provides retry instructions. No contradictions 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 but somewhat lengthy. It front-loads the core purpose and constraints, then provides parameter guidance, pricing, and privacy policy. Every sentence adds value, but could be trimmed slightly (e.g., the separate 'Privacy policy' line could be omitted or merged). Overall, it is appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters with complex conditional behavior (payment, file size limits, two upload methods) and no output schema, the description is comprehensive. It explains the output (structured metadata), the payment flow, the file size and format constraints, and the retry mechanism. No missing context for correct tool 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 100% with descriptions for all 4 parameters. The description adds extra semantic value: for file_b64 it explains the 200KB limit and context window budget concern, for file_url it explains format detection from URL path, for filename it clarifies it is required only with file_b64, and for payment it explains the required fields for each payment method (x402 transaction details, MPP challenge/payload).
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 purpose: auto-detect geometry file format and extract metadata statistics. It lists specific metadata types (bounding boxes, triangle counts, manifold analysis, point cloud statistics) and distinguishes from sibling tools by explicitly stating it does not perform mesh repair, format conversion, or boolean operations. It also lists supported formats, leaving no ambiguity.
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 guidance on when to use this tool (for metadata extraction from 3D files), when not to use it (for repair, conversion, or boolean operations), and alternative tools are implied by sibling names. It also gives detailed parameter usage: when to use file_url vs file_b64, size limits, and filename requirement. Payment conditions and retry instructions are clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_batchBatch AnalysisARead-onlyIdempotentInspect
Analyze multiple geometry files in a single batch request.
Submit up to 10 files, receive a single quote, pay once, and get
structured metadata for all files. Supports mixed formats. Read-only
analysis — does not modify, convert, or repair files.
Payment is required via x402 (USDC on Base) or card via MPP (Stripe). If no payment is provided,
the response includes the total price and per-file breakdown. Retry
with the payment argument containing "transaction", "network", and
"priceToken".
Partial success: if some files fail processing, you still receive
results for the files that succeeded.
Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| files | Yes | JSON array of file descriptors. Each object has optional keys: "file_url" (HTTP/S URL), "file_b64" (base64 string), "filename" (for format detection). Provide either file_url or file_b64 per file. Max 10 files per batch. | |
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: read-only (matches readOnlyHint), partial success handling, and detailed payment retry mechanics. While annotations already cover readOnly and idempotent, the description adds valuable context about payment flow and failure handling.
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 front-loaded with purpose. It is relatively compact given the complexity, with each sentence adding necessary information. Minor redundancy could be trimmed, but overall it is efficient and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch processing, payment, partial success) and lack of output schema, the description covers all essential aspects: constraints, payment flow, read-only nature, and result structure. It also provides a privacy policy link, making it fully informative for an agent.
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 baseline is 3. The description does not add significant new meaning to the parameters beyond what the schema already provides (e.g., file descriptor keys, payment proof format). It explains the retry flow but that is more about usage than 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 clearly states the tool's purpose: 'Analyze multiple geometry files in a single batch request.' It uses a specific verb (Analyze) and resource (multiple geometry files) and distinguishes itself from sibling single-file tools by emphasizing batch processing and mixed format support.
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 on when to use the tool: for batch analysis of up to 10 files, with payment and retry flow. It implies differentiation from single-file tools through the batch focus, but it does not explicitly state when not to use or name alternatives. Thus it is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_detectDetect File FormatARead-onlyIdempotentInspect
Detect the geometry file format from a filename or URL.
Returns the detected format name and whether it is currently supported.
Use this to check format support before making a paid analysis call.
No payment required. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Filename or URL to check. The format is detected from the file extension. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it discloses that 'no payment required' (financial aspect), mentions a privacy policy URL, and explains the return values. Annotations cover read-only, closed-world, and idempotent hints, so the description doesn't contradict them but enriches understanding with practical constraints and outcomes.
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 highly concise and well-structured: the first sentence states the core purpose, the second explains returns, the third provides usage guidelines, and the fourth adds behavioral details. Every sentence earns its place with no wasted words, and key 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?
Given the tool's low complexity (1 parameter, no output schema), the description is complete enough. It covers purpose, usage, behavioral traits (payment, privacy), and return values, compensating for the lack of output schema. Annotations provide additional safety and idempotency context, making this well-rounded for agent understanding.
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 fully documents the single parameter 'filename'. The description adds minimal semantics by reiterating that detection is 'from the file extension', but this is redundant with the schema's description. Baseline 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('detect the geometry file format') and resources ('from a filename or URL'), and distinguishes it from siblings by focusing on format detection rather than conversion or analysis. It explicitly mentions what it returns ('detected format name and whether it is currently supported'), making the 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 provides explicit guidance on when to use this tool ('Use this to check format support before making a paid analysis call') and includes a 'when-not' scenario by implying it's for pre-checking rather than actual analysis. It also distinguishes from siblings by not being a conversion tool like format_gltf or format_obj, though it doesn't name alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_gltfglTF/GLB AnalysisARead-onlyIdempotentInspect
Extract metadata from a glTF or GLB file.
Returns asset info, scene graph structure, mesh/material/texture
counts, vertex and index totals, feature flags (normals, tangents,
texcoords, colors, joints), primitive modes, and extensions.
Payment via x402 (USDC on Base) or card via MPP (Stripe). See format_auto
for payment flow details. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. Description adds payment requirement (x402/card) and references format_auto for payment flow, providing useful behavioral context beyond 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?
Concise, front-loaded with core functionality. Second paragraph covers payment flow, which is necessary, but privacy link is slightly extraneous. Efficient overall.
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?
Covers metadata extraction, payment, and file source options. Lists return values well, but lacks error handling details and file size limits (though schema covers them). Mostly 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 coverage is 100% with detailed parameter descriptions. Description adds no additional parameter insight beyond schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies verb ('Extract metadata') and resource ('glTF or GLB file'), listing specific metadata types. Distinct from siblings like format_stl, format_obj, and format_auto by file 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?
Implied usage for glTF/GLB analysis, but no explicit when-to-use, when-not-to-use, or alternatives. Lacks context for choosing between this and siblings like format_detect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_lasLAS/LAZ AnalysisARead-onlyIdempotentInspect
Extract metadata from a LAS or LAZ point cloud file.
Returns LAS version, point format, point count, scale factors,
offsets, bounding box, classification counts, feature flags
(RGB, intensity, GPS time, waveform), and VLR information.
Payment via x402 (USDC on Base) or card via MPP (Stripe). See format_auto
for payment flow details. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only, open-world, and idempotent behavior. The description adds context that this tool extracts metadata and requires payment, which is useful beyond annotations. No contradictions.
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 and front-loaded with the tool's purpose. It efficiently covers payment and privacy links without unnecessary fluff, though payment info could be seen as secondary.
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 no output schema, the description adequately lists return values and mentions payment flow. It is complete enough for a read-only metadata extraction tool with well-documented parameters.
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?
Input schema has 100% description coverage, so the schema already explains each parameter. The description does not add significant extra meaning beyond what is in the schema, meeting 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 extracts metadata from LAS or LAZ point cloud files, listing specific data elements returned. The name and description distinguish it from sibling tools like format_auto and 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 on when to use this tool (for LAS/LAZ files) but does not explicitly exclude other scenarios or guide against alternatives. It references format_auto for payment details, which aids in usage flow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_objOBJ AnalysisARead-onlyIdempotentInspect
Extract metadata from an OBJ file.
Returns vertex/normal/texcoord/face counts, triangle/quad/polygon
breakdown, material and group counts, bounding box, surface area,
and triangulation status.
Payment via x402 (USDC on Base) or card via MPP (Stripe). See format_auto
for payment flow details. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the payment requirement and privacy policy, adding value beyond the readOnlyHint, openWorldHint, and idempotentHint annotations. It does not contradict 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 concise with two paragraphs. The first front-loads the purpose, and the second adds payment and policy details. Every sentence is 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?
The description lists the metadata returned and mentions payment, but does not detail the response format or file size limits (though schema covers some). Still fairly complete for a metadata extraction 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 100%, so baseline is 3. The description does not add further parameter semantics beyond what the schema already provides.
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 verb 'Extract metadata' and the resource 'OBJ file', and lists specific metadata returned. This distinguishes it from siblings like format_auto which likely handle multiple 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 mentions payment methods and references format_auto for payment flow, but does not explicitly state when to use this tool over alternatives like format_auto or other format-specific tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_pcdPCD AnalysisARead-onlyIdempotentInspect
Extract metadata from a PCD point cloud file.
Returns point count, field definitions, data format, organization,
viewpoint, feature flags (RGB, intensity, normals, curvature),
bounding box, centroid, and point density estimate.
Payment via x402 (USDC on Base) or card via MPP (Stripe). See format_auto
for payment flow details. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. The description adds value by explaining payment requirements (x402 or card) and providing a privacy policy link. No contradictions. It also lists what the tool returns, which is beyond 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 four sentences focusing on purpose, return, payment, and privacy. No filler. Could be slightly more streamlined but it's efficient. Front-loaded with the main action.
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 no output schema, the description compensates by listing return fields. It covers input options (file_b64, file_url) and payment flow. It doesn't detail error handling or edge cases, but for a simple analysis tool with 100% schema coverage and annotations, it 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%, so baseline 3. The description does not add parameter-specific insights beyond the schema. It mentions return fields but that's not parameter semantics. No additional meaning for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract metadata from a PCD point cloud file' with a specific verb and resource. It lists return fields, distinguishing it from sibling format tools that handle other file types. The mention of format_auto for payment flow further aids differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Implicitly for PCD files, but no alternatives discussed beyond format_auto for payment flow. Lacks exclusions or context for when to choose this over other format tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_plyPLY AnalysisARead-onlyIdempotentInspect
Extract metadata from a PLY file (ASCII or binary).
Returns vertex/face counts, element properties, feature detection
(normals, colors, texcoords, intensity, curvature), bounding box,
centroid, and point cloud identification.
Payment via x402 (USDC on Base) or card via MPP (Stripe). See format_auto
for payment flow details. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly explains that the tool is read-only (extracts metadata) and idempotent (returns consistent output), aligning with annotations. It details the output structure and mentions payment requirements, adding behavioral context beyond the annotations. There is no contradiction with the readOnlyHint, openWorldHint, or idempotentHint 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 concise (three sentences) with front-loaded purpose. Every sentence adds value: the first states the core action, the second lists outputs, and the third covers payment details and a cross-reference. No redundant or irrelevant 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?
The description covers the tool's purpose, outputs, and payment flow, which is sufficient for a metadata extraction tool. It does not explain usage preconditions (e.g., providing file_b64 or file_url) as these are in the schema. However, it could include more context on when to use this tool versus format_auto or error handling, but given the annotations and schema, it is largely 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%, so the input schema already provides detailed explanations for all four parameters. The description does not add new information about parameter semantics; it only provides a high-level overview of the tool's function. According to calibration, with high coverage, the baseline is 3, and the description does not exceed that.
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 extracts metadata from PLY files (ASCII or binary), specifying the exact output (vertex/face counts, element properties, feature detection, bounding box, centroid, point cloud identification). The verb 'Extract' and resource 'PLY file' are specific and unambiguous. While it does not explicitly compare to sibling tools like format_obj or format_stl, the name and focus on PLY inherently distinguish it.
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 guidance on payment methods (x402 and MPP) and directs to format_auto for payment flow details, which implies format_auto handles payment setup. However, it does not explicitly state when to use this tool over other format-specific siblings or the auto-detection tool. The usage context is clear for PLY files but lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
format_stlSTL AnalysisARead-onlyIdempotentInspect
Extract metadata from an STL file (ASCII or binary).
Returns triangle count, bounding box, surface area, volume,
manifold analysis (watertight, open edges, non-manifold edges),
triangle quality metrics, vertex deduplication count, mean edge
length, minimum bounding sphere, and a noise estimate derived
from planar region fitting.
Payment via x402 (USDC on Base) or card via MPP (Stripe). See format_auto
for payment flow details. Privacy policy: https://caliper.fit/privacy
| Name | Required | Description | Default |
|---|---|---|---|
| payment | No | Payment proof as a JSON string. Set this when retrying after a payment_required response. For x402: must contain 'transaction' (on-chain tx hash), 'network', and 'priceToken' from the payment_required response. For MPP: must contain 'challenge' and 'payload' from the org.paymentauth/credential flow. Default: null (omit on first call; set only when retrying with payment). | |
| file_b64 | No | Base64-encoded file content. Max 200KB decoded. Use file_url for larger files to avoid consuming model context window budget. Default: null (omit if providing file_url instead). | |
| file_url | No | HTTP/HTTPS URL of the geometry file to analyze. Preferred for large files (over 200KB). The file format is detected from the URL path extension, so the filename parameter is not needed when using file_url. Max 100MB. Default: null (omit if providing file_b64 instead). | |
| filename | No | Original filename with extension (e.g. 'model.stl'). Required for format detection when using file_b64. Not needed when using file_url (format is detected from the URL path). Default: null. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it as read-only and idempotent. The description adds extensive behavioral details: supports ASCII/binary, returns manifold analysis, quality metrics, and noise estimate. No contradictions.
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 thorough but not overly verbose. It front-loads the purpose, lists return values, then covers payment. Every sentence adds value, though it could be slightly more concise.
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 must explain return values—which it does in detail. It also covers payment prerequisites and file format handling, making it fully self-contained for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description does not add additional meaning beyond what's in the parameter descriptions, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts metadata from an STL file, lists specific metrics (triangle count, bounding box, etc.), and is distinct from sibling format-specific tools like format_obj or format_ply.
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 indicates when to use it (for STL files) and provides guidance on payment flow by referencing format_auto. However, it does not explicitly compare with other format tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!