@ekoindia/eps-context-mcp 0.1.0
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/README.md +171 -0
- package/data/eps.json +13867 -0
- package/dist/index.js +263 -0
- package/package.json +40 -0
package/README.md
ADDED
|
@@ -0,0 +1,171 @@
|
|
|
1
|
+
# @ekoindia/eps-context-mcp
|
|
2
|
+
|
|
3
|
+
A local, stdio [MCP](https://modelcontextprotocol.io) server that gives AI
|
|
4
|
+
coding agents accurate, up-to-date context for **Eko Platform Services (EPS)**
|
|
5
|
+
APIs — endpoints, request/response shapes, auth, errors, pricing, environments,
|
|
6
|
+
and multi-step integration recipes.
|
|
7
|
+
|
|
8
|
+
The full API bundle is **baked into the package** (works offline). No EPS
|
|
9
|
+
account or credentials are needed to run it. The server exposes a small set of
|
|
10
|
+
**tiered, lazy, secret-free** tools so an agent can list/search first and only
|
|
11
|
+
fetch full detail when it needs it.
|
|
12
|
+
|
|
13
|
+
## Install / run
|
|
14
|
+
|
|
15
|
+
No install step required — run it on demand with `npx`:
|
|
16
|
+
|
|
17
|
+
```bash
|
|
18
|
+
npx -y @ekoindia/eps-context-mcp
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
The server speaks MCP over **stdio**, so it is meant to be launched by an MCP
|
|
22
|
+
client (see per-harness config below) rather than run by hand. It logs its
|
|
23
|
+
status to **stderr** and waits for an MCP client on stdin/stdout.
|
|
24
|
+
|
|
25
|
+
Requires **Node.js ≥ 18**.
|
|
26
|
+
|
|
27
|
+
## Tools
|
|
28
|
+
|
|
29
|
+
All tools are read-only and **secret-free** — none of them accept an
|
|
30
|
+
`access_key` or any other credential.
|
|
31
|
+
|
|
32
|
+
| Tool | Arguments | Returns |
|
|
33
|
+
| --- | --- | --- |
|
|
34
|
+
| `list_apis` | `category?` | Compact index of EPS endpoints (no request/response bodies). Optional category filter. |
|
|
35
|
+
| `list_topics` | — | Documentation topic ids: `auth`, `errors`, `pricing`, `environments`. |
|
|
36
|
+
| `list_recipes` | — | Multi-step recipe ids + names (e.g. `dmt-send-money`, `aeps-cash-withdrawal`). |
|
|
37
|
+
| `search` | `query` | Ranked endpoint matches for a query (ids only, no bodies). |
|
|
38
|
+
| `get_api` | `slug` | Full detail for one endpoint (params, response fields, errors, examples). |
|
|
39
|
+
| `get_topic` | `topic` (`auth` \| `errors` \| `pricing` \| `environments`) | One documentation topic. |
|
|
40
|
+
| `get_recipe` | `id` | One multi-step recipe (steps + branches). |
|
|
41
|
+
| `get_signing_snippet` | `language` (`php` \| `java` \| `csharp` \| `javascript` \| `python` \| `go`) | Paste-ready **backend** code to compute the request `secret-key`. |
|
|
42
|
+
| `get_meta` | — | Bundle org/version + which data source is in use (`baked` or `remote`). |
|
|
43
|
+
|
|
44
|
+
**Tiered usage:** start with `list_apis` / `search` (cheap, compact), then call
|
|
45
|
+
`get_api` only for the endpoint(s) you actually need. Same pattern for
|
|
46
|
+
`list_topics` → `get_topic` and `list_recipes` → `get_recipe`.
|
|
47
|
+
|
|
48
|
+
## Client configuration
|
|
49
|
+
|
|
50
|
+
### Claude Code
|
|
51
|
+
|
|
52
|
+
```bash
|
|
53
|
+
claude mcp add eps -- npx -y @ekoindia/eps-context-mcp
|
|
54
|
+
```
|
|
55
|
+
|
|
56
|
+
Or add to your MCP config (`~/.claude.json` / project `.mcp.json`):
|
|
57
|
+
|
|
58
|
+
```json
|
|
59
|
+
{
|
|
60
|
+
"mcpServers": {
|
|
61
|
+
"eps": { "command": "npx", "args": ["-y", "@ekoindia/eps-context-mcp"] }
|
|
62
|
+
}
|
|
63
|
+
}
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
### Cursor
|
|
67
|
+
|
|
68
|
+
`~/.cursor/mcp.json` (or `.cursor/mcp.json` in a project):
|
|
69
|
+
|
|
70
|
+
```json
|
|
71
|
+
{
|
|
72
|
+
"mcpServers": {
|
|
73
|
+
"eps": { "command": "npx", "args": ["-y", "@ekoindia/eps-context-mcp"] }
|
|
74
|
+
}
|
|
75
|
+
}
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### opencode
|
|
79
|
+
|
|
80
|
+
`opencode.json`:
|
|
81
|
+
|
|
82
|
+
```json
|
|
83
|
+
{
|
|
84
|
+
"mcp": {
|
|
85
|
+
"eps": {
|
|
86
|
+
"type": "local",
|
|
87
|
+
"command": ["npx", "-y", "@ekoindia/eps-context-mcp"],
|
|
88
|
+
"enabled": true
|
|
89
|
+
}
|
|
90
|
+
}
|
|
91
|
+
}
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### Continue
|
|
95
|
+
|
|
96
|
+
`~/.continue/config.yaml`:
|
|
97
|
+
|
|
98
|
+
```yaml
|
|
99
|
+
mcpServers:
|
|
100
|
+
- name: eps
|
|
101
|
+
command: npx
|
|
102
|
+
args: ["-y", "@ekoindia/eps-context-mcp"]
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
### Codex CLI
|
|
106
|
+
|
|
107
|
+
`~/.codex/config.toml`:
|
|
108
|
+
|
|
109
|
+
```toml
|
|
110
|
+
[mcp_servers.eps]
|
|
111
|
+
command = "npx"
|
|
112
|
+
args = ["-y", "@ekoindia/eps-context-mcp"]
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
### Gemini CLI
|
|
116
|
+
|
|
117
|
+
`~/.gemini/settings.json`:
|
|
118
|
+
|
|
119
|
+
```json
|
|
120
|
+
{
|
|
121
|
+
"mcpServers": {
|
|
122
|
+
"eps": { "command": "npx", "args": ["-y", "@ekoindia/eps-context-mcp"] }
|
|
123
|
+
}
|
|
124
|
+
}
|
|
125
|
+
```
|
|
126
|
+
|
|
127
|
+
## Configuration
|
|
128
|
+
|
|
129
|
+
### `EPS_BUNDLE_URL` (optional)
|
|
130
|
+
|
|
131
|
+
By default the server serves the bundle baked into the package. To pull a fresh
|
|
132
|
+
bundle at startup (e.g. the latest generated `eps.json`), set `EPS_BUNDLE_URL`:
|
|
133
|
+
|
|
134
|
+
```json
|
|
135
|
+
{
|
|
136
|
+
"mcpServers": {
|
|
137
|
+
"eps": {
|
|
138
|
+
"command": "npx",
|
|
139
|
+
"args": ["-y", "@ekoindia/eps-context-mcp"],
|
|
140
|
+
"env": { "EPS_BUNDLE_URL": "https://eps.eko.in/agent/eps.json" }
|
|
141
|
+
}
|
|
142
|
+
}
|
|
143
|
+
}
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
If the fetch fails for any reason, the server transparently falls back to the
|
|
147
|
+
baked bundle. `get_meta` reports which source is in effect (`baked` or
|
|
148
|
+
`remote`).
|
|
149
|
+
|
|
150
|
+
## Security: backend-only signing
|
|
151
|
+
|
|
152
|
+
EPS requests are authenticated with a `secret-key` derived from your
|
|
153
|
+
`access_key` via HMAC-SHA256:
|
|
154
|
+
|
|
155
|
+
```
|
|
156
|
+
secret-key = base64( HMAC-SHA256( message = timestamp_ms, key = base64(access_key) ) )
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
The `get_signing_snippet` tool returns paste-ready code for this in six
|
|
160
|
+
languages. **This code is backend-only.**
|
|
161
|
+
|
|
162
|
+
- The `access_key` is a secret. It must live in your server-side secret store
|
|
163
|
+
(the snippets read it from `process.env` / `getenv`) and must **never** be
|
|
164
|
+
shipped to a browser or mobile client.
|
|
165
|
+
- The signing tool only emits an **algorithm template** — it never embeds a real
|
|
166
|
+
key. This MCP server holds **no credentials** and performs **no signing or API
|
|
167
|
+
calls** itself; it only provides context and code.
|
|
168
|
+
|
|
169
|
+
## License
|
|
170
|
+
|
|
171
|
+
MIT
|