Research Decisions
Date: 2026-02-16
Decision 1: Go Implementation
Context: Choose language for MCP server that wraps Namecheap API.
Chosen: Go.
Rationale:
- Static binary, easy deployment.
- Excellent stdlib for HTTP and XML.
- Consistent with other OpenClaw tools (DNS server project).
- Good standard for CLI tools.
Decision 2: Stdio Transport
Context: MCP transport (stdio vs TCP).
Chosen: stdio (JSON‑RPC over stdin/stdout).
Rationale:
- Simplicity; no network port exposure.
- Fits MCP standard for local agents.
- Access control via OS permissions.
Decision 3: Tool Set
Context: Which operations to expose.
Chosen:
- `namecheap.domains.list`
- `namecheap.dns.list_records`
- `namecheap.dns.add_record`
- `namecheap.dns.delete_record`
- `namecheap.dns.set_nameservers`
- `namecheap.dns.get_nameservers`
Rationale:
- Covers essential DNS management use‑cases.
- Simpler than full CRUD with update; update can be expressed as delete+add.
- MVP scope manageable.
Decision 4: Update via Delete+Add
Context: Namecheap lacks a direct record update endpoint; setHostRecords replaces entire zone.
Chosen: Omit `update_record` from MVP; users use `delete_record` + `add_record`.
Rationale:
- Avoids complexity of zone replace logic.
- Reduces risk of accidentally deleting other records.
- Adequate for automation where old record is known and removed explicitly.
Decision 5: Use Sandbox First
Context: Testing against live API could affect real domains.
Chosen: Develop and test against Namecheap sandbox environment (`api.sandbox.namecheap.com`), then switch to production with real credentials.
Rationale:
- Safe; no risk to live DNS.
- Sandbox likely mirrors production behavior.
Decision 6: Rate Limiting
Context: Prevent hitting Namecheap rate limits.
Chosen: Client‑side limiter (1–2 QPS) with retry and backoff.
Rationale:
- Defensive; polite to API.
- Handles occasional spikes.