HiveAttest
Server Details
Pre-action attestation perimeter for AI agents — 8 primitives, signed C18 receipt per call.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- srotzin/hive-mcp-attest
- GitHub Stars
- 0
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 3.4/5 across 18 of 18 tools scored. Lowest: 2.8/5.
Each tool belongs to a distinct subdomain (absence, cargo, custody, gate, inspect, meta, passport, SMSH, warranty) with clearly differentiated actions (e.g., build/prove/verify). No two tools have overlapping purposes; an agent can easily select the correct tool based on the action needed.
All tools follow a uniform `attest_<domain>_<action>` pattern (e.g., attest_absence_build, attest_cargo_register). The naming is predictable and consistent across all 18 tools, making it easy for agents to infer functionality from the name.
With 18 tools covering multiple domains (absence proofs, cargo registry, custody chains, gate enforcement, passport, warranty, etc.), the server is well-scoped. Each tool serves a specific purpose without redundancy, and the count feels appropriate for the complexity of attestation workflows.
The tool set provides essential CRUD-like operations for each subdomain: absence (build/prove/verify), cargo (register/snapshot/validate), custody (append/proof/verify), passport (issue/verify), and warranty (issue/get/breach). Additionally, gate evaluation, secondary inspection, and metadata introspection are included, leaving no obvious gaps for the stated purpose.
Available Tools
18 toolsattest_absence_buildBInspect
Build a sorted Merkle tree for an audit window — enables cryptographic non-membership proofs (C13 — prov-absence). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| events | Yes | Observed events to commit to the sorted Merkle tree | |
| window_id | Yes | Audit window identifier |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Adds context about reference-grade implementation and normative wire format, but does not describe side effects, permissions, or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with main action. Efficient but contains jargon ('C13', 'prov-absence') that may hinder clarity.
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?
No output schema and description does not explain return value. For a build tool, output info is important. Also lacks prerequisites or error conditions.
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 baseline 3. Description adds no extra meaning beyond the schema's parameter 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?
Clearly states verb 'build', resource 'sorted Merkle tree', and purpose 'enables cryptographic non-membership proofs'. Distinguishes from siblings like attest_absence_prove and attest_absence_verify.
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 guidance on when to use this tool vs alternatives. Mentions 'Wire format normative; production-grade is Layer B' but does not clarify when building is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_absence_proveAInspect
Prove that a query event is NOT a member of a previously-built audit window (C13). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Event to prove absent | |
| window_id | Yes | Audit window identifier (must have been built) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral info. Mentions 'reference-grade' and 'wire format normative' but fails to disclose safety (read-only implied but not stated), permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adding value: purpose, implementation quality, production context. Could merge second two sentences, but overall efficient and 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?
Covers core purpose and prerequisite but lacks return format or error handling description. No output schema, so description should compensate moderately; it does not.
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 describes both parameters fully (100% coverage), so description adds little: only context of 'query event' and 'previously-built'. No added format or constraints beyond 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?
Description clearly states verb 'Prove' and resource 'non-membership in audit window'. Distinguishes from siblings by focusing on absence proof, contrasting with build or verify.
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?
Implies prerequisite of a previously-built window, but no explicit guidance on when to use this tool versus alternatives like attest_absence_verify. No when-not or direct sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_absence_verifyAInspect
Verify a non-membership proof against an expected Merkle root (C13). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| proof | Yes | Non-membership proof from attest_absence_prove | |
| root_hex | Yes | Expected Merkle root (hex) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It adds context about the tool's quality tier (reference vs production) but does not disclose side effects, authentication needs, rate limits, or what happens if verification fails. The tool is likely read-only, but the description does not confirm this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each adding value: clear purpose, quality guidance, and normativity. No wasted words, and it is front-loaded with the core 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?
The description lacks important information: it does not specify the return value (likely boolean), error handling, or what happens if verification fails. With no output schema and no annotations, the agent is left to infer behavior.
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% (both parameters are documented in the schema). The description adds that the proof comes from 'attest_absence_prove' and the root is hex, but this is already in the schema. No new parameter-specific meaning 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: 'Verify a non-membership proof against an expected Merkle root'. It includes a specific verb ('verify'), the resource ('non-membership proof', 'Merkle root'), and distinguishes it from sibling tools like 'attest_absence_prove' and 'attest_absence_build'.
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 implicit usage context by specifying 'Reference-grade implementation' and 'Wire format normative; production-grade is Layer B', indicating this tool is for testing/validation rather than production. However, it does not explicitly state when to use or avoid this tool compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_cargo_registerBInspect
Register a versioned cargo type in the HiveAttest registry (C17 — hive-cargo-taxonomy). Pins a definition hash for version-anchoring. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Unique cargo type ID, e.g. "pii" | |
| name | Yes | Human-readable cargo type name | |
| schema | Yes | JSON Schema defining the payload shape | |
| version | Yes | Semver version string, e.g. "1.0.0" | |
| supersedes | No | Optional {id, version} of superseded type | |
| sensitivity | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden but fails to disclose key behaviors such as idempotency, side effects, or error states. Mentioning 'pins a definition hash' is vague and does not clarify the tool's 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 brief (three sentences) but contains jargon 'Reference-grade implementation' and 'Layer B' that may confuse rather than clarify. It could be more concise by removing non-essential phrases.
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 (6 parameters, nested objects) and lack of output schema or annotations, the description is incomplete. It fails to explain return values, error conditions, or how this tool relates to other cargo tools like attest_cargo_validate.
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 83% with descriptions for all parameters. The description adds no new parameter-level meaning beyond the schema. It does not explain concepts like 'supersedes' or the expected format of 'schema', so it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Register' and the resource 'versioned cargo type', and includes context about the HiveAttest registry and version anchoring. It distinguishes from siblings like attest_cargo_snapshot by focusing on registration.
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 does not provide guidance on when to use this tool versus alternatives, nor does it mention preconditions or exclusions. Phrases like 'Reference-grade implementation' and 'Layer B' hint at implementation quality but not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_cargo_snapshotBInspect
Get a registry snapshot with Merkle root for version pinning (C17). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'Reference-grade implementation' and 'production-grade is Layer B', hinting at quality tiers, but does not address side effects, auth needs, or safety profile. For a get operation, it is likely read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) and front-loaded with the main purpose. However, the second sentence contains jargon ('Reference-grade', 'normative', 'Layer B') that could be clearer, reducing efficiency slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-param tool with no output schema, the description minimally covers what the tool does but lacks details on the returned snapshot structure or constraints. It implies usage for version pinning, but does not fully specify the output format or any prerequisites.
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, and schema coverage is 100%, so no parameter info is needed. The description adds no parameter semantics, but the dimension baseline for zero params is 4, which is appropriate as there is nothing to miss.
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 'Get a registry snapshot with Merkle root for version pinning', providing a specific verb and resource. It distinguishes from siblings like attest_cargo_register and attest_cargo_validate by focusing on snapshot retrieval, though the mention of 'C17' may be obscure.
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 version pinning (C17) but does not explicitly state when to use this tool versus alternatives. No when-not or exclusion guidance is provided, leaving the decision partially to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_cargo_validateCInspect
Validate a payload against a registered cargo type schema (C17). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes | Payload to validate against the schema | |
| version | Yes | Cargo type version | |
| cargo_type_id | Yes | Registered cargo type ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions 'Reference-grade' and 'production-grade is Layer B', but does not explain error behavior, side effects, or authorization requirements. For a validation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. But the second sentence (Wire format normative; production-grade is Layer B) is cryptic and could be clearer for an AI agent.
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 and no annotations, the description does not specify what the tool returns on success/failure, nor does it explain the implications of 'normative' vs 'production-grade'. Incomplete for a required 3-parameter validation 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%. Description does not add additional meaning beyond the basic parameter descriptions already in the schema, 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?
Clearly states the tool validates a payload against a cargo type schema (C17). However, it does not differentiate from sibling tools like attest_cargo_register or attest_cargo_snapshot, which are related but distinct operations.
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 guidance on when to use this tool versus alternatives. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_custody_appendAInspect
Append a node to a custody chain (C16 — hive-custody). Taint propagates: once tainted, always tainted. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | No | Transform payload (will be hashed) | |
| chain_id | Yes | Chain identifier (create new by using a fresh ID) | |
| agent_did | Yes | DID of the agent performing the transform | |
| taint_status | No | Declared taint status | clean |
| transform_id | Yes | Transform identifier for this step |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses one key behavioral trait: 'Taint propagates: once tainted, always tainted'. This adds transparency about stateful effects. However, with no annotations provided, the description carries the full burden and omits other behaviors (e.g., whether the operation is idempotent, reversible, or its impact on existing chains). The remark on implementation levels is somewhat ambiguous.
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 concise sentences, front-loading the main action. Every sentence adds value: action, key behavioral property, and implementation note. There is 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 no output schema and 5 parameters, the description covers core functionality and taint behavior but leaves gaps: return value is unspecified, error conditions are not mentioned, and operational constraints (e.g., whether chain_id must be new) are only implied via the schema description. The implementation remarks may confuse rather than clarify.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds marginal extra meaning by explaining taint propagation in relation to the 'taint_status' parameter. However, it does not elaborate further on other parameters like 'payload' or 'chain_id' beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Append a node to a custody chain'. It identifies the verb (append) and resource (node to custody chain), and references a specific protocol (C16 — hive-custody). The tool name aligns perfectly, and the description distinguishes it from siblings like attest_custody_proof and attest_custody_verify.
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 no guidance on when to use this tool versus alternative attest_* tools. It does not mention preconditions (e.g., chain must exist) or scenarios where other tools (like attest_custody_proof) would be appropriate. The reference to 'Reference-grade implementation' and 'Layer B' hints at maturity but does not clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_custody_proofBInspect
Retrieve a Merkle inclusion proof for a specific node in a custody chain (C16). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| index | Yes | 0-based node index | |
| chain_id | Yes | Chain identifier |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks details on side effects, authentication requirements, or behavioral traits. The terms 'wire format normative' and 'Layer B' are cryptic.
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 sentences. The first sentence front-loads the main purpose. The second adds technical detail, though it could be more accessible.
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?
No output schema is provided, and the description does not explain the return format of the Merkle proof. It also fails to mention prerequisites, such as valid chain_id or index bounds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has clear descriptions for both parameters (chain_id and index). The description adds contextual information about Merkle inclusion and custody chain, but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve a Merkle inclusion proof') and the target resource ('specific node in a custody chain (C16)'). It distinguishes from sibling tools like attest_custody_append and attest_custody_verify.
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 guidance on when to use this tool versus alternatives. The mention of 'Reference-grade implementation' and 'production-grade is Layer B' is vague and does not provide concrete usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_custody_verifyAInspect
Verify a custody chain: hash linkage, Ed25519 signatures, and taint propagation (C16). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| nodes | Yes | Ordered array of custody chain node objects (from attest_custody_append responses) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must stand alone. 'Verify' implies read-only operation, and the description adds context about reference-grade implementation and wire format norms, but does not explicitly state that it has no side effects or require specific permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each adds unique information: action+scope, quality level, format maturity. 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?
Lacks specification of return value (e.g., boolean, detailed report) and does not mention error conditions or prerequisites. As a verification tool without output schema, this information is critical for correct 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?
Only one parameter 'nodes' which is fully described in the schema. The description does not add additional meaning beyond the schema's description, meeting the baseline for 100% 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?
Description clearly states the tool verifies a custody chain, listing specific verification elements (hash linkage, Ed25519 signatures, taint propagation). This distinguishes it from siblings like attest_custody_append (creates) and attest_custody_proof (generates proofs).
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?
Implies usage after building a custody chain (via attest_custody_append) and mentions 'reference-grade' vs 'production-grade', but does not explicitly state when to use or avoid this tool compared to alternatives like attest_custody_proof.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_gate_evaluateAInspect
THE HEADLINE TOOL. Evaluate whether an agent may proceed through the HiveAttest gate (C19 — hive-gate-enforcer). Verifies passport signature + expiry, cargo registry membership, and warranty status. Every response (allow OR deny) includes a signed C18-format receipt of the gate decision. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| context | No | Additional gate evaluation context | |
| custody_root | No | Expected custody chain Merkle root (optional) | |
| warranty_ids | No | Active warranty IDs to verify | |
| cargo_manifest | No | C17 cargo manifest (optional) | |
| passport_manifest | Yes | C15 passport manifest from attest_passport_issue |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool verifies several conditions and returns a signed receipt, but does not mention safety traits (e.g., read-only vs. destructive), authorization needs, or error behavior. The 'Reference-grade implementation' note adds some context but insufficient detail.
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 cohesive paragraph that front-loads the purpose. It could drop the 'THE HEADLINE TOOL' and 'Reference-grade implementation' phrases without losing essential information, but it remains reasonably concise and structured.
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 (5 parameters, nested objects, no output schema), the description adequately outlines the evaluation checks and mentions the signed receipt format. However, it omits error handling details and does not specify the return structure beyond the receipt, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 5 parameters have descriptions in the input schema), so the baseline is 3. The description adds minimal value by linking passport_manifest to 'attest_passport_issue', but does not otherwise enhance parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool evaluates whether an agent may proceed through the HiveAttest gate, listing specific checks: passport signature and expiry, cargo registry membership, and warranty status. This specific verb+resource combination clearly distinguishes it from sibling attest tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description calls it 'THE HEADLINE TOOL' and implies it should be used for gate evaluation, but lacks explicit guidance on when not to use it or comparisons to alternative tools among the siblings. Usage context is implied but not fully directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_inspect_sampleBInspect
Probabilistic secondary inspection of a record batch (C20 — hive-secondary-inspection). Returns a signed inspection record. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | No | Optional RNG seed for reproducibility | |
| records | Yes | Records to probabilistically inspect | |
| sample_id | Yes | Identifier for the sample batch | |
| sample_rate | No | Fraction to inspect (0.0–1.0) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations (which are absent) by stating it returns a signed record and is a reference-grade implementation. However, it does not disclose side effects, permissions, or whether the operation is read-only. The mention of 'production-grade is Layer B' hints at a non-production status but is vague.
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 relatively concise but includes jargon ('C20', 'hive-secondary-inspection', 'Layer B') that may not be universally understood. The main purpose is front-loaded, but the additional jargon reduces clarity for agents not familiar with the domain.
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, no output schema, and no annotations, the description lacks sufficient context. It mentions the return value (signed inspection record) but does not describe its structure or behavior. Missing details on prerequisites, side effects, or when to use the tool limit completeness.
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 all parameters described in the input schema. The description does not add parameter-specific information beyond the schema, such as usage examples or constraints. Since schema coverage is high, a 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 performs 'probabilistic secondary inspection of a record batch' and returns a signed inspection record. It distinguishes itself from sibling tools by specifying 'secondary inspection' and referencing 'C20 — hive-secondary-inspection', making its purpose unique among many attest 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?
No explicit guidance on when to use this tool versus alternatives. The description mentions 'secondary inspection' but does not provide context for when it should be invoked nor when it should be avoided. Sibling tools are listed but no comparative usage instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_metaAInspect
Return HiveAttest layer/spec/patent metadata for all claims. Useful for agent introspection. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It implies a read-only operation (returning metadata) and mentions 'reference-grade implementation' and 'wire format normative', hinting at reliability. However, it does not explicitly state idempotency, side effects, or performance characteristics, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, front-loading the main purpose. It could be slightly more structured (e.g., separating metadata content from quality notes), but every sentence adds value and there is no 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 no output schema, the description omits specifics of the returned metadata format. However, for a simple parameterless metadata retrieval tool, it provides sufficient context: what it returns (layer/spec/patent metadata for all claims) and its quality. It is complete enough for most agents.
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 per guidelines the baseline is 4. The description adds nothing beyond the schema (which has no params), so it meets the baseline appropriately.
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 returns 'HiveAttest layer/spec/patent metadata for all claims', specifying the action (return) and resource (metadata). It distinguishes from sibling tools which focus on building, proving, verifying, etc., making its purpose distinct.
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 it is 'useful for agent introspection', implying a use case, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools for metadata or other purposes. This is adequate but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_passport_issueCInspect
Issue a Pre-Action Attestation Manifest (C15 — hive-passport). Signs with Ed25519 over RFC 8785 JCS-canonical body. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | No | Declared inputs (will be hashed) | |
| action_id | Yes | Caller-supplied action correlation ID | |
| agent_did | Yes | DID of the attesting agent | |
| intended_op | Yes | Operation name, e.g. "tool_invocation" | |
| ttl_seconds | No | Validity window in seconds (default 300) | |
| target_resource | Yes | URI or identifier of the target resource |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses signing with Ed25519 over JCS-canonical body, indicating a cryptographic operation. However, without annotations, it lacks information on side effects, persistence, or whether the operation is idempotent. The description does not contradict any annotations (none provided).
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 and front-loads purpose. However, phrases like 'Reference-grade implementation' and 'Wire format normative; production-grade is Layer B' are vague and may not aid tool selection, adding unnecessary 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 complexity (6 parameters, no output schema, nested objects), the description does not explain return values, required permissions, or how the manifest is used downstream. It fails to provide a complete picture for an agent to invoke confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The tool description adds context about signing and format but does not enrich parameter meaning beyond the schema. 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?
The description clearly states it issues a Pre-Action Attestation Manifest (C15 — hive-passport), specifying the action and format. However, it does not differentiate among sibling issuance tools like attest_warranty_issue, which also issue manifests.
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 guidance on when to use this tool versus alternatives. The description mentions 'Reference-grade implementation' and 'production-grade is Layer B', which hint at maturity but do not advise on scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_passport_verifyAInspect
Verify a Pre-Action Attestation Manifest (C15 — hive-passport). Checks Ed25519 signature, temporal validity, and optionally observed inputs hash. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| manifest | Yes | Full passport manifest object (from attest_passport_issue) | |
| observed_inputs | No | Optional observed inputs to check against declared hash |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description discloses core behaviors: signature verification, temporal validity check, and optional hash checking. However, it omits failure modes, error responses, and side effects. The 'reference-grade implementation' hint adds some reliability context, but overall transparency is incomplete.
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 brief (two sentences) and front-loaded with the core action. The second sentence adds relevant context about implementation quality, though it could be more tightly integrated. 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?
Given the tool's complexity (reference implementation, no output schema, two parameters), the description covers the verification purpose but does not explain return values or failure behavior. It hints at wire format norms but leaves the agent uncertain about the result format (boolean? status object?). Some 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?
With 100% schema coverage, the baseline is 3. The description adds value by linking the manifest parameter to attest_passport_issue and clarifying that observed_inputs is optional and used for hash verification, which goes beyond the schema's minimal 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 tool verifies a specific Pre-Action Attestation Manifest (C15, hive-passport) and lists the checks performed (Ed25519 signature, temporal validity, optional observed inputs hash). It references a sibling tool (attest_passport_issue) for the input manifest, distinguishing it from other verify tools on the server.
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 does not provide explicit guidance on when to use this tool versus alternatives like attest_custody_verify or attest_absence_verify. It mentions implementation maturity (reference-grade vs. production-grade Layer B) but does not clarify usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_smsh_verifyAInspect
Verify a SMSH-Stamp v1 receipt (C8/C12 — smsh-stamp-verifier). Validates schema, version, algorithm, timestamp, and Ed25519 signature. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| receipt | Yes | SMSH-Stamp v1 receipt object | |
| pubkey_b64url | No | Override trust anchor Ed25519 public key (base64url, 32 bytes) | |
| max_age_seconds | No | Reject receipts older than this many seconds |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses validation steps and implementation status (reference-grade, not production). With no annotations, it carries the burden and does so reasonably, though it omits failure behavior or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action. Concise but second sentence ('Wire format normative; production-grade is Layer B') is somewhat cryptic, slightly reducing clarity.
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?
Lacks return value/behavior description (no output schema). Provides context about implementation grade but misses output details for a complete 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 coverage is 100%, so baseline 3. The description adds no extra meaning to parameters (receipt, pubkey_b64url, max_age_seconds) beyond what the schema 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 tool verifies an SMSH-Stamp v1 receipt, specifying the exact validations (schema, version, algorithm, timestamp, signature). It distinguishes itself from siblings by the specific receipt type.
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?
Implies use for reference-grade validation due to 'Reference-grade implementation' and 'production-grade is Layer B', but does not explicitly state when to use this tool versus alternatives or provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_warranty_breachCInspect
Report a warranty breach. Marks the warranty as breached and returns a signed breach record (C18). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| evidence | No | Optional evidence dict | |
| warranty_id | Yes | Warranty ID to report breach on | |
| breach_description | Yes | Description of the breach |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It notes the state change ('marks as breached') but omits side effects, reversibility, permissions, or response format. Jargon like 'C18' and 'Layer B' adds confusion.
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?
First sentence is concise and clear. Second sentence is cryptic and arguably unnecessary for an agent, adding noise. Could be improved by removing or clarifying the jargon.
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 a nested object parameter and no output schema, the description is sparse. It doesn't explain preconditions, return value semantics, or how to handle the signed record. The 'Layer B' reference is unexplained, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions, so baseline is 3. The description adds no additional meaning or context for the parameters, leaving the schema to do the work.
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?
Clearly states it reports a warranty breach and marks it, with a mention of the return value (signed breach record). Lacks differentiation from sibling tools like attest_warranty_issue, but the verb 'report' and resource 'warranty breach' are specific enough.
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 guidance on when to use this tool vs alternatives like attest_warranty_get or attest_warranty_issue. The cryptic technical notes about 'Reference-grade' and 'Layer B' do not help an agent decide applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_warranty_getAInspect
Retrieve a warranty by ID (C18). Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| warranty_id | Yes | Warranty ID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'Reference-grade implementation' and 'Wire format normative' but does not disclose key traits like idempotency, side effects, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding distinct information: retrieval action, implementation grade, and wire format note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description is adequate but lacks specifics on return format, error scenarios, or required permissions. With many sibling tools, more context 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 coverage is 100% and the parameter description 'Warranty ID' is basic. The tool description adds no additional meaning beyond what the schema already provides, hence baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Retrieve), the resource (warranty), and the identifier (by ID). It also distinguishes from siblings like attest_warranty_issue and attest_warranty_breach by focusing on retrieval.
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 context about implementation grades (reference vs production) but lacks explicit guidance on when to use this tool versus alternatives, such as prerequisites or conditional usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
attest_warranty_issueBInspect
Issue an attestation warranty committing an agent to a claim (C18 — hive-attestation-warranty). Signed with Ed25519. Reference-grade implementation. Wire format normative; production-grade is Layer B.
| Name | Required | Description | Default |
|---|---|---|---|
| claim | Yes | Human-readable warranty claim | |
| scope | No | Scope constraints | |
| action_id | Yes | Action correlation ID being warranted | |
| agent_did | Yes | DID of the warranting agent | |
| expires_at | No | ISO-8601 expiry UTC (optional) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description reveals some behavioral traits (signed with Ed25519, reference-grade implementation, wire format normative) but does not fully disclose side effects, authentication needs, or rate limits. It adds moderate value beyond the missing 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 two sentences, begins with the core purpose, and avoids unnecessary words. It is efficient but could be more structured.
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?
No output schema, and the description does not explain the return value or side effects. As a mutation tool, it lacks information about what the attestation entails in terms of persistence or consequences.
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 all parameters have descriptions. The description does not add additional meaning beyond the schema; it merely restates 'Human-readable warranty claim' for the claim parameter. 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?
The description clearly states it 'Issues an attestation warranty committing an agent to a claim' and references a specific standard (C18). It distinguishes from siblings like attest_warranty_breach and attest_warranty_get by specifying the action of issuing.
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 guidance on when to use this tool versus alternatives like attest_warranty_breach or attest_warranty_get. The description lacks context for selecting this tool over others.
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!