@squawk/mcp 0.3.0 → 0.4.1
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 +43 -0
- package/dist/tools/flightplan.js +1 -1
- package/package.json +21 -21
package/README.md
CHANGED
|
@@ -87,6 +87,49 @@ Continue exposes MCP via its experimental config block. In `~/.continue/config.j
|
|
|
87
87
|
}
|
|
88
88
|
```
|
|
89
89
|
|
|
90
|
+
### Picking an install version
|
|
91
|
+
|
|
92
|
+
The snippets above pass the bare package name (`@squawk/mcp`), which lets `npx` pick whatever
|
|
93
|
+
version it finds first - usually a previously cached one. For predictable behavior, pin the
|
|
94
|
+
version explicitly in the client config:
|
|
95
|
+
|
|
96
|
+
```json
|
|
97
|
+
{
|
|
98
|
+
"mcpServers": {
|
|
99
|
+
"squawk": {
|
|
100
|
+
"command": "npx",
|
|
101
|
+
"args": ["-y", "@squawk/mcp@0.4.1"]
|
|
102
|
+
}
|
|
103
|
+
}
|
|
104
|
+
}
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
Bump the pinned version when a new release ships (see [npm](https://www.npmjs.com/package/@squawk/mcp)
|
|
108
|
+
for the latest). Pinning is the most reliable option because the resolved version is part of your
|
|
109
|
+
config and never depends on cache state.
|
|
110
|
+
|
|
111
|
+
If you would rather have the server auto-update on every Claude Desktop (or other host) restart,
|
|
112
|
+
use the `@latest` tag:
|
|
113
|
+
|
|
114
|
+
```json
|
|
115
|
+
{
|
|
116
|
+
"mcpServers": {
|
|
117
|
+
"squawk": {
|
|
118
|
+
"command": "npx",
|
|
119
|
+
"args": ["-y", "@squawk/mcp@latest"]
|
|
120
|
+
}
|
|
121
|
+
}
|
|
122
|
+
}
|
|
123
|
+
```
|
|
124
|
+
|
|
125
|
+
`@latest` instructs `npx` to consult the registry for the newest version on every spawn. There is a
|
|
126
|
+
caveat: the `npx` cache (under `~/.npm/_npx/`) can still hold an older version that satisfies the
|
|
127
|
+
resolved tag, in which case the cached copy is reused. If a newer release is published and the
|
|
128
|
+
server still serves the old behavior after a host restart, clear the cache directory and restart
|
|
129
|
+
again, or fall back to a pinned version. The host process itself also has to restart for any
|
|
130
|
+
update to take effect, since each MCP server is a long-running stdio subprocess that loads its
|
|
131
|
+
code once at spawn time.
|
|
132
|
+
|
|
90
133
|
### Pinning a specific Node binary
|
|
91
134
|
|
|
92
135
|
`npx` resolves `node` through whatever PATH the host launches with. On macOS, GUI apps often
|
package/dist/tools/flightplan.js
CHANGED
|
@@ -25,7 +25,7 @@ export function registerFlightplanTools(server) {
|
|
|
25
25
|
});
|
|
26
26
|
server.registerTool('parse_flightplan_route', {
|
|
27
27
|
title: 'Parse a flight plan route string',
|
|
28
|
-
description: 'Parses a whitespace-separated flight plan route string (e.g. "KJFK DCT MERIT J60 MARTN DCT KLAX") into structured route elements. Each token is classified as an airport, SID, STAR, airway, direct (DCT), waypoint, lat/lon coordinate, speed/altitude group, or unresolved. Airway tokens are expanded into waypoint sequences between the entry and exit fixes
|
|
28
|
+
description: 'Parses a whitespace-separated flight plan route string (e.g. "KJFK DCT MERIT J60 MARTN DCT KLAX") into structured route elements. Each token is classified as an airport, SID, STAR, airway, direct (DCT), waypoint, lat/lon coordinate, speed/altitude group, or unresolved. Airway tokens are expanded into waypoint sequences between the entry and exit fixes. SID/STAR tokens are expanded into their first common route, and the dotted PROCCODE.TRANSITION form (e.g. "NUBLE4.JJIMY") additionally merges the named transition\'s waypoints into the expansion.',
|
|
29
29
|
inputSchema: {
|
|
30
30
|
routeString: z
|
|
31
31
|
.string()
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@squawk/mcp",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.4.1",
|
|
4
4
|
"type": "module",
|
|
5
5
|
"description": "Model Context Protocol server exposing squawk's aviation libraries as tools for LLM clients",
|
|
6
6
|
"author": "Neil Cochran",
|
|
@@ -38,26 +38,26 @@
|
|
|
38
38
|
},
|
|
39
39
|
"dependencies": {
|
|
40
40
|
"@modelcontextprotocol/sdk": "^1.29.0",
|
|
41
|
-
"@squawk/airport-data": "
|
|
42
|
-
"@squawk/airports": "
|
|
43
|
-
"@squawk/airspace": "
|
|
44
|
-
"@squawk/airspace-data": "
|
|
45
|
-
"@squawk/airway-data": "
|
|
46
|
-
"@squawk/airways": "
|
|
47
|
-
"@squawk/fix-data": "
|
|
48
|
-
"@squawk/fixes": "
|
|
49
|
-
"@squawk/flight-math": "
|
|
50
|
-
"@squawk/flightplan": "
|
|
51
|
-
"@squawk/geo": "
|
|
52
|
-
"@squawk/icao-registry": "
|
|
53
|
-
"@squawk/icao-registry-data": "
|
|
54
|
-
"@squawk/navaid-data": "
|
|
55
|
-
"@squawk/navaids": "
|
|
56
|
-
"@squawk/notams": "
|
|
57
|
-
"@squawk/procedure-data": "
|
|
58
|
-
"@squawk/procedures": "
|
|
59
|
-
"@squawk/types": "
|
|
60
|
-
"@squawk/weather": "
|
|
41
|
+
"@squawk/airport-data": "^0.4.1",
|
|
42
|
+
"@squawk/airports": "^0.3.2",
|
|
43
|
+
"@squawk/airspace": "^0.4.1",
|
|
44
|
+
"@squawk/airspace-data": "^0.3.2",
|
|
45
|
+
"@squawk/airway-data": "^0.3.3",
|
|
46
|
+
"@squawk/airways": "^0.2.3",
|
|
47
|
+
"@squawk/fix-data": "^0.4.1",
|
|
48
|
+
"@squawk/fixes": "^0.1.4",
|
|
49
|
+
"@squawk/flight-math": "^0.5.1",
|
|
50
|
+
"@squawk/flightplan": "^0.3.3",
|
|
51
|
+
"@squawk/geo": "^0.2.1",
|
|
52
|
+
"@squawk/icao-registry": "^0.2.3",
|
|
53
|
+
"@squawk/icao-registry-data": "^0.3.3",
|
|
54
|
+
"@squawk/navaid-data": "^0.4.1",
|
|
55
|
+
"@squawk/navaids": "^0.2.4",
|
|
56
|
+
"@squawk/notams": "^0.2.3",
|
|
57
|
+
"@squawk/procedure-data": "^0.3.3",
|
|
58
|
+
"@squawk/procedures": "^0.2.4",
|
|
59
|
+
"@squawk/types": "^0.3.1",
|
|
60
|
+
"@squawk/weather": "^0.3.4",
|
|
61
61
|
"zod": "^4.3.6"
|
|
62
62
|
},
|
|
63
63
|
"devDependencies": {
|