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 declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true. The description adds valuable context beyond annotations: payment requirements for files over 150KB, privacy policy link, and specific retry behavior with payment argument. It doesn't contradict annotations (read-only analysis aligns with readOnlyHint). However, it doesn't mention rate limits or authentication needs.
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 appropriately sized. It front-loads the core purpose, then details supported formats, input options, payment model, and privacy policy. Most sentences earn their place, though the payment retry instructions could be slightly more concise. The privacy policy URL might be better as a separate annotation.
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 (payment model, multiple input methods) and rich schema/annotations, the description is mostly complete. It explains the tool's scope, limitations, and usage patterns. However, without an output schema, it doesn't detail the return structure beyond listing metadata categories (bounding boxes, triangle counts, etc.). A brief example of the output format would help.
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 4 parameters thoroughly. The description adds some semantic context: it explains the trade-off between file_url and file_b64 (avoiding context window budget), clarifies when filename is required, and mentions the 200KB/100MB size limits. However, it doesn't add significant meaning beyond what's in the schema 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 description clearly states the specific action ('Auto-detect geometry file format and extract metadata statistics') and resource ('3D geometry file'), distinguishing it from sibling tools like format_detect (likely detection only) or format_* tools (likely format-specific). The explicit exclusion of mesh repair, format conversion, or boolean operations further clarifies its unique analytical 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?
The description provides explicit guidance on when to use this tool vs. alternatives: it's for analysis only (not repair/conversion/boolean operations). It also specifies when to use file_url vs. file_b64 based on file size, and includes payment requirements for large files with retry instructions. The sibling tools (format_*) suggest this is the general auto-detect tool vs. format-specific ones.
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 adds valuable behavioral context beyond annotations: it discloses payment requirements ('Payment is required'), partial success handling ('Partial success: if some files fail...'), and privacy policy links. While annotations cover read-only, open-world, and idempotent hints, the description enriches this with operational details like payment flow and error handling, without contradicting 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 appropriately sized and front-loaded, starting with the core purpose and key features. Most sentences earn their place by explaining payment flow, partial success, and privacy, though the payment details could be slightly more streamlined. Overall, it's efficient with minimal waste.
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 (payment flow, batch processing) and rich annotations, the description is largely complete. It covers purpose, usage, payment requirements, and behavioral traits. Without an output schema, it doesn't explain return values, but this is acceptable as the annotations and context provide sufficient guidance for an agent to use the tool effectively.
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 documents both parameters thoroughly. The description adds minimal parameter semantics, such as implying 'files' supports up to 10 items and 'payment' is for retries, but doesn't provide significant additional meaning beyond what's in the schema. This 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 clearly states the tool's purpose with specific verbs ('analyze multiple geometry files') and resources ('geometry files'), distinguishing it from sibling tools like format_auto or format_detect by emphasizing batch processing capabilities. It explicitly mentions 'batch request' and 'multiple files', making the scope 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 vs. alternatives: it specifies 'batch request' for analyzing multiple files at once, contrasting with single-file tools in the sibling list. It also details when to retry with payment ('if no payment is provided... retry with the payment argument'), offering clear usage scenarios and 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 declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, indicating safe, non-destructive, and repeatable operations. The description adds valuable behavioral context beyond annotations by disclosing payment requirements ('Payment required via x402'), privacy policy links, and retry logic for payment, which are critical for correct tool invocation. No contradictions with annotations are present.
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 sized and front-loaded, starting with the core purpose and then listing extracted metadata. The payment and privacy details are necessary but placed later, making it efficient. However, the inclusion of a privacy policy URL and payment flow reference, while useful, slightly reduces conciseness compared to a more streamlined version.
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 (payment requirements, file handling options) and rich annotations, the description is mostly complete. It covers key behavioral aspects like payment and privacy, and the lack of an output schema is mitigated by detailing what metadata is returned. However, it could be more explicit about error handling or limitations beyond file size, but overall it provides sufficient context for effective use.
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%, meaning the input schema already fully documents all four parameters (payment, file_b64, file_url, filename) with detailed descriptions. The description does not add any additional meaning or clarification about parameters beyond what the schema provides, so it meets the baseline of 3 without compensating further.
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 specific action ('Extract metadata') and resource ('from a glTF or GLB file'), and distinguishes itself from siblings by focusing on glTF/GLB analysis rather than other formats like OBJ, STL, or LAS. The detailed list of extracted information (asset info, scene graph structure, mesh/material/texture counts, etc.) further clarifies the scope.
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 usage by mentioning payment requirements and referring to 'format_auto for payment flow details,' which helps guide the agent on prerequisites. However, it does not explicitly state when to use this tool versus alternatives like format_detect or other format-specific tools, nor does it provide exclusions or comparisons with siblings.
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?
The description adds valuable behavioral context beyond annotations: it discloses payment requirements, references a sibling tool for payment flow, and provides a privacy policy link. Annotations already cover read-only, open-world, and idempotent hints, so the description appropriately supplements with operational details 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 well-structured and front-loaded with the core functionality, followed by payment and privacy details. Every sentence adds value, but it could be slightly more concise by integrating the payment note more seamlessly. Overall, it's efficient with minimal waste.
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 (file processing with payment) and lack of output schema, the description does a good job explaining what metadata is returned and operational constraints. However, it could benefit from more detail on error handling or response structure to fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema fully documents all 4 parameters. The description does not add any parameter-specific information beyond what the schema provides, such as explaining interactions between file_b64 and file_url. This meets the baseline of 3 since the schema handles 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 specific action ('Extract metadata') and target resource ('from a LAS or LAZ point cloud file'), distinguishing it from sibling tools like format_auto or format_stl which handle different file formats. It provides a comprehensive list of what metadata is returned, making the purpose explicit and differentiated.
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 this tool ('Payment required via x402') and provides an alternative ('See format_auto for payment flow details'), giving clear guidance on prerequisites and related tools. It also mentions a privacy policy link, adding context for usage considerations.
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 adds valuable behavioral context beyond annotations: it discloses payment requirements, privacy policy, and specific return data structure (vertex/normal counts, bounding box, etc.). While annotations cover read-only/idempotent/open-world aspects, the description provides operational details about payment flow and output format that annotations don't capture.
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: first sentence states core purpose, second enumerates return values, third covers payment requirements with reference, fourth provides privacy policy. Every sentence adds value, though the payment details 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?
For a tool with rich annotations (readOnlyHint, openWorldHint, idempotentHint) and comprehensive schema coverage, the description provides good contextual completeness by detailing the specific metadata returned and payment requirements. The main gap is the lack of output schema, but the description compensates by enumerating return values. Slight deduction for not explicitly mentioning file size limits that appear in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents all 4 parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, so it meets the baseline expectation without providing additional semantic context about 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 the tool's purpose with specific verbs ('Extract metadata') and resource ('from an OBJ file'), then enumerates the exact metadata returned. It distinguishes from siblings by focusing on OBJ files specifically, unlike format_auto (general), format_gltf (GLTF), etc.
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 about payment requirements and references format_auto for payment flow details, giving practical usage guidance. However, it doesn't explicitly state when to use this tool versus alternatives like format_detect or format_auto for similar analysis tasks.
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?
The description adds valuable behavioral context beyond annotations: it discloses payment requirements ('Payment required via x402'), references a sibling tool for payment flow, and provides a privacy policy link. Annotations already cover read-only, open-world, and idempotent hints, so the description appropriately supplements with operational details 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 front-loaded with the core purpose, followed by a detailed list of returned metadata, and concludes with payment and privacy details. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.
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 (metadata extraction with payment requirements) and lack of an output schema, the description does well by listing the specific metadata returned. However, it could improve by briefly mentioning error handling or response format, though the payment retry logic is covered in the schema. Annotations provide safety hints, making this reasonably 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?
With 100% schema description coverage, the input schema fully documents all 4 parameters. The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining how 'file_b64' or 'file_url' relate to PCD analysis. This meets the baseline of 3 when schema coverage is high.
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 specific action ('Extract metadata') and resource ('from a PCD point cloud file'), distinguishing it from sibling tools like format_auto or format_las that handle different file formats. It provides a comprehensive list of what metadata is extracted, making the purpose explicit and differentiated.
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 this tool ('Extract metadata from a PCD point cloud file') and provides clear alternatives for payment flow ('See format_auto for payment flow details'). It also mentions privacy policy details, offering contextual guidance for usage.
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 adds valuable behavioral context beyond annotations: it discloses payment requirements, privacy policy, and specific return details (vertex/face counts, bounding box, etc.). Annotations already indicate it's read-only, open-world, and idempotent, so the description appropriately supplements 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 well-structured and front-loaded with the core purpose, followed by return details and operational notes (payment, privacy). Every sentence adds value without redundancy, making it efficient and easy to parse.
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 (file analysis with payment), the description is mostly complete: it covers purpose, return values, payment requirements, and references. However, without an output schema, it could benefit from more detail on return format or error handling, but it still provides sufficient context for effective use.
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 fully documents all parameters. The description does not add any parameter-specific details beyond what the schema provides, such as explaining the relationship between file_b64 and file_url or payment usage. This meets the baseline score of 3 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 clearly states the tool's purpose with specific verbs ('Extract metadata') and resources ('from a PLY file'), and distinguishes it from siblings by specifying the file format (PLY) and the type of analysis (metadata extraction). It explicitly mentions the format_auto sibling for payment flow details.
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 this tool (for PLY file analysis) and references an alternative (format_auto for payment flow). However, it does not explicitly state when not to use it or compare it to other format_* siblings for different file types, which would be needed for a score of 5.
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 indicate readOnlyHint=true, openWorldHint=true, and idempotentHint=true, covering safety and idempotency. The description adds valuable behavioral context beyond annotations: it discloses payment requirements, privacy policy link, and details on file size limits (e.g., 'Max 200KB decoded', 'Max 100MB'), which are not captured in annotations, enhancing transparency for the agent.
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, starting with the core purpose and followed by metadata details and usage notes. It is concise with no wasted sentences, though the inclusion of the privacy policy URL and payment details adds slight length that is justified by their importance. Overall, it is efficient and clear.
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 (metadata extraction with payment requirements) and rich annotations, the description is largely complete. It covers key behavioral aspects like payment and file limits, and while there is no output schema, it lists return values (e.g., triangle count, bounding box). However, it could improve by briefly mentioning error handling or response formats, but the annotations and parameter details suffice for most contexts.
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 fully documents all parameters (payment, file_b64, file_url, filename). The description does not add any parameter-specific semantics beyond what the schema provides, such as explaining trade-offs between file_b64 and file_url. Thus, it meets the baseline of 3 without compensating for gaps, as there are none.
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 specific action ('Extract metadata from an STL file') and resource ('STL file'), distinguishing it from siblings like format_gltf or format_obj by specifying the file format. It provides a comprehensive list of what metadata is extracted, making the purpose explicit and detailed.
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 includes explicit usage context by mentioning 'Payment required via x402' and referring to 'format_auto for payment flow details', which guides when to use this tool in terms of prerequisites. However, it does not specify when to choose this tool over other format_* siblings (e.g., format_gltf for GLTF files), leaving some ambiguity in sibling differentiation.
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!