base-escrow-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a distinct purpose: get_deal retrieves by ID, get_buyer_deals and get_seller_deals filter by role, get_escrow_info provides contract metadata, and create/release/refund/dispute handle lifecycle actions. No two tools overlap ambiguously.
Naming Consistency5/5
All query tools follow a get_* pattern, and all action tools use the *_escrow suffix. The verb-noun structure is consistent throughout, making the API predictable and easy to navigate.
Tool Count5/5
With 8 tools, the server is well-scoped for an escrow management domain. Each tool covers a core operation or query without redundancy or bloat.
Completeness5/5
The tool set covers the full escrow lifecycle: creation, release, refund, and dispute, along with sufficient query capabilities (by ID, buyer, seller, and contract info). No obvious gaps exist for common use cases.
Average 4.1/5 across 8 of 8 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It does disclose the return fields (buyer, seller, token, amount, status, creation time, description), which is useful. However, it omits details like error handling, permissions, or side-effect information, leaving gaps in transparency.
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 a single, efficient sentence that is front-loaded with the verb and resource. It includes useful return-field details without any unnecessary words, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema or annotations. The description covers purpose, parameter, and return fields. However, it fails to clarify behavior when the deal is not found, differentiate from 'get_escrow_info', or note any permissions. Given the lack of annotations, this feels incomplete for a robust agent decision.
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% since the only parameter 'deal_id' has a description. The tool description adds no new semantics beyond repeating 'by its ID'. Baseline 3 is appropriate as the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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: fetching details of an escrow deal by ID. It uses a specific verb and resource, and lists the returned fields. However, it does not distinguish itself from the sibling tool 'get_escrow_info', which may serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not state when to use this tool versus alternatives like 'get_buyer_deals' or 'get_escrow_info', nor does it mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of indicating behavior. 'Get' implies a read-only operation, and the return of deal IDs is stated. However, it adds no detail about pagination, error handling, or whether the address must be exactly the seller, making the transparency adequate but minimal.
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 a single, clear sentence with no redundant words. It efficiently communicates the tool's purpose and scope.
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 and no output schema, the description adequately specifies the return content (deal IDs) and the filtering condition. It is complete enough for an agent to understand what the tool returns and when to invoke it.
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?
The schema description for the address parameter ('Seller wallet address') fully aligns with the tool description's use of 'seller'. Since schema description coverage is 100%, the tool description adds no additional parameter detail, matching the baseline for high coverage.
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: retrieving all escrow deal IDs for a given seller address. It uses a specific verb ('Get'), identifies the resource ('escrow deal IDs'), and specifies the filter (address as seller), which distinguishes it from sibling tools like get_buyer_deals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need deals where the address is the seller) but does not explicitly mention alternatives or exclusions. Sibling tools like get_buyer_deals are not referenced, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description itself must convey safety and side effects. 'Get' implies a read-only operation, but it doesn't explicitly state non-mutating behavior or disclose any potential side effects, auth requirements, or response format. It adds value by listing the specific fields returned.
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?
A single sentence with no filler. The purpose is front-loaded and the list of returned values is compact yet informative.
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?
For a simple info tool with no parameters and no output schema, the description adequately covers what data is returned and the intended use. It doesn't elaborate on network specifics or address formats, but such details are not essential for basic usage.
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 takes zero parameters, so the schema is fully described by the empty object. The description adds meaning by enumerating what information is returned, which is helpful given no output 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 verb 'Get' and the resource 'Escrow contract info', followed by specific data points (fee, deals created, treasury address, contract address). This distinguishes it from sibling tools like get_deal or get_buyer_deals, which focus on individual deals or user-specific views.
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?
It explicitly says 'Use to verify the contract is live', giving a clear context. While it doesn't mention alternatives or exclusions, the use case is specific enough to infer when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the caller restriction, the required DEPLOYER_PRIVATE_KEY env var, and the outcome (refunding funds to buyer). It does not cover failure states or lifecycle prerequisites, but the essential behavioral context is present.
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 three short, front-loaded sentences with no filler. Each sentence provides a distinct, necessary piece of information: the action, the usage condition, and the environment requirement.
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 tool is simple with one parameter and no output schema. The description adequately covers purpose, usage trigger, user restriction, and environment variable. Minor gaps exist around potential state prerequisites (e.g., whether a dispute must be active), but overall it is sufficient for confident 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 coverage is 100% since the single required parameter deal_id is documented as 'Deal ID to refund'. The tool description adds context about refunding to buyer, but this is largely consistent with the schema and does not provide substantial additional parameter semantics.
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 action ('Refund escrowed funds'), the target ('back to the buyer'), and the triggering condition ('when the seller fails to deliver'). This distinguishes it from sibling tools like release_escrow (pay seller) and dispute_escrow (open dispute).
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?
Explicitly states when to use ('Use when the seller fails to deliver') and who can call it ('Only the buyer can call this'). It does not mention alternatives or when-not-to-use, but the context is clear enough for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behavioral traits: buyer-only restriction, state change to complete, and the DEPLOYER_PRIVATE_KEY prerequisite. It stops short of detailing irreversibility or failure modes, which would elevate it further.
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?
Two sentences, no waste, front-loaded with the primary action. Every clause earns its place.
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?
For a simple one-parameter financial tool with no output schema, the description covers the actor, effect, and a critical prerequisite. Missing return value details are acceptable given the simple scope, though failure outcomes are not addressed.
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?
The schema already fully documents deal_id as 'Deal ID to release' (100% coverage), so the description adds no new parameter meaning. Baseline 3 applies because the schema handles it.
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 a specific action ('Release escrowed funds to the seller') and resource ('escrowed funds'), and distinguishes from siblings like refund_escrow (refund) and dispute_escrow by noting it marks the deal as complete and is buyer-only.
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?
It provides clear context: who can call (only buyer), what it accomplishes (releases funds, marks complete), and a required environment variable. However, it does not explicitly contrast with alternative tools like refund_escrow or dispute_escrow, so it lacks explicit 'when/not' comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Get' signals a read-only operation, and the return type is specified as 'escrow deal IDs'. It adds the scoping condition (buyer), which is useful. It does not cover pagination or auth, but for a simple query this is adequate.
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?
One sentence, no filler, information-dense. Every word adds value.
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 low-complexity tool with one parameter and no output schema, the description adequately explains what is returned (deal IDs) and the filter (buyer address). No gaps.
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?
The only parameter 'address' is fully described in the schema as 'Buyer wallet address', and the description repeats the same concept. No additional parameter semantics are provided beyond the schema, so baseline 3 applies.
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 a specific action (get) on a specific resource (escrow deal IDs) filtered by buyer address. It distinguishes itself from the sibling get_seller_deals by explicitly mentioning 'buyer'.
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 implies when to use: when you need deals where the address is the buyer. It does not explicitly mention alternatives like get_seller_deals, but the buyer/seller contrast is clear from sibling tools. Context is clear without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: ETH is locked, ERC-20 tokens are transferred from wallet with automatic approval, a flat fee is charged in ETH, and a required env var. This is substantial and goes beyond simple 'create' boilerplate.
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?
Three concise sentences, each earning their place: main action, token-specific behavior, and required prerequisite/fee. No fluff, front-loaded with the purpose.
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 tool has moderate complexity (two token types, fee, env var) and no output schema. The description covers the key semantics and prerequisites, though it doesn't mention the return value or whether an escrow ID is generated. Still, it's sufficient for an agent to understand what the tool does and when to call it.
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?
Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the token parameter's zero-address convention for ETH, the automatic approval handling, and the units for amount. This helps the agent understand how to set parameters correctly beyond the schema's raw field descriptions.
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 creates a new P2P escrow deal on Base, with specific behavior for ETH vs ERC-20. It distinguishes itself from all sibling tools (which are getters, release, refund, dispute) by focusing on the creation action.
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?
It clearly implies when to use this tool (to create an escrow) and provides the prerequisites (DEPLOYER_PRIVATE_KEY). It doesn't explicitly mention alternatives or exclusions, but among siblings this is the only create/action tool, so the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses two behavioral traits: funds remain locked until treasury resolution, and DEPLOYER_PRIVATE_KEY env var is required. This informs the agent of side effects and authentication needs, though it doesn't mention reversibility or invocation limits.
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?
Three concise sentences, each adding critical information: purpose, eligibility/outcome, and environment prerequisite. No redundant language. The description is front-loaded with the primary verb and object.
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?
For a single-parameter tool with no output schema, the description covers purpose, eligibility, fund-locking consequence, and env var requirement. It leaves little ambiguity about invocation, though it doesn't describe the return value or failure modes, which is a minor gap.
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 schema fully documents deal_id, and the description adds the constraint that it must be an active escrow deal, supplementing the schema's generic 'Deal ID to dispute.' This provides extra meaning 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 function: 'Flag a dispute on an active escrow deal.' This distinguishes it from sibling tools like release_escrow or refund_escrow, which handle normal completion paths. The verb 'Flag' and resource 'active escrow deal' are specific.
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?
It notes 'Either buyer or seller can call this,' giving eligibility context. However, it doesn't explicitly contrast with alternatives like release_escrow or refund_escrow, so it stops short of full when/where-not guidance. The context is clear enough for the agent to infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![base-escrow-mcp MCP server](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/base-escrow-mcp/badges/card.svg)](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/base-escrow-mcp)

Score Badge

Copy to your README.md:

[![base-escrow-mcp MCP server](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/base-escrow-mcp/badges/score.svg)](https://glama.ai/mcp/servers/lordbasilaiassistant-sudo/base-escrow-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lordbasilaiassistant-sudo/base-escrow-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server