Verify photos are genuine camera captures, not AI-generated: C2PA checks and RAW+JPEG forensics.
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.
Average 4.3/5 across 11 of 11 tools scored. Lowest: 3.6/5.
Each tool targets a distinct action and resource: uploads, account usage, listings, verifications, sharing, and the two verification methods are clearly differentiated by input type (single image vs RAW+JPEG). The get_verification and get_verification_share pair is unambiguous due to specific descriptions.
All tool names use lowercase snake_case with a verb_noun pattern (create, get, list, share, unshare, verify), making the set predictable and consistent. Even longer names like verify_content_credentials follow the same verb-first convention.
With 11 tools, the server covers uploads, verification, results retrieval, sharing, account usage, and marketplace listing retrieval without redundancy. This is a well-scoped count for the feature set.
The verification lifecycle is well covered: create (two methods), upload, get, list, share/unshare, and usage check. The only notable gap is that marketplace listing management is read-only (no create/update/delete), but that's tangential to the core verification purpose.
create_verification_uploadAInspectGet pre-signed S3 PUT URLs to upload a large RAW + JPEG directly (avoids inlining bytes and bypasses request-size limits). PUT each file to its upload_url, then call verify_photo with the returned object_key values as raw_object_key / image_object_key.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It transparently discloses that the tool does not upload files directly but returns pre-signed URLs, and it explains the required follow-up call to verify_photo. It also explains why this approach exists (avoiding inlining bytes). This is substantial but could have mentioned expiration or permissions, so not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the primary purpose. The second sentence adds essential workflow instructions without any padding.
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 fully explains the tool's role in the upload process, including the pre-signed URLs, the PUT action, and how to pass the resulting object_key values to verify_photo. An output schema exists, so detailed return values are not needed here. The workflow is complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (empty schema), so the baseline of 4 applies. The description appropriately does not discuss parameters, and there is nothing to add beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('pre-signed S3 PUT URLs') for uploading RAW + JPEG files. It distinguishes itself from siblings by explaining the upload workflow and how it connects to verify_photo.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use when uploading large RAW + JPEG files to avoid request-size limits and inlining bytes. It also provides step-by-step instructions for using the returned URLs. However, it does not explicitly mention when not to use it or name alternative tools, though the rationale is implicitly strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_account_usageAInspectGet the authenticated account's monthly verification quota: plan, used, limit, and remaining. Call this before verify_photo to check the free-tier allowance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions 'authenticated account' and describes a read-only quota check, which implies no side effects. However, it doesn't explicitly state that the operation is non-destructive or doesn't consume quota, but the verb 'Get' and the context is sufficient for a simple reader.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose, and every word earns its place. It includes the key data fields and the usage context without any redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description doesn't need to explain return values. It covers the tool's purpose, the data it returns, and when to call it, making it complete for a simple read-only tool with no 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?
The tool has zero parameters, so the schema provides complete coverage. With 0 params, the baseline is 4 per instructions, and the description adds no unnecessary parameter information, making it 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 gets the authenticated account's monthly verification quota, listing specific fields (plan, used, limit, remaining). It uses a specific verb 'Get' and resource, differentiating it from sibling verification tools that perform actions on individual verification items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to call this tool before verify_photo to check the free-tier allowance, providing a concrete use case and naming an alternative tool. This gives clear when-to-use guidance, even though it doesn't list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listingAInspectFetch a marketplace listing by id: title, description, per-license pricing, terms, and sales totals. There is no public directory — you must know the listing UUID.
| Name | Required | Description | Default |
|---|---|---|---|
| listing_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the read-only nature via 'Fetch' and specifies the exact fields returned. It also adds the operational constraint about UUID requirements. However, it doesn't describe error handling, authentication requirements, or any side effects, though these are less critical for a simple get operation. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences. The first sentence front-loads the purpose and data fields; the second adds a crucial constraint. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter and an output schema, the description covers the essential aspects: what it fetches, the data it returns, and the requirement of a known UUID. It doesn't need to detail the output schema since that exists separately. Minor omission is not specifying access scope, but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does by explaining that listing_id is a UUID and must be known, giving the parameter clear meaning beyond the bare string type. The description also implies the parameter is required through context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Fetch a marketplace listing by id' and enumerates the returned data (title, description, pricing, terms, sales totals). This specific verb+resource definition distinguishes it from sibling tools like list_my_listings, which lists multiple listings, and other verification tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states a key usage constraint: 'There is no public directory — you must know the listing UUID.' This gives clear context for when to use the tool (when you have a UUID) but does not explicitly name alternatives or exclusions, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_verificationAInspectRetrieve a verification by id: processing status and per-algorithm authenticity results. Completed single-image (image_only) verifications also include a verdict and a structured evidence_report with per-check findings and coverage. Works for both API-key callers (scoped to their account) and keyless anonymous callers (any anonymous verification, which are public by link).
| Name | Required | Description | Default |
|---|---|---|---|
| verification_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses what data is returned (processing status, per-algorithm results, verdict, evidence_report for completed single-image cases) and explains access control (API-key scoping vs anonymous public-by-link). It does not explicitly state that the operation is read-only, but the verb 'Retrieve' implies this, and the absence of side-effect warnings is acceptable for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each adding essential information: the core action, the return details for completed single-image verifications, and the access model. It is front-loaded with the primary verb, and no sentence is wasted.
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 simplicity (one parameter, no annotations, but an output schema exists), the description covers all necessary aspects: what it does, what it returns, the special case for image_only verifications, and authorization for both API-key and anonymous callers. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It does so by explicitly saying 'Retrieve a verification by id', directly tying the single required parameter verification_id to its purpose. The parameter name itself is self-explanatory, so even without detailed schema documentation, the agent can correctly use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Retrieve a verification by id', a specific verb+resource pair that clearly distinguishes this from sibling listing tools like list_verifications. It further specifies the exact data returned: processing status, per-algorithm authenticity results, and for completed single-image verifications, a verdict and evidence_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use this tool: to retrieve a single verification by its ID. It also provides important usage constraints by stating it works for both API-key callers (scoped to their account) and anonymous callers (accessing public-by-link verifications). However, it does not explicitly name alternatives or exclusions, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_my_listingsAInspectList the marketplace listings owned by your account (with pricing and sales totals).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the account scope and the inclusion of pricing and sales totals in results. The verb 'list' clearly signals a read-only operation, though it does not explicitly mention pagination or rate limits. This is reasonable behavioral context for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the operation and scope directly. No extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low-complexity with an output schema, so the description doesn't need to explain return values. It covers the essential purpose and scope. It lacks explicit pagination guidance, but the schema provides defaults, making it sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention limit or offset. The agent gets no guidance about pagination, ordering, or how these parameters affect results beyond their default values in the schema. The description fails to compensate for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List the marketplace listings owned by your account' uses a specific verb (list) and resource (marketplace listings) with a clear scope (owned by your account), distinguishing it from siblings like get_listing (single listing) and list_verifications (different resource). It also adds return value context (with pricing and sales totals).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the user's own listings, but it does not explicitly state when to use this over alternatives like get_listing or list_verifications, nor does it mention exclusions. The scope is clear, but the guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_verificationsAInspectList the account's verifications, most recent first. Optional filters: status (pending|queued|in_progress|completed|failed) and result (true=authentic, false=not).
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | ||
| offset | No | ||
| result | No | ||
| status | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the ordering ('most recent first'), filter semantics, and result meaning ('true=authentic, false=not'). However, it does not mention pagination behavior (size/offset) or any rate limits/auth requirements, which would be valuable for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence: 'List the account's verifications, most recent first.' It then efficiently lists the optional filters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with all-optional parameters and an output schema (which presumably describes return values). The description covers the core behavior but does not explain pagination semantics (size/offset) or elaborate on potential edge cases. It is adequate but could be more 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 0%, so the description must compensate. It explains the 'status' and 'result' parameters, including the enumerated status values. However, 'size' and 'offset' are not described; while their names are self-explanatory, the description does not clarify their role in pagination, leaving a gap for half 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 'List the account's verifications' with a specific verb and resource, and adds ordering ('most recent first') which distinguishes it from siblings like get_verification (singular) and list_my_listings (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this tool to list verifications with optional filters. However, it does not explicitly mention alternatives (e.g., get_verification for a single verification) or when this tool would be preferred over sibling tools, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_content_credentialsAInspectVerify a single image's authenticity — use this when you only have the image and no RAW camera file. Checks its embedded Content Credentials (C2PA) for capture provenance and AI-generation flags, and runs advisory forensic screens (error-level analysis, double-JPEG artifacts, EXIF timestamp consistency, editing-software traces, screen recapture). Free: it does not consume your verification quota. Provide the image inline as image_base64, or — for large files — call create_verification_upload and pass the returned image_object_key. Returns a verification id; poll get_verification, which on completion includes a structured evidence_report (verdict, per-check findings, coverage). Works without an API key on the keyless anonymous tier (rate-limited; returns an anonymous_user_id to reuse). For the strongest forensic check, use verify_photo with a RAW + JPEG pair instead.
| Name | Required | Description | Default |
|---|---|---|---|
| image_base64 | No | ||
| image_filename | No | upload.jpg | |
| image_object_key | No | ||
| anonymous_user_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: it runs advisory forensic screens, does not consume verification quota, works anonymously with rate limits, returns an anonymous_user_id for reuse, and requires polling get_verification for results. This goes beyond a simple mutating/read label and sets accurate expectations.
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 dense but every sentence adds value; it front-loads the primary purpose and then layers in transfer/storage, authentication, and alternatives. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has multiple parameters, an output schema, and sibling alternatives, the description covers the full usage flow: input methods, authentication, result polling, and the recommended alternative. It is self-contained for effective agent 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 coverage is 0%, but the description directly explains how to use image_base64 and image_object_key, and mentions anonymous_user_id as a return-to-reuse value. It also implies image_filename is optional. This is strong compensation for the missing 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 opens with a specific action, 'Verify a single image's authenticity', and clarifies the exact resource and condition ('when you only have the image and no RAW camera file'). It explicitly contrasts with sibling verify_photo, making the tool's niche unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-to-use ('use this when you only have the image and no RAW camera file') and names the alternative for stronger checks ('use verify_photo with a RAW + JPEG pair instead'). It also guides large-file handling via create_verification_upload, showing clear decision logic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_photoAInspectVerify a photo's authenticity from a RAW camera file and its JPEG export. Provide the files either inline as raw_base64 + image_base64 (small files), or — for large files — call create_verification_upload first and pass the returned raw_object_key + image_object_key. Returns a verification id; poll get_verification for the result. With an API key this counts against your monthly quota (free tier: 5/month). Without a key it runs on the keyless anonymous tier (rate-limited; returns an anonymous_user_id to reuse; anonymous verifications can't be listed or shared until you register).
| Name | Required | Description | Default |
|---|---|---|---|
| raw_base64 | No | ||
| image_base64 | No | ||
| raw_filename | No | upload.raw | |
| image_filename | No | upload.jpg | |
| raw_object_key | No | ||
| image_object_key | No | ||
| anonymous_user_id | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It explicitly mentions quota accounting, the keyless anonymous tier with rate limits, and the fact that anonymous verifications can't be listed or shared until registration, plus the asynchronous return pattern. These are meaningful behavioral traits.
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 about four sentences, front-loaded with the core purpose, then covering all essential usage details. Every sentence adds necessary information without redundancy, making it efficient.
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 moderate complexity (two upload modes, async result, quota tiers), the description covers the critical workflow steps and limitations. The presence of an output schema reduces the need to explain return values, and the description remains 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?
The description explains the semantics of the primary parameters (raw_base64, image_base64, raw_object_key, image_object_key, anonymous_user_id) by mapping them to two input modes. However, it omits raw_filename and image_filename entirely, and does not specify size limits or format constraints, leaving gaps given the 0% 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 function: verifying photo authenticity from a RAW file and its JPEG export. It distinguishes itself from siblings like create_verification_upload and get_verification by describing the full verification workflow, making it 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 explains when to use inline base64 vs uploading via create_verification_upload, and instructs to poll get_verification. It also contrasts keyed and anonymous usage patterns, giving clear context for choosing the appropriate path, though it doesn't explicitly compare against all sibling tools.
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.
No comments yet. Be the first to start the discussion!