@simpleapps-com/augur-skills 0.0.12 → 0.0.14
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: augur-api
|
|
3
|
+
description: Augur API integration via MCP. Covers service discovery, multi-site CRUD operations across Augur microservices, and credential resolution. Use when querying or modifying Augur data (contacts, transactions, inventory, etc.).
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Augur API
|
|
7
|
+
|
|
8
|
+
MCP server exposing Augur microservices through 7 generic tools.
|
|
9
|
+
|
|
10
|
+
## Tools
|
|
11
|
+
|
|
12
|
+
| Tool | Purpose |
|
|
13
|
+
|------|---------|
|
|
14
|
+
| `augur_discover` | List services or endpoints for a service |
|
|
15
|
+
| `augur_sites` | List configured sites with default flag |
|
|
16
|
+
| `augur_list` | List records (GET collection) |
|
|
17
|
+
| `augur_get` | Get single record by ID |
|
|
18
|
+
| `augur_create` | Create record (POST) |
|
|
19
|
+
| `augur_update` | Update record (PUT) |
|
|
20
|
+
| `augur_delete` | Delete record (DELETE) |
|
|
21
|
+
|
|
22
|
+
All 5 data tools (`augur_list`, `augur_get`, `augur_create`, `augur_update`, `augur_delete`) accept an optional `site` parameter to target a specific site. Omit `site` to use the default.
|
|
23
|
+
|
|
24
|
+
## Usage Pattern
|
|
25
|
+
|
|
26
|
+
Always start with discovery:
|
|
27
|
+
|
|
28
|
+
1. `augur_sites()` — see which sites are configured and which is default
|
|
29
|
+
2. `augur_discover()` — lists all available services
|
|
30
|
+
3. `augur_discover(service="<name>")` — lists endpoints for a specific service
|
|
31
|
+
4. Use data tools for CRUD, passing `site` when targeting a non-default site
|
|
32
|
+
|
|
33
|
+
Do NOT hardcode service names or endpoints. Use `augur_discover` to find them at runtime.
|
|
34
|
+
|
|
35
|
+
## Authentication
|
|
36
|
+
|
|
37
|
+
Credentials resolve automatically from `.simpleapps/` directories.
|
|
38
|
+
|
|
39
|
+
Resolution order (first match wins):
|
|
40
|
+
|
|
41
|
+
1. **Env vars** — `AUGUR_TOKEN` + `AUGUR_SITE_ID`
|
|
42
|
+
2. **Explicit file** — `AUGUR_CREDS_FILE` env var pointing to a JSON file
|
|
43
|
+
3. **Project file** — `<cwd>/.simpleapps/augur-api.json`
|
|
44
|
+
4. **Global file** — `~/.simpleapps/augur-api.json`
|
|
45
|
+
|
|
46
|
+
Project and global files are merged (project takes precedence).
|
|
47
|
+
|
|
48
|
+
### Single-site format
|
|
49
|
+
|
|
50
|
+
```json
|
|
51
|
+
{
|
|
52
|
+
"siteId": "my-site",
|
|
53
|
+
"jwt": "my-token"
|
|
54
|
+
}
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
### Multi-site format
|
|
58
|
+
|
|
59
|
+
```json
|
|
60
|
+
{
|
|
61
|
+
"site-a": { "jwt": "token-a" },
|
|
62
|
+
"site-b": { "jwt": "token-b" }
|
|
63
|
+
}
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
## API Reference
|
|
67
|
+
|
|
68
|
+
Documentation hub: https://augur-api.info/
|
|
69
|
+
|
|
70
|
+
- **Service directory** — https://items.augur-api.com/llms.txt lists all available services
|
|
71
|
+
- **Per-service docs** — `https://{service}.augur-api.com/llms.txt` (LLM-friendly), `/openapi.json`, `/postman.json`, `/endpoints.jsonl`
|
|
72
|
+
- **FAQ for agents** — https://augur-api.info/faq.md (auth, pagination, rate limits)
|
|
73
|
+
|
|
74
|
+
Services include items, pricing, commerce, orders, customers, payments, shipping, open-search, and more. Use `augur_discover` at runtime rather than hardcoding service names.
|
|
75
|
+
|
|
76
|
+
## When Auth Fails
|
|
77
|
+
|
|
78
|
+
If tools return authentication errors:
|
|
79
|
+
- Check for `.simpleapps/augur-api.json` in the project directory or home directory
|
|
80
|
+
- Verify the file contains valid credentials (single-site or multi-site format)
|
|
81
|
+
- Fallback: set `AUGUR_TOKEN` and `AUGUR_SITE_ID` env vars
|
|
@@ -6,11 +6,13 @@ Every project MUST use this layout:
|
|
|
6
6
|
|
|
7
7
|
```
|
|
8
8
|
{project}/
|
|
9
|
-
├── repo/
|
|
10
|
-
|
|
9
|
+
├── repo/ # Main git repo (simpleapps-com/<name>.git)
|
|
10
|
+
├── wiki/ # GitHub wiki repo (simpleapps-com/<name>.wiki.git)
|
|
11
|
+
├── wip/ # Work-in-progress files for active tasks (not in git)
|
|
12
|
+
└── protected/ # Secrets and credentials for dev testing (not in git)
|
|
11
13
|
```
|
|
12
14
|
|
|
13
|
-
The parent `{project}/` directory is NOT a git repo — it's a local wrapper that keeps the code repo and wiki side-by-side.
|
|
15
|
+
The parent `{project}/` directory is NOT a git repo — it's a local wrapper that keeps the code repo and wiki side-by-side. The `wip/` and `protected/` directories sit outside both git trees so their contents can never be accidentally committed.
|
|
14
16
|
|
|
15
17
|
## Why This Pattern
|
|
16
18
|
|
|
@@ -38,8 +40,46 @@ If the wiki repo doesn't exist yet, create it by adding any page via the GitHub
|
|
|
38
40
|
| Repo README | `repo/README.md` | Minimal — quick start + link to wiki |
|
|
39
41
|
| Repo `.claude/rules/` | `repo/` | Minimal summaries referencing wiki pages |
|
|
40
42
|
| Repo `.claude/CLAUDE.md` | `repo/` | Quick reference + wiki links |
|
|
43
|
+
| Active task context | `wip/` | WIP files for Basecamp todos or GitHub issues |
|
|
44
|
+
| Dev secrets | `protected/` | API keys, tokens, test credentials |
|
|
41
45
|
|
|
42
|
-
Rule of thumb: if a `.md` file isn't built into the end product, it belongs in the wiki.
|
|
46
|
+
Rule of thumb: if a `.md` file isn't built into the end product, it belongs in the wiki. If it contains secrets or ephemeral task state, it belongs outside both git trees.
|
|
47
|
+
|
|
48
|
+
## WIP Directory
|
|
49
|
+
|
|
50
|
+
The `wip/` directory holds work-in-progress files that AI agents create when picking up tasks from Basecamp or GitHub issues. Each file tracks research, plans, and progress for an active task.
|
|
51
|
+
|
|
52
|
+
### Naming Convention
|
|
53
|
+
|
|
54
|
+
`{issue-number}-{short-description}.md` — e.g., `14-basecamp-mcp-auto-refresh-oauth.md`
|
|
55
|
+
|
|
56
|
+
### Lifecycle
|
|
57
|
+
|
|
58
|
+
1. Agent picks up a Basecamp todo or GitHub issue
|
|
59
|
+
2. Creates a WIP file with research findings and implementation plan
|
|
60
|
+
3. Updates the file as work progresses
|
|
61
|
+
4. File remains after completion as a record of decisions made
|
|
62
|
+
|
|
63
|
+
### What belongs in WIP
|
|
64
|
+
|
|
65
|
+
- Research findings and code analysis
|
|
66
|
+
- Detailed implementation plans
|
|
67
|
+
- Decision rationale
|
|
68
|
+
- Test results and verification notes
|
|
69
|
+
|
|
70
|
+
### What does NOT belong in WIP
|
|
71
|
+
|
|
72
|
+
- Secrets, credentials, or tokens (use `protected/`)
|
|
73
|
+
- Final documentation (use `wiki/`)
|
|
74
|
+
- Code (use `repo/`)
|
|
75
|
+
|
|
76
|
+
## Protected Directory
|
|
77
|
+
|
|
78
|
+
The `protected/` directory stores secrets and credentials needed during development and testing. It sits outside all git trees so nothing can be accidentally committed.
|
|
79
|
+
|
|
80
|
+
Examples: API keys, OAuth tokens, test credentials, `.env` files for local testing.
|
|
81
|
+
|
|
82
|
+
MUST NOT be committed to any git repository. MUST NOT be copied into `repo/` or `wiki/`.
|
|
43
83
|
|
|
44
84
|
## Referencing Wiki from Repo
|
|
45
85
|
|