核心用法
Bind MCP提供双服务器架构：本地服务器(bind)处理敏感凭证数据，远程服务器(bind-remote)执行需要后端服务的操作。核心工作流涵盖四大场景：
凭证验证流程：bind_parse_credential解码JWT → bind_verify_credential本地验签 → bind_hash_credential计算哈希 → bind_check_revocation远程查吊销状态。关键设计：原始凭证永不离开本地机器，仅发送不可逆哈希进行吊销检查。
发行方调查：通过bind_resolve_issuer获取组织公钥，bind_list_policies/bind_explain_policy查询验证策略。
策略创建：需先调用bind_whoami确认组织名称与权限层级，构建策略JSON后先bind_validate_policy dry-run验证，再bind_create_policy创建，最后bind_generate_circuit编译ZK电路。策略需严格遵循命名空间规则（以组织名开头），字符串输入必须配置encoding映射为数值。
证明生成与凭证发行：选择电路后bind_submit_prove_job提交输入，轮询状态完成后bind_issue_credential签发VC-JWT，可选bind_share_proof分享给验证方。
显著优点
- 隐私优先架构：敏感凭证处理完全本地执行，远程仅交互哈希与元数据
- 零知识证明原生支持：内置Noir电路编译与证明生成，支持选择性披露
- 细粒度权限控制：Agent Key支持按工具类别授权、日配额限制、审计日志
- 分层验证模型：解析、验签、吊销检查解耦，支持渐进式验证
潜在局限
- Node.js >= 18硬性依赖：老旧环境无法运行
- Agent Key一次性暴露：密钥仅显示一次，丢失需重新创建
- 字符串输入强制编码：ZK电路仅支持数值，策略设计复杂度较高
- 电路编译耗时：
bind_generate_circuit为异步作业需轮询等待 - 层级功能受限：Basic/Verifier层级无法创建策略，需付费升级
适合人群
- 需要验证用户凭证的DApp开发者（金融、出行、身份场景）
- 希望自托管验证策略的企业合规团队
- 探索隐私保护凭证方案的Web3产品经理
- 需集成链下证明到链上合约的Solidity开发者
常规风险
| 风险类型 | 说明 | 缓解措施 |
|---------|------|---------|
| 密钥泄露 | Agent Key明文存储于环境变量 | 使用`${BIND_MCP_TOKEN}`占位符，避免硬编码 || 策略命名空间错误 | 使用`bind`/`system`保留空间或组织名不匹配 | 严格遵循`bind_whoami`返回的org名称 |
| 吊销检查遗漏 | `bind_verify_credential`不查吊销状态 | 必须后续执行`hash + check_revocation`完整流程 |
| 电路输入溢出 | Noir类型不匹配导致编译失败 | 严格匹配`inputTypes`声明的位宽（u8/u32等） |
| 证明作业挂起 | 异步作业未完成即调用issue | 轮询`bind_get_prove_job`至`completed`状态 |