- Go 97.6%
- Python 2.4%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
| .forgejo/workflows | ||
| cdpScripts | ||
| cmd | ||
| config | ||
| internal | ||
| scripts | ||
| sql | ||
| testClient | ||
| .gitignore | ||
| .golangci.yml | ||
| AGENTS.md | ||
| docker-compose.test.yml | ||
| go.mod | ||
| go.sum | ||
| mcpServer.service | ||
| README.md | ||
| sqlc.yaml | ||
naco-api
Go MCP server (13 tools) for Bluesky / Nostr / ActivityPub / Twitter, gated by x402 crypto payments.
See AGENTS.md for architecture, commands, and development conventions.
Payment deadline note (TO REMEMBER)
MaxTimeoutSeconds in internal/server/settlement.go (buildRequirements) is set to 600s — not 60s.
Why: for the upto scheme the client signs the Permit2 permit with deadline = now + MaxTimeoutSeconds, and the MCP wrapper settles only after the tool handler has executed. A slow handler (e.g. getStyleProfile which fetches posts and runs style analysis) plus round-trip latency therefore sits inside the permit's validity window. With 60s the permit expired before settlement and the facilitator rejected with 400 invalid_exact_evm_permit2_payload_deadline.
If a new payable tool is added with a handler slower than the current deadline window, bump this value along with the HTTP/test timeouts rather than shrinking it back down.