MCP server for Linkd Fund escrow contract operations on Stellar Soroban. Handles fund escrow initialization, milestone management, deposits, proof submissions, approvals, refunds, and expenditure auditing with blockchain anchoring.
This Linkd escrow protocol server has well-defined schemas and descriptions for all 9 tools. Naming follows verb_noun patterns (init_escrow, deposit_funds, etc.). Schemas are registered via Zod and properly exposed. However, several critical issues reduce the score: (1) Most parameter descriptions lack detail on constraints, ranges, and error conditions. For example, 'targetAmount' has no guidance on minimum/maximum or unit semantics. (2) Output schemas are NOT documented, the tools return plain text XDR strings or status JSON with no formal structure definition, forcing LLMs to parse unstructured responses. (3) No error handling guidance, if a contract is not found or an operation fails, tools return errors with no recovery hints. (4) Security considerations are absent, no mention of transaction signing, secret injection, or auditing. (5) Parameter relationships are undocumented (e.g., which roles can call which tools, or what happens if milestoneId does not exist). Overall, the tools are functional but lack production-grade polish for safe LLM consumption.
Tools (9)
add_milestonewritesource verified73/100
Prepares a transaction XDR to add a funding milestone.
approve_auditorwritesource verified74/100
Prepares a transaction XDR for the AI Auditor to sign off on a verified invoice.
approve_ngowritesource verified74/100
Prepares a transaction XDR for the NGO to sign off on a milestone.
Cross-layer audit: recomputes the deterministic expenditure hash and verifies it matches the memo anchored on the Stellar ledger. Returns a strict JSON audit report.
deposit_fundswritesource verified73/100
Prepares a transaction XDR to lock funds into the escrow.
get_escrow_statusread onlysource verified77/100
Retrieves real-time on-chain status (total escrowed, milestone count).
init_escrowwritesource verified77/100
Prepares a transaction XDR to initialize a Linkd Fund escrow contract.
Add parameter constraints to all descriptions. E.g., 'targetAmount: The funding target in stroops (smallest Stellar unit, 1 - 10000000 allowed). Must be >0 and aligned with token decimals.' Similarly for contractId ('Soroban contract ID, 56-char alphanumeric string'), proofHash ('IPFS v0 CID or eTIMS hash, 46+ chars'), refundAddress ('Valid Stellar public key, 56 chars starting with G').
Add error handling guidance to each tool. E.g., 'If contract not initialized, call init_escrow first. If milestoneId not found, call get_escrow_status to list valid IDs. If signer unauthorized, verify account has the required role (admin/ngo/auditor).'
Implement dry-run or confirmation pattern for refund_milestone. Add optional parameter dry_run: bool (default false) or split into refund_milestone_prepare (returns estimated refund) + refund_milestone_execute (requires explicit confirmation hash). This prevents accidental fund loss.
Clarify role-based authorization in approve_ngo and approve_auditor descriptions. E.g., 'approve_ngo: Called when the NGO signs off on milestone completion. Only the NGO public key can call this.' Similarly for approve_auditor. Consider renaming to approveNgo_byRole() and approveAuditor_byRole() if role is enforced server-side.
Score history
Overall score trend
↑ 56 points across a rubric change (v1 → v2)
56/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
D
56
2026-07-28+
v2
2026-03-09
F
0
-
v1
refund_milestonereversiblesource verified75/100
Prepares a transaction XDR for the Admin to cancel a milestone and refund capital.
submit_proofwritesource verified77/100
Prepares a transaction XDR for the NGO to submit a proof hash (eTIMS/IPFS).
Parameter relationships undefined. E.g., approve_ngo and approve_auditor both accept 'signer' but docs don't clarify role-based authorization, whether a milestone must exist, or permission model.
Overlapping tool semantics. approve_ngo and approve_auditor are nearly identical in schema; LLMs may select the wrong one. No clear distinction in descriptions.
Document idempotency guarantees. E.g., 'Calling deposit_funds twice with the same donor, contractId, and amount is safe, the second call is ignored (idempotent). Calling approve_ngo on an already-approved milestone returns success without re-executing.'
Add security/audit fields to descriptions. E.g., 'All XDR-returning tools require offline signing; the server never holds private keys. Caller must sign the XDR before submitting to Stellar. All state changes are logged with caller identity for compliance.'
For approve_ngo and approve_auditor, unify if possible or add explicit examples: 'Use approve_ngo when the NGO organization signs off. Use approve_auditor when the AI Auditor oracle verifies and approves. Both methods accept a signer (public key) and milestoneId; the server enforces that only the authorized role can succeed.'
Add parameter type suffixes for clarity. Rename bare 'admin', 'ngo', 'auditor', 'donor', 'signer', 'refundAddress' to 'admin_publicKey', 'ngo_publicKey', 'auditor_publicKey', 'donor_publicKey', 'signer_publicKey', 'refund_publicKey' to eliminate ambiguity (are these addresses, IDs, or names?).
Include pagination and limits guidance for get_escrow_status. E.g., 'Returns up to 100 milestones. If more exist, provide a next_cursor in the response for fetching subsequent pages.'
For audit_expenditure_anchor, clarify the 'deterministic expenditure hash' algorithm in the description: 'Recomputes BLAKE2b(invoiceNumber | amount | supplierName | sortedDonorIds) and compares against the memo field anchored on the Stellar transaction (stellarTxHash). Returns pass/fail with details.'
Add explicit dependency documentation. E.g., 'deposit_funds requires init_escrow to be called first. add_milestone requires init_escrow to be completed. approve_ngo requires a milestone to exist (created via add_milestone and funded via deposit_funds).'