evermint-mcpofficial
A
license-
qualityD
maintenanceTamper-evident receipts for AI agent actions. The notary layer for agent-to-agent transactions.
52
1
MIT
Ambr
Server Details
Ricardian contracts for AI agents — dual-format, SHA-256 bound, legible by construction.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
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.
100% free. Your data is private.
Tool Definition Quality
A4.4/5.0
Tool DescriptionsA
Average 4.3/5 across 6 of 6 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool has a unique purpose: handshake, create, get, status, list templates, and verify hash. No two tools overlap in functionality, making selection unambiguous.
Naming Consistency5/5
All tool names follow a consistent 'ambr_verb_noun' pattern (e.g., ambr_create_contract, ambr_get_contract). The naming is uniform and predictable.
Tool Count5/5
With 6 tools, the set covers the essential operations for contract management without being excessive. The count is appropriate for the domain.
Completeness4/5
The tools cover creation, retrieval, status, template discovery, hash verification, and agent handshake. Missing a tool to list all user contracts, but amendment handling via create_contract with parent hash addresses lifecycle partially.
Available Tools
6 toolsambr_agent_handshakeAIdempotentInspect
Initiate a handshake on a contract on behalf of your delegating principal.
Requires an API key with an active delegation (principal wallet registered via /api/v1/delegations). Records the agent's intent to accept, reject, or request changes on the contract. The principal must separately approve via wallet signature on the Reader Portal.
Args:
contract_id (string, required): Contract ID (amb-YYYY-NNNN), SHA-256 hash, or UUID
intent (string, required): "accept" | "reject" | "request_changes"
message (string, optional): Note for the counterparty
visibility_preference (string, optional): "private" | "metadata_only" | "public" | "encrypted"
Returns: Handshake status and next steps for principal approval.
Legibility: the handshake itself is auditable — delegation scope, agent identity, and principal approval are recorded alongside the contract hash.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| intent | Yes | Handshake intent | |
| message | No | Optional note for counterparty | |
| contract_id | Yes | Contract ID, SHA-256 hash, or UUID | |
| visibility_preference | No | Optional visibility preference for negotiation |
Tool Definition Quality
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (idempotentHint=true, destructiveHint=false), the description explains that the action records agent intent, requires principal approval, and is auditable, providing useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, requirements, args, returns, legibility). It is not overly verbose but could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 2 required, no output schema), the description covers purpose, prerequisites, parameter details, and expected output. It is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents parameters. The description lists args but does not add significant new meaning beyond what the schema provides; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's action: initiating a handshake on a contract as an agent. It distinguishes from siblings (e.g., create_contract, get_contract) by focusing on recording intent and requiring principal approval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Prerequisites are stated (API key with active delegation, principal must separately approve). Context for use is implied but explicit when-not-to-use or alternatives are not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ambr_create_contractAInspect
Generate a Ricardian Contract from a template.
Creates a dual-format contract (human-readable legal text + machine-parsable JSON) using AI, linked by SHA-256 hash. The contract is stored on Ambr and accessible via the Reader Portal.
Requires a valid API key (X-API-Key header on the HTTP request) with available credits. Use ambr_list_templates first to discover templates and their required parameters.
Args:
template (string, required): Template slug (e.g. "d1-general-auth")
parameters (object, required): Template-specific parameters matching the schema
principal_declaration (object, required): { agent_id, principal_name, principal_type }
parent_contract_hash (string, optional): SHA-256 hash of parent contract for amendments
amendment_type (string, optional): "original" | "amendment" | "extension"
Returns:
contract_id: Unique ID (e.g. "amb-2026-0042")
sha256_hash: SHA-256 hash for verification
status: Contract status
reader_url: URL to view in Reader Portal
credits_remaining: Remaining API credits
Legibility: Output is dual-format by construction and replayable to the original SHA-256 hash — the basis of Ambr's legibility guarantee.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| template | Yes | Template slug from ambr_list_templates | |
| parameters | Yes | Template-specific parameters | |
| amendment_type | No | ||
| parent_contract_hash | No | SHA-256 hash of parent contract (for amendments) | |
| principal_declaration | Yes |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations all false, the description carries the full burden. It explains the dual-format output, SHA-256 linking, storage, legibility guarantee, and authentication/credit requirements. It does not mention error handling or side effects but adds substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary, followed by concise sections for prerequisites, parameters, returns, and legibility. Every sentence serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return values and key behavioral aspects, which is critical given no output schema. It does not detail error conditions or optional parameter behaviors, but it is largely complete for the complexity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, and the description restates parameter types and requirements. It adds context like template slug sourced from ambr_list_templates and the purpose of parent_contract_hash for amendments. The value added is moderate but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a Ricardian Contract from a template, with a specific verb and resource. It distinguishes itself from sibling tools like ambr_get_contract (reading) and ambr_list_templates (listing templates) through its creation function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using ambr_list_templates first to discover templates and parameters, providing key prerequisite guidance. However, it does not explicitly state when not to use this tool or compare directly with siblings like ambr_agent_handshake.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ambr_get_contractARead-onlyIdempotentInspect
Retrieve a contract by ID, SHA-256 hash, or UUID.
With a valid API key (contract creator): returns the full contract including human-readable text, machine-readable JSON, status, and principal declaration. Without authentication: returns metadata only (contract_id, status, hash, dates).
Supports three lookup formats:
Contract ID: "amb-2026-0042"
SHA-256 hash: 64-character hex string
UUID: Standard UUID format
Args:
id (string, required): Contract ID, SHA-256 hash, or UUID
Returns: Full contract (if authorized) or metadata-only response.
Legibility: retrieval preserves the dual-format pairing — prose and JSON always replay to the same SHA-256.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Contract ID (amb-YYYY-NNNN), SHA-256 hash, or UUID |
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds context on the dual-format pairing and legibility guarantee, and explains the difference in responses based on authentication, going beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and examples. It is appropriately sized for the tool's complexity, front-loading the main purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description thoroughly covers the conditional return values, authentication behavior, and even the legibility guarantee, making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description enriches the 'id' parameter with concrete examples (amb-2026-0042, SHA-256, UUID) and clarifies the three allowable formats, adding significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a contract by ID, SHA-256 hash, or UUID' with a specific verb and resource, and distinguishes itself from siblings by detailing the three identifier formats and authentication-dependent responses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on usage with and without authentication, and lists three lookup formats. However, it does not directly reference sibling tools or state when to use this tool over alternatives like ambr_get_contract_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ambr_get_contract_statusARead-onlyIdempotentInspect
Check the status of a contract and its amendment chain.
Returns the current status and any linked amendments (parent or child contracts). Useful for verifying if a contract is active, amended, or terminated.
Args:
id (string, required): Contract ID, SHA-256 hash, or UUID
Returns:
contract_id, status, created_at
amendment_type, parent_contract_hash
amendments: Array of child contracts (if any)
Legibility: amendments are bilateral and themselves dual-format — the chain stays legible from original through every revision.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Contract ID (amb-YYYY-NNNN), SHA-256 hash, or UUID |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds behavioral details about the amendment chain's legibility and return format, providing value beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose, followed by usage, arguments, returns, and legibility note. The Args section redundantly restates schema info, slightly reducing conciseness, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description lists return fields and explains the tool's role in contract status verification. For a simple, single-parameter read-only tool, this is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both schema and description define the 'id' parameter identically. The description adds no new semantics beyond what the schema already provides, meeting baseline only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Check') and resource ('status of a contract and its amendment chain'), and distinguishes from siblings like ambr_get_contract by focusing on status and amendments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use ('verifying if a contract is active, amended, or terminated') and implies alternatives by contrast with sibling tools, though explicit when-not-to-use is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ambr_list_templatesARead-onlyIdempotentInspect
List available contract templates on Ambr.
Returns all active Ricardian Contract templates with their slugs, names, descriptions, categories, parameter schemas, and pricing. Use this to discover which templates are available before creating a contract with ambr_create_contract.
No authentication required.
Returns: Array of template objects with slug, name, description, category, parameter_schema, price_cents, and version fields.
Legibility: templates are the parameter schema for the dual-format contracts you create — starting here keeps your request conformant and your output defensible.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
A4.6/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool is free of authentication requirements and returns active templates with specific fields. This provides additional context about safety and behavior beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with key information front-loaded. It uses three sentences: purpose, usage guidance, and output. The legibility note adds minor clutter but is not overly verbose. Could be slightly tighter, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and annotations cover safety, the description is complete. It explains the tool's purpose, when to use it, what it returns, and that no auth is needed. This covers all essential aspects for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema coverage 100%), so the description does not need to explain them. The baseline for 0 parameters is 4, and the description appropriately omits parameter details while otherwise adding value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: listing available contract templates on Ambr. It specifies the verb (List), resource (contract templates), and scope (available/active). It distinguishes from siblings like ambr_create_contract by stating its use for discovery before creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this to discover which templates are available before creating a contract with ambr_create_contract.' It also provides a non-usage detail (no authentication required) and clarifies the return structure, helping the agent decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ambr_verify_hashARead-onlyIdempotentInspect
Verify a contract's SHA-256 hash to confirm document integrity.
Checks whether the provided hash matches a contract stored on Ambr. Returns verification status, contract metadata, and Reader Portal URL if found.
Args:
hash (string, required): SHA-256 hash (64-character hex string)
Returns:
verified: boolean
contract_id: string (if found)
status: string (if found)
reader_url: string (if found)
Legibility: verification is the point at which legibility becomes provable — matching hash means the prose a human reads and the JSON a machine parses are the same document that was originally signed.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | SHA-256 hash to verify (64-character hex) |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds behavioral details such as returning verification status, contract metadata, and Reader Portal URL. It also includes a philosophical note on legibility, which provides extra context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The 'Legibility' paragraph adds abstract context but could be considered slightly verbose for an agent. Overall, it is efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is complete. It explains the action, the required input format, the return values (despite no output schema), and provides sufficient context for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'hash'. The description adds the format constraint ('64-character hex string'), but this is already present in the schema's description. Thus, the description adds limited value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: verifying a contract's SHA-256 hash to confirm document integrity. It uses a specific verb ('verify') and resource ('contract's SHA-256 hash'), and the tool is distinct from siblings like 'ambr_create_contract' or 'ambr_get_contract'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives or when not to use it. The context is clear enough given sibling names, but explicit guidance is missing.
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!
Related MCP Servers
- Alicense-qualityDmaintenanceAI agent commerce platform — 141 tools for payments, escrow, identity, marketplace, and Z3 formal verificationMIT
emilia-mcp-serverofficial
AlicenseAqualityAmaintenanceThe accountability layer for AI agents — a named human's signed yes before an agent does anything irreversible (payment, record change, deploy), then an offline-verifiable Trust Receipt. Apache-2.0, formally verified.17846Apache 2.0- FlicenseCqualityBmaintenanceThe trust-and-settlement rails of the agent economy: identity, trust, escrow, metering, arbitration, compute-carbon ledger, covenant, provenance, offsets, ERC-8004 bridge, surety, notary, and discovery — plus sellable measurement/CAD services. Durable, machine-checkable invariants, free rails.100