@cyanheads/gdelt-mcp-server 0.2.2 → 0.2.3
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/CLAUDE.md +47 -36
- package/Dockerfile +10 -6
- package/LICENSE +201 -0
- package/README.md +1 -1
- package/changelog/0.2.x/0.2.3.md +44 -0
- package/changelog/template.md +5 -3
- package/dist/mcp-server/tools/date-range.d.ts +27 -0
- package/dist/mcp-server/tools/date-range.d.ts.map +1 -0
- package/dist/mcp-server/tools/date-range.js +29 -0
- package/dist/mcp-server/tools/date-range.js.map +1 -0
- package/dist/mcp-server/tools/definitions/get-coverage-breakdown.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/get-coverage-breakdown.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/get-coverage-breakdown.tool.js +22 -2
- package/dist/mcp-server/tools/definitions/get-coverage-breakdown.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/get-coverage-timeline.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/get-coverage-timeline.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/get-coverage-timeline.tool.js +22 -2
- package/dist/mcp-server/tools/definitions/get-coverage-timeline.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/get-tone-distribution.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/get-tone-distribution.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/get-tone-distribution.tool.js +22 -2
- package/dist/mcp-server/tools/definitions/get-tone-distribution.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/get-tv-clips.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/get-tv-clips.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/get-tv-clips.tool.js +25 -3
- package/dist/mcp-server/tools/definitions/get-tv-clips.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/get-tv-context.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/get-tv-context.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/get-tv-context.tool.js +25 -3
- package/dist/mcp-server/tools/definitions/get-tv-context.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/search-articles.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/search-articles.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/search-articles.tool.js +24 -4
- package/dist/mcp-server/tools/definitions/search-articles.tool.js.map +1 -1
- package/dist/mcp-server/tools/definitions/search-tv.tool.d.ts +10 -0
- package/dist/mcp-server/tools/definitions/search-tv.tool.d.ts.map +1 -1
- package/dist/mcp-server/tools/definitions/search-tv.tool.js +26 -5
- package/dist/mcp-server/tools/definitions/search-tv.tool.js.map +1 -1
- package/dist/services/gdelt/gdelt-fetch.d.ts +8 -0
- package/dist/services/gdelt/gdelt-fetch.d.ts.map +1 -1
- package/dist/services/gdelt/gdelt-fetch.js +64 -3
- package/dist/services/gdelt/gdelt-fetch.js.map +1 -1
- package/package.json +9 -7
- package/server.json +3 -3
package/CLAUDE.md
CHANGED
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
# Developer Protocol
|
|
2
2
|
|
|
3
3
|
**Server:** gdelt-mcp-server
|
|
4
|
-
**Version:** 0.2.
|
|
5
|
-
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.10.
|
|
4
|
+
**Version:** 0.2.3
|
|
5
|
+
**Framework:** [@cyanheads/mcp-ts-core](https://www.npmjs.com/package/@cyanheads/mcp-ts-core) `^0.10.14`
|
|
6
6
|
**Engines:** Bun ≥1.3.0, Node ≥24.0.0
|
|
7
7
|
**MCP SDK:** `@modelcontextprotocol/sdk` ^1.29.0
|
|
8
8
|
**Zod:** ^4.4.3
|
|
@@ -11,19 +11,6 @@
|
|
|
11
11
|
|
|
12
12
|
---
|
|
13
13
|
|
|
14
|
-
## First Session
|
|
15
|
-
|
|
16
|
-
This project was just scaffolded with `bunx @cyanheads/mcp-ts-core init`. The framework, skills, and example definitions are in place — the domain isn't. The user's first messages will set direction; wait for them before proceeding.
|
|
17
|
-
|
|
18
|
-
> **Remove this section** from CLAUDE.md / AGENTS.md after completing these steps. The skills and conventions below remain — this block is one-time onboarding only.
|
|
19
|
-
|
|
20
|
-
1. **Get your bearings.** Take stock of the project tree, the skills in `skills/`, and the tools/MCP servers available. Light tool use is fine for context-building — you're mapping the territory, not committing yet.
|
|
21
|
-
2. **Read the framework docs** — `node_modules/@cyanheads/mcp-ts-core/CLAUDE.md` (builders, Context, errors, exports, conventions)
|
|
22
|
-
3. **Run the `setup` skill** — read `skills/setup/SKILL.md` and follow its checklist (project orientation, agent protocol file selection, echo definition cleanup, skill sync)
|
|
23
|
-
4. **Design the server** — read `skills/design-mcp-server/SKILL.md` and work through it with the user to map the domain into tools, resources, and services before scaffolding
|
|
24
|
-
|
|
25
|
-
---
|
|
26
|
-
|
|
27
14
|
## What's Next?
|
|
28
15
|
|
|
29
16
|
When the user asks what's next or needs direction, suggest options based on the current project state. Common next steps:
|
|
@@ -48,7 +35,7 @@ Tailor suggestions to what's actually missing or stale — don't recite the full
|
|
|
48
35
|
- **Logic throws, framework catches.** Tool/resource handlers are pure — throw on failure, no `try/catch`. Plain `Error` is fine; the framework catches, classifies, and formats. Use error factories (`notFound()`, `validationError()`, etc.) when the error code matters.
|
|
49
36
|
- **Use `ctx.log`** for request-scoped logging. No `console` calls.
|
|
50
37
|
- **Use `ctx.state`** for tenant-scoped storage. Never access persistence directly.
|
|
51
|
-
- **Check `ctx.elicit
|
|
38
|
+
- **Check `ctx.elicit`** for presence before calling.
|
|
52
39
|
- **Secrets in env vars only** — never hardcoded.
|
|
53
40
|
- **Close the loop on issues.** When implementing work tracked by a GitHub issue, comment on the issue with what landed and close it. Do both — a comment without a close leaves stale issues open; a close without a comment leaves no record of what shipped. The comment is for future readers — state the concrete changes, not the conversation that produced them.
|
|
54
41
|
|
|
@@ -128,10 +115,6 @@ export const reviewCode = prompt('review_code', {
|
|
|
128
115
|
});
|
|
129
116
|
```
|
|
130
117
|
|
|
131
|
-
### Server instructions
|
|
132
|
-
|
|
133
|
-
`createApp({ instructions })` — optional server-level orientation, sent to clients on every `initialize` as session-level context. Use it for deployment guidance (connection aliases, regional notes, scope hints) instead of repeating the same context across tool descriptions. Client adoption is uneven, but there's no downside when set.
|
|
134
|
-
|
|
135
118
|
### Server config
|
|
136
119
|
|
|
137
120
|
```ts
|
|
@@ -142,6 +125,7 @@ import { parseEnvConfig } from '@cyanheads/mcp-ts-core/config';
|
|
|
142
125
|
const ServerConfigSchema = z.object({
|
|
143
126
|
apiKey: z.string().describe('External API key'),
|
|
144
127
|
maxResults: z.coerce.number().default(100),
|
|
128
|
+
verboseLogging: z.stringbool().default(false).describe('Enable verbose logging'),
|
|
145
129
|
});
|
|
146
130
|
|
|
147
131
|
let _config: z.infer<typeof ServerConfigSchema> | undefined;
|
|
@@ -149,6 +133,7 @@ export function getServerConfig() {
|
|
|
149
133
|
_config ??= parseEnvConfig(ServerConfigSchema, {
|
|
150
134
|
apiKey: 'MY_API_KEY',
|
|
151
135
|
maxResults: 'MY_MAX_RESULTS',
|
|
136
|
+
verboseLogging: 'MY_VERBOSE_LOGGING',
|
|
152
137
|
});
|
|
153
138
|
return _config;
|
|
154
139
|
}
|
|
@@ -156,6 +141,25 @@ export function getServerConfig() {
|
|
|
156
141
|
|
|
157
142
|
`parseEnvConfig` maps Zod schema paths → env var names so errors name the variable (`MY_API_KEY`) not the path (`apiKey`). Throws `ConfigurationError`, which the framework prints as a clean startup banner.
|
|
158
143
|
|
|
144
|
+
For env booleans use `z.stringbool()`, never `z.coerce.boolean()` — `Boolean("false")` is `true`, so a coerced flag can't be disabled through the environment. `z.stringbool()` parses `true/false/1/0/yes/no/on/off` and rejects anything else, so `=false` actually disables.
|
|
145
|
+
|
|
146
|
+
### Server identity and instructions
|
|
147
|
+
|
|
148
|
+
`createApp()` accepts optional identity fields forwarded to the SDK's `initialize` response and the server manifest (`/.well-known/mcp.json`):
|
|
149
|
+
|
|
150
|
+
```ts
|
|
151
|
+
await createApp({
|
|
152
|
+
name: 'my-mcp-server',
|
|
153
|
+
title: 'My Server', // human-readable display name
|
|
154
|
+
websiteUrl: 'https://github.com/owner/repo', // canonical homepage URL
|
|
155
|
+
description: 'One-line description.', // wins over MCP_SERVER_DESCRIPTION
|
|
156
|
+
icons: [{ src: 'https://example.com/icon.png', sizes: ['48x48'], mimeType: 'image/png' }],
|
|
157
|
+
instructions: 'Use shortcut alpha for the most common case.', // session-level context
|
|
158
|
+
});
|
|
159
|
+
```
|
|
160
|
+
|
|
161
|
+
`instructions` is optional server-level orientation, sent on every `initialize` as session-level context. Use it for deployment guidance (connection aliases, regional notes, scope hints) instead of repeating the same context across tool descriptions. Client adoption is uneven, but there's no downside when set.
|
|
162
|
+
|
|
159
163
|
---
|
|
160
164
|
|
|
161
165
|
## Context
|
|
@@ -165,13 +169,14 @@ Handlers receive a unified `ctx` object. Key properties:
|
|
|
165
169
|
| Property | Description |
|
|
166
170
|
|:---------|:------------|
|
|
167
171
|
| `ctx.log` | Request-scoped logger — `.debug()`, `.info()`, `.notice()`, `.warning()`, `.error()`. Auto-correlates requestId, traceId, tenantId. |
|
|
168
|
-
| `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
|
|
169
|
-
| `ctx.elicit` | Ask user for structured input. **Check for presence first:** `if (ctx.elicit) { ... }` |
|
|
170
|
-
| `ctx.
|
|
172
|
+
| `ctx.state` | Tenant-scoped KV — `.get(key)`, `.set(key, value, { ttl? })`, `.delete(key)`, `.getMany(keys)`, `.list(prefix, { cursor, limit })`. Accepts any serializable value. |
|
|
173
|
+
| `ctx.elicit` | Ask user for structured input — form call `(message, schema)` or `.url(message, url)` for an external link. **Check for presence first:** `if (ctx.elicit) { ... }` |
|
|
174
|
+
| `ctx.enrich` | Success-path agent context (empty-result notices, query echo, pagination totals) — `ctx.enrich(...)` or `.notice()` / `.total()` / `.echo()` / `.truncated()`. Reaches `structuredContent` and `content[]`; lands only when the definition declares an `enrichment` block (no-op otherwise). |
|
|
175
|
+
| `ctx.content` | Non-text content blocks — `.image(data, mimeType)`, `.audio(data, mimeType)`, or `ctx.content(block)` for a raw block. Prepended to `content[]` after `format()`; never enters `structuredContent`. |
|
|
171
176
|
| `ctx.signal` | `AbortSignal` for cancellation. |
|
|
172
177
|
| `ctx.progress` | Task progress (present when `task: true`) — `.setTotal(n)`, `.increment()`, `.update(message)`. |
|
|
173
178
|
| `ctx.requestId` | Unique request ID. |
|
|
174
|
-
| `ctx.tenantId` | Tenant ID from JWT
|
|
179
|
+
| `ctx.tenantId` | Tenant ID from JWT; `'default'` for stdio or HTTP with auth off. |
|
|
175
180
|
|
|
176
181
|
---
|
|
177
182
|
|
|
@@ -179,7 +184,7 @@ Handlers receive a unified `ctx` object. Key properties:
|
|
|
179
184
|
|
|
180
185
|
Handlers throw — the framework catches, classifies, and formats.
|
|
181
186
|
|
|
182
|
-
**Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required
|
|
187
|
+
**Recommended: typed error contract.** Declare `errors: [{ reason, code, when, recovery, retryable? }]` on `tool()` / `resource()` to receive `ctx.fail(reason, …)` typed against the reason union. TypeScript catches typos at compile time, `data.reason` is auto-populated for observability, linter enforces conformance against the handler body. `recovery` is required (≥ 5 words, lint-validated) — the single source of truth for the agent's next move. Pass `ctx.recoveryFor('reason')` as the throw's data to put it on the wire (`data.recovery.hint`, mirrored into `content[]` text); override with an explicit `{ recovery: { hint: '...' } }` when dynamic runtime context matters. Baseline codes (`InternalError`, `ServiceUnavailable`, `Timeout`, `ValidationError`, `SerializationError`) bubble freely and don't need declaring.
|
|
183
188
|
|
|
184
189
|
```ts
|
|
185
190
|
import { JsonRpcErrorCode } from '@cyanheads/mcp-ts-core/errors';
|
|
@@ -191,7 +196,7 @@ errors: [
|
|
|
191
196
|
],
|
|
192
197
|
async handler(input, ctx) {
|
|
193
198
|
const item = await db.find(input.id);
|
|
194
|
-
if (!item) throw ctx.fail('no_match', `No item ${input.id}
|
|
199
|
+
if (!item) throw ctx.fail('no_match', `No item ${input.id}`, ctx.recoveryFor('no_match'));
|
|
195
200
|
return item;
|
|
196
201
|
}
|
|
197
202
|
```
|
|
@@ -254,7 +259,7 @@ src/
|
|
|
254
259
|
|
|
255
260
|
## Skills
|
|
256
261
|
|
|
257
|
-
Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool.
|
|
262
|
+
Skills are modular instructions in `skills/` at the project root. Read them directly when a task matches — e.g., `skills/add-tool/SKILL.md` when adding a tool. `bun run list-skills` prints the full registry.
|
|
258
263
|
|
|
259
264
|
**Agent skill directory:** Copy skills into the directory your agent discovers (Claude Code: `.claude/skills/`, others: equivalent). Skills then load as context without referencing `skills/` paths. After framework updates, run the `maintenance` skill — Phase B re-syncs the agent directory.
|
|
260
265
|
|
|
@@ -274,7 +279,6 @@ Available skills:
|
|
|
274
279
|
| `tool-defs-analysis` | Read-only audit of MCP definition language across the surface — voice, leaks, defaults, recovery hints, output descriptions |
|
|
275
280
|
| `security-pass` | Audit server for MCP-flavored security gaps: output injection, scope blast radius, input sinks, tenant isolation |
|
|
276
281
|
| `code-simplifier` | Post-session cleanup against `git diff` — modernize syntax, consolidate duplication, align with the codebase |
|
|
277
|
-
| `devcheck` | Lint, format, typecheck, audit |
|
|
278
282
|
| `polish-docs-meta` | Finalize docs, README, metadata, and agent protocol for shipping |
|
|
279
283
|
| `git-wrapup` | Land working-tree changes as a versioned commit + annotated tag — version bump, changelog, verify, tag. Local only. |
|
|
280
284
|
| `release-and-publish` | Push + npm + MCP Registry + GH Release + Docker. Picks up from `git-wrapup` |
|
|
@@ -282,17 +286,18 @@ Available skills:
|
|
|
282
286
|
| `orchestrations` | Chain task skills into a gated multi-phase pipeline — build-out, QA-fix, update-ship — when you can spawn sub-agents |
|
|
283
287
|
| `report-issue-framework` | File a bug or feature request against `@cyanheads/mcp-ts-core` via `gh` CLI |
|
|
284
288
|
| `report-issue-local` | File a bug or feature request against this server's own repo via `gh` CLI |
|
|
289
|
+
| `techniques` | Catalog of response/data-shaping techniques — overflow handling, payload shaping, retrieval patterns |
|
|
285
290
|
| `api-auth` | Auth modes, scopes, JWT/OAuth |
|
|
286
291
|
| `api-canvas` | DataCanvas: register tabular data, run SQL, export, plus the `spillover()` helper for big result sets — Tier 3 opt-in |
|
|
287
292
|
| `api-config` | AppConfig, parseConfig, env vars |
|
|
288
293
|
| `api-context` | Context interface, logger, state, progress |
|
|
289
294
|
| `api-errors` | McpError, JsonRpcErrorCode, error patterns |
|
|
290
295
|
| `api-linter` | Definition linter rule catalog — invoked by `bun run lint:mcp` and `devcheck` |
|
|
296
|
+
| `api-mirror` | MirrorService: persistent self-refreshing local mirror (embedded SQLite + FTS5) of a bulk upstream dataset — Tier 3 opt-in |
|
|
291
297
|
| `api-services` | LLM, Speech, Graph services |
|
|
292
298
|
| `api-testing` | createMockContext, test patterns |
|
|
293
299
|
| `api-utils` | Formatting, parsing, security, pagination, scheduling, telemetry helpers |
|
|
294
300
|
| `api-telemetry` | OTel catalog: spans, metrics, completion logs, env config, cardinality rules |
|
|
295
|
-
| `api-mirror` | MirrorService: persistent SQLite-backed local mirror of bulk upstream datasets — `defineMirror()`, `sqliteMirrorStore()`, sync state machine, FTS5 |
|
|
296
301
|
| `api-workers` | Cloudflare Workers runtime |
|
|
297
302
|
|
|
298
303
|
**Chaining skills into pipelines.** When the user wants a multi-phase effort — build this server out, QA-and-fix the surface, update-and-ship — *and you can spawn sub-agents*, `skills/orchestrations/SKILL.md` sequences the task skills above into a gated pipeline with verification at each step. Read it to drive the run. Optional: skip it if you can't orchestrate sub-agents, and ignore it entirely if you were *spawned* as one — you've already been scoped to a single phase.
|
|
@@ -303,7 +308,7 @@ When you complete a skill's checklist, check the boxes and add a completion time
|
|
|
303
308
|
|
|
304
309
|
## Commands
|
|
305
310
|
|
|
306
|
-
**Runtime:** Scripts use
|
|
311
|
+
**Runtime:** Scripts use Bun's native TypeScript execution — `bun run <cmd>` is the standard invocation. `npm run <cmd>` also works (npm delegates to bun).
|
|
307
312
|
|
|
308
313
|
| Command | Purpose |
|
|
309
314
|
|:--------|:--------|
|
|
@@ -313,20 +318,24 @@ When you complete a skill's checklist, check the boxes and add a completion time
|
|
|
313
318
|
| `bun run devcheck` | Lint + format + typecheck + security + changelog sync |
|
|
314
319
|
| `bun run audit:refresh` | Delete `bun.lock`, reinstall, and re-run `bun audit`. Use when `devcheck` flags a transitive advisory — Bun's `update` is sticky on transitive resolutions, so the advisory may be a stale-lockfile false positive. If it survives the refresh, it's real. |
|
|
315
320
|
| `bun run tree` | Generate directory structure doc |
|
|
316
|
-
| `bun run
|
|
317
|
-
| `bun run
|
|
321
|
+
| `bun run lint:mcp` | Run the MCP definition linter standalone (rule catalog: `api-linter` skill) |
|
|
322
|
+
| `bun run lint:packaging` | Packaging surface checks — `server.json`/`manifest.json` env-var parity (run by devcheck) |
|
|
323
|
+
| `bun run list-skills` | Print the skill registry |
|
|
324
|
+
| `bun run format` | Auto-fix formatting (safe fixes only) |
|
|
325
|
+
| `bun run format:unsafe` | Also apply Biome's unsafe autofixes — review the diff; they can change behavior |
|
|
326
|
+
| `bun run test` | Run tests (Vitest — use `bun run test`, not `bun test`) |
|
|
318
327
|
| `bun run start:stdio` | Production mode (stdio) |
|
|
319
328
|
| `bun run start:http` | Production mode (HTTP) |
|
|
320
329
|
| `bun run changelog:build` | Regenerate `CHANGELOG.md` from `changelog/*.md` |
|
|
321
330
|
| `bun run changelog:check` | Verify `CHANGELOG.md` is in sync (used by devcheck) |
|
|
322
331
|
| `bun run release:github` | Create GitHub Release from current tag (title + optional .mcpb attach) |
|
|
323
|
-
| `bun run bundle` | Build and
|
|
332
|
+
| `bun run bundle` | Build, pack, and clean a `.mcpb` for one-click Claude Desktop install |
|
|
324
333
|
|
|
325
334
|
---
|
|
326
335
|
|
|
327
336
|
## Bundling
|
|
328
337
|
|
|
329
|
-
`npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
|
|
338
|
+
`npm run bundle` produces a `.mcpb` extension bundle for one-click install in Claude Desktop. The pack step is followed by `scripts/clean-mcpb.ts`, which prunes dev dependencies (`mcpb clean`) and strips dependency-shipped agent docs (`node_modules/**` `skills/`, `.claude/`, `.agents/`, `SKILL.md`) that root-anchored `.mcpbignore` patterns cannot reach. MCPB is stdio-only — HTTP and Cloudflare Workers deployments are unaffected. Consumers who don't need it can delete `manifest.json` and `.mcpbignore`; `lint:packaging` skips cleanly.
|
|
330
339
|
|
|
331
340
|
**Adding an env var requires both files:** `server.json` (registry discovery, `environmentVariables[]`) and `manifest.json` (bundle install UX, `mcp_config.env` + `user_config`). `lint:packaging` (run by `devcheck`) verifies the env var names match.
|
|
332
341
|
|
|
@@ -344,14 +353,16 @@ Each per-version file opens with YAML frontmatter:
|
|
|
344
353
|
---
|
|
345
354
|
summary: "One-line headline, ≤350 chars" # required — powers the rollup index
|
|
346
355
|
breaking: false # optional — true flags breaking changes
|
|
347
|
-
security: false # optional — true
|
|
356
|
+
security: false # optional — true ONLY for a source-code security fix, never a dependency CVE bump
|
|
348
357
|
---
|
|
349
358
|
|
|
350
359
|
# 0.1.0 — YYYY-MM-DD
|
|
351
360
|
...
|
|
352
361
|
```
|
|
353
362
|
|
|
354
|
-
`breaking: true` renders a `· ⚠️ Breaking` badge — use it when consumers must update code on upgrade (signature changes, removed APIs, config renames). `security: true` renders a `· 🛡️ Security` badge and pairs with a `## Security` body section. When both are set, badges render `· ⚠️ Breaking · 🛡️ Security`.
|
|
363
|
+
`breaking: true` renders a `· ⚠️ Breaking` badge — use it when consumers must update code on upgrade (signature changes, removed APIs, config renames). `security: true` renders a `· 🛡️ Security` badge and pairs with a `## Security` body section — set it only for a security fix in this server's *own source code*, never for a routine dependency or transitive CVE bump (record those under `## Dependencies`). When both are set, badges render `· ⚠️ Breaking · 🛡️ Security`.
|
|
364
|
+
|
|
365
|
+
`agent-notes` is an optional free-form field for maintenance agents processing the release downstream. Content here won't appear in the rendered CHANGELOG — it's consumed by agents running the `maintenance` skill. Use it for adoption instructions that don't fit the human-facing sections: new files to create, fields to populate, one-time migration steps. Omit entirely when there's nothing to say.
|
|
355
366
|
|
|
356
367
|
**Section order** (Keep a Changelog): Added, Changed, Deprecated, Removed, Fixed, Security. Include only sections with entries — don't ship empty headers.
|
|
357
368
|
|
package/Dockerfile
CHANGED
|
@@ -4,15 +4,17 @@
|
|
|
4
4
|
# This stage installs all dependencies (including dev), builds the TypeScript
|
|
5
5
|
# source code into JavaScript, and prepares the production assets.
|
|
6
6
|
# ==============================================================================
|
|
7
|
-
FROM oven/bun:1.3 AS build
|
|
7
|
+
FROM oven/bun:1.3.14 AS build
|
|
8
8
|
|
|
9
9
|
WORKDIR /usr/src/app
|
|
10
10
|
|
|
11
11
|
# Copy dependency manifests for optimized layer caching
|
|
12
12
|
COPY package.json bun.lock ./
|
|
13
13
|
|
|
14
|
-
# Install all dependencies (including dev dependencies for building)
|
|
15
|
-
|
|
14
|
+
# Install all dependencies (including dev dependencies for building).
|
|
15
|
+
# The BuildKit cache mount persists Bun's global package cache across builds.
|
|
16
|
+
RUN --mount=type=cache,target=/root/.bun/install/cache \
|
|
17
|
+
bun install --frozen-lockfile --ignore-scripts
|
|
16
18
|
|
|
17
19
|
# Copy the rest of the source code
|
|
18
20
|
COPY . .
|
|
@@ -30,7 +32,7 @@ RUN node_modules/.bin/tsc -p tsconfig.build.json && \
|
|
|
30
32
|
# application. It uses a slim base image and only includes production
|
|
31
33
|
# dependencies and build artifacts.
|
|
32
34
|
# ==============================================================================
|
|
33
|
-
FROM oven/bun:1.3-slim AS production
|
|
35
|
+
FROM oven/bun:1.3.14-slim AS production
|
|
34
36
|
|
|
35
37
|
WORKDIR /usr/src/app
|
|
36
38
|
|
|
@@ -51,13 +53,15 @@ COPY package.json bun.lock ./
|
|
|
51
53
|
|
|
52
54
|
# Install only production dependencies, ignoring any lifecycle scripts (like 'prepare')
|
|
53
55
|
# that are not needed in the final production image.
|
|
54
|
-
RUN bun
|
|
56
|
+
RUN --mount=type=cache,target=/root/.bun/install/cache \
|
|
57
|
+
bun install --production --frozen-lockfile --ignore-scripts
|
|
55
58
|
|
|
56
59
|
# Conditionally install OpenTelemetry optional peer dependencies (Tier 3).
|
|
57
60
|
# These are not bundled by default to keep the base image lean. Enable at build time
|
|
58
61
|
# with: docker build --build-arg OTEL_ENABLED=true
|
|
59
62
|
ARG OTEL_ENABLED=true
|
|
60
|
-
RUN
|
|
63
|
+
RUN --mount=type=cache,target=/root/.bun/install/cache \
|
|
64
|
+
if [ "$OTEL_ENABLED" = "true" ]; then \
|
|
61
65
|
bun add @hono/otel \
|
|
62
66
|
@opentelemetry/instrumentation-http \
|
|
63
67
|
@opentelemetry/exporter-metrics-otlp-http \
|
package/LICENSE
ADDED
|
@@ -0,0 +1,201 @@
|
|
|
1
|
+
Apache License
|
|
2
|
+
Version 2.0, January 2004
|
|
3
|
+
http://www.apache.org/licenses/
|
|
4
|
+
|
|
5
|
+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
|
|
6
|
+
|
|
7
|
+
1. Definitions.
|
|
8
|
+
|
|
9
|
+
"License" shall mean the terms and conditions for use, reproduction,
|
|
10
|
+
and distribution as defined by Sections 1 through 9 of this document.
|
|
11
|
+
|
|
12
|
+
"Licensor" shall mean the copyright owner or entity authorized by
|
|
13
|
+
the copyright owner that is granting the License.
|
|
14
|
+
|
|
15
|
+
"Legal Entity" shall mean the union of the acting entity and all
|
|
16
|
+
other entities that control, are controlled by, or are under common
|
|
17
|
+
control with that entity. For the purposes of this definition,
|
|
18
|
+
"control" means (i) the power, direct or indirect, to cause the
|
|
19
|
+
direction or management of such entity, whether by contract or
|
|
20
|
+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
|
|
21
|
+
outstanding shares, or (iii) beneficial ownership of such entity.
|
|
22
|
+
|
|
23
|
+
"You" (or "Your") shall mean an individual or Legal Entity
|
|
24
|
+
exercising permissions granted by this License.
|
|
25
|
+
|
|
26
|
+
"Source" form shall mean the preferred form for making modifications,
|
|
27
|
+
including but not limited to software source code, documentation
|
|
28
|
+
source, and configuration files.
|
|
29
|
+
|
|
30
|
+
"Object" form shall mean any form resulting from mechanical
|
|
31
|
+
transformation or translation of a Source form, including but
|
|
32
|
+
not limited to compiled object code, generated documentation,
|
|
33
|
+
and conversions to other media types.
|
|
34
|
+
|
|
35
|
+
"Work" shall mean the work of authorship, whether in Source or
|
|
36
|
+
Object form, made available under the License, as indicated by a
|
|
37
|
+
copyright notice that is included in or attached to the work
|
|
38
|
+
(an example is provided in the Appendix below).
|
|
39
|
+
|
|
40
|
+
"Derivative Works" shall mean any work, whether in Source or Object
|
|
41
|
+
form, that is based on (or derived from) the Work and for which the
|
|
42
|
+
editorial revisions, annotations, elaborations, or other modifications
|
|
43
|
+
represent, as a whole, an original work of authorship. For the purposes
|
|
44
|
+
of this License, Derivative Works shall not include works that remain
|
|
45
|
+
separable from, or merely link (or bind by name) to the interfaces of,
|
|
46
|
+
the Work and Derivative Works thereof.
|
|
47
|
+
|
|
48
|
+
"Contribution" shall mean any work of authorship, including
|
|
49
|
+
the original version of the Work and any modifications or additions
|
|
50
|
+
to that Work or Derivative Works thereof, that is intentionally
|
|
51
|
+
submitted to Licensor for inclusion in the Work by the copyright owner
|
|
52
|
+
or by an individual or Legal Entity authorized to submit on behalf of
|
|
53
|
+
the copyright owner. For the purposes of this definition, "submitted"
|
|
54
|
+
means any form of electronic, verbal, or written communication sent
|
|
55
|
+
to the Licensor or its representatives, including but not limited to
|
|
56
|
+
communication on electronic mailing lists, source code control systems,
|
|
57
|
+
and issue tracking systems that are managed by, or on behalf of, the
|
|
58
|
+
Licensor for the purpose of discussing and improving the Work, but
|
|
59
|
+
excluding communication that is conspicuously marked or otherwise
|
|
60
|
+
designated in writing by the copyright owner as "Not a Contribution."
|
|
61
|
+
|
|
62
|
+
"Contributor" shall mean Licensor and any individual or Legal Entity
|
|
63
|
+
on behalf of whom a Contribution has been received by Licensor and
|
|
64
|
+
subsequently incorporated within the Work.
|
|
65
|
+
|
|
66
|
+
2. Grant of Copyright License. Subject to the terms and conditions of
|
|
67
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
68
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
69
|
+
copyright license to reproduce, prepare Derivative Works of,
|
|
70
|
+
publicly display, publicly perform, sublicense, and distribute the
|
|
71
|
+
Work and such Derivative Works in Source or Object form.
|
|
72
|
+
|
|
73
|
+
3. Grant of Patent License. Subject to the terms and conditions of
|
|
74
|
+
this License, each Contributor hereby grants to You a perpetual,
|
|
75
|
+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
|
|
76
|
+
(except as stated in this section) patent license to make, have made,
|
|
77
|
+
use, offer to sell, sell, import, and otherwise transfer the Work,
|
|
78
|
+
where such license applies only to those patent claims licensable
|
|
79
|
+
by such Contributor that are necessarily infringed by their
|
|
80
|
+
Contribution(s) alone or by combination of their Contribution(s)
|
|
81
|
+
with the Work to which such Contribution(s) was submitted. If You
|
|
82
|
+
institute patent litigation against any entity (including a
|
|
83
|
+
cross-claim or counterclaim in a lawsuit) alleging that the Work
|
|
84
|
+
or a Contribution incorporated within the Work constitutes direct
|
|
85
|
+
or contributory patent infringement, then any patent licenses
|
|
86
|
+
granted to You under this License for that Work shall terminate
|
|
87
|
+
as of the date such litigation is filed.
|
|
88
|
+
|
|
89
|
+
4. Redistribution. You may reproduce and distribute copies of the
|
|
90
|
+
Work or Derivative Works thereof in any medium, with or without
|
|
91
|
+
modifications, and in Source or Object form, provided that You
|
|
92
|
+
meet the following conditions:
|
|
93
|
+
|
|
94
|
+
(a) You must give any other recipients of the Work or
|
|
95
|
+
Derivative Works a copy of this License; and
|
|
96
|
+
|
|
97
|
+
(b) You must cause any modified files to carry prominent notices
|
|
98
|
+
stating that You changed the files; and
|
|
99
|
+
|
|
100
|
+
(c) You must retain, in the Source form of any Derivative Works
|
|
101
|
+
that You distribute, all copyright, patent, trademark, and
|
|
102
|
+
attribution notices from the Source form of the Work,
|
|
103
|
+
excluding those notices that do not pertain to any part of
|
|
104
|
+
the Derivative Works; and
|
|
105
|
+
|
|
106
|
+
(d) If the Work includes a "NOTICE" text file as part of its
|
|
107
|
+
distribution, then any Derivative Works that You distribute must
|
|
108
|
+
include a readable copy of the attribution notices contained
|
|
109
|
+
within such NOTICE file, excluding those notices that do not
|
|
110
|
+
pertain to any part of the Derivative Works, in at least one
|
|
111
|
+
of the following places: within a NOTICE text file distributed
|
|
112
|
+
as part of the Derivative Works; within the Source form or
|
|
113
|
+
documentation, if provided along with the Derivative Works; or,
|
|
114
|
+
within a display generated by the Derivative Works, if and
|
|
115
|
+
wherever such third-party notices normally appear. The contents
|
|
116
|
+
of the NOTICE file are for informational purposes only and
|
|
117
|
+
do not modify the License. You may add Your own attribution
|
|
118
|
+
notices within Derivative Works that You distribute, alongside
|
|
119
|
+
or as an addendum to the NOTICE text from the Work, provided
|
|
120
|
+
that such additional attribution notices cannot be construed
|
|
121
|
+
as modifying the License.
|
|
122
|
+
|
|
123
|
+
You may add Your own copyright statement to Your modifications and
|
|
124
|
+
may provide additional or different license terms and conditions
|
|
125
|
+
for use, reproduction, or distribution of Your modifications, or
|
|
126
|
+
for any such Derivative Works as a whole, provided Your use,
|
|
127
|
+
reproduction, and distribution of the Work otherwise complies with
|
|
128
|
+
the conditions stated in this License.
|
|
129
|
+
|
|
130
|
+
5. Submission of Contributions. Unless You explicitly state otherwise,
|
|
131
|
+
any Contribution intentionally submitted for inclusion in the Work
|
|
132
|
+
by You to the Licensor shall be under the terms and conditions of
|
|
133
|
+
this License, without any additional terms or conditions.
|
|
134
|
+
Notwithstanding the above, nothing herein shall supersede or modify
|
|
135
|
+
the terms of any separate license agreement you may have executed
|
|
136
|
+
with Licensor regarding such Contributions.
|
|
137
|
+
|
|
138
|
+
6. Trademarks. This License does not grant permission to use the trade
|
|
139
|
+
names, trademarks, service marks, or product names of the Licensor,
|
|
140
|
+
except as required for reasonable and customary use in describing the
|
|
141
|
+
origin of the Work and reproducing the content of the NOTICE file.
|
|
142
|
+
|
|
143
|
+
7. Disclaimer of Warranty. Unless required by applicable law or
|
|
144
|
+
agreed to in writing, Licensor provides the Work (and each
|
|
145
|
+
Contributor provides its Contributions) on an "AS IS" BASIS,
|
|
146
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
|
|
147
|
+
implied, including, without limitation, any warranties or conditions
|
|
148
|
+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
|
|
149
|
+
PARTICULAR PURPOSE. You are solely responsible for determining the
|
|
150
|
+
appropriateness of using or redistributing the Work and assume any
|
|
151
|
+
risks associated with Your exercise of permissions under this License.
|
|
152
|
+
|
|
153
|
+
8. Limitation of Liability. In no event and under no legal theory,
|
|
154
|
+
whether in tort (including negligence), contract, or otherwise,
|
|
155
|
+
unless required by applicable law (such as deliberate and grossly
|
|
156
|
+
negligent acts) or agreed to in writing, shall any Contributor be
|
|
157
|
+
liable to You for damages, including any direct, indirect, special,
|
|
158
|
+
incidental, or consequential damages of any character arising as a
|
|
159
|
+
result of this License or out of the use or inability to use the
|
|
160
|
+
Work (including but not limited to damages for loss of goodwill,
|
|
161
|
+
work stoppage, computer failure or malfunction, or any and all
|
|
162
|
+
other commercial damages or losses), even if such Contributor
|
|
163
|
+
has been advised of the possibility of such damages.
|
|
164
|
+
|
|
165
|
+
9. Accepting Warranty or Additional Liability. While redistributing
|
|
166
|
+
the Work or Derivative Works thereof, You may choose to offer,
|
|
167
|
+
and charge a fee for, acceptance of support, warranty, indemnity,
|
|
168
|
+
or other liability obligations and/or rights consistent with this
|
|
169
|
+
License. However, in accepting such obligations, You may act only
|
|
170
|
+
on Your own behalf and on Your sole responsibility, not on behalf
|
|
171
|
+
of any other Contributor, and only if You agree to indemnify,
|
|
172
|
+
defend, and hold each Contributor harmless for any liability
|
|
173
|
+
incurred by, or claims asserted against, such Contributor by reason
|
|
174
|
+
of your accepting any such warranty or additional liability.
|
|
175
|
+
|
|
176
|
+
END OF TERMS AND CONDITIONS
|
|
177
|
+
|
|
178
|
+
APPENDIX: How to apply the Apache License to your work.
|
|
179
|
+
|
|
180
|
+
To apply the Apache License to your work, attach the following
|
|
181
|
+
boilerplate notice, with the fields enclosed by brackets "[]"
|
|
182
|
+
replaced with your own identifying information. (Don't include
|
|
183
|
+
the brackets!) The text should be enclosed in the appropriate
|
|
184
|
+
comment syntax for the file format. We also recommend that a
|
|
185
|
+
file or class name and description of purpose be included on the
|
|
186
|
+
same "printed page" as the copyright notice for easier
|
|
187
|
+
identification within third-party archives.
|
|
188
|
+
|
|
189
|
+
Copyright 2026 Casey Hand @cyanheads
|
|
190
|
+
|
|
191
|
+
Licensed under the Apache License, Version 2.0 (the "License");
|
|
192
|
+
you may not use this file except in compliance with the License.
|
|
193
|
+
You may obtain a copy of the License at
|
|
194
|
+
|
|
195
|
+
http://www.apache.org/licenses/LICENSE-2.0
|
|
196
|
+
|
|
197
|
+
Unless required by applicable law or agreed to in writing, software
|
|
198
|
+
distributed under the License is distributed on an "AS IS" BASIS,
|
|
199
|
+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
200
|
+
See the License for the specific language governing permissions and
|
|
201
|
+
limitations under the License.
|
package/README.md
CHANGED
|
@@ -7,7 +7,7 @@
|
|
|
7
7
|
|
|
8
8
|
<div align="center">
|
|
9
9
|
|
|
10
|
-
[](./CHANGELOG.md) [](./LICENSE) [](https://github.com/users/cyanheads/packages/container/package/gdelt-mcp-server) [](https://modelcontextprotocol.io/) [](https://www.npmjs.com/package/@cyanheads/gdelt-mcp-server) [](https://www.typescriptlang.org/) [](https://bun.sh/)
|
|
11
11
|
|
|
12
12
|
</div>
|
|
13
13
|
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
summary: "Fixed: unpaired date-range boundaries silently ignored (#22) and confusing GDELT query-rejection errors (#18); mcp-ts-core ^0.10.9 → ^0.10.14 clears 8 transitive advisories; new install-time supply-chain guard"
|
|
3
|
+
breaking: false
|
|
4
|
+
security: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# 0.2.3 — 2026-07-15
|
|
8
|
+
|
|
9
|
+
## Added
|
|
10
|
+
|
|
11
|
+
- **Supply-chain install guard** — `bunfig.toml` sets `minimumReleaseAge = 259200` (3 days), blocking freshly published package versions at install time (`@cyanheads/mcp-ts-core` is excluded via `minimumReleaseAgeExcludes`, adopted same-day). `[install.security].scanner` wires in `@socketsecurity/bun-security-scanner` for pre-install malware/typosquat/CVE scanning.
|
|
12
|
+
|
|
13
|
+
## Changed
|
|
14
|
+
|
|
15
|
+
- **`@cyanheads/mcp-ts-core`** `^0.10.9` → `^0.10.14`, with vendored `skills/` and `scripts/*.ts` re-synced to match.
|
|
16
|
+
- **`scripts/devcheck.ts`** — the Outdated check no longer flags a row held back solely by `minimumReleaseAge` (`Update` == `Current`, marked `*` by `bun outdated`); a genuine available update still fails the check.
|
|
17
|
+
- **`devcheck.config.json`** — `outdated.allowlist` now holds `typescript` (major-version hold against 7.0.2, outside the `^6` range) in place of the framework package.
|
|
18
|
+
- **`Dockerfile`** — pins `oven/bun:1.3.14` (was floating `1.3`/`1.3-slim`), adds a BuildKit cache mount for the Bun install cache, and passes `--ignore-scripts` on the build-stage install.
|
|
19
|
+
|
|
20
|
+
## Fixed
|
|
21
|
+
|
|
22
|
+
- **`gdelt_search_articles`, `gdelt_get_coverage_timeline`, `gdelt_get_tone_distribution`, `gdelt_get_coverage_breakdown`, `gdelt_search_tv`, `gdelt_get_tv_clips`, `gdelt_get_tv_context`** — a lone `startDatetime` or `endDatetime` was silently dropped, running the query against GDELT's default window instead of the requested one ([#22](https://github.com/cyanheads/gdelt-mcp-server/issues/22)). Both fields now carry a `.regex()` format constraint via a new shared `src/mcp-server/tools/date-range.ts` module (`GDELT_DATETIME_PATTERN`, serialized into the advertised JSON Schema as `pattern` — a malformed value is rejected by the SDK as `InvalidParams`/-32602), and every handler rejects an unpaired boundary via a new `invalid_date_range` `ValidationError`/-32007 reason (`isUnpairedDateRange`) before the service call runs.
|
|
23
|
+
- **Same seven tools** — GDELT's HTTP-200 plain-text query rejections (no TV station selected, keyword too short/long, unbalanced parenthesis, illegal character) surfaced as a generic `SerializationError` ("unparseable response") instead of an actionable error ([#18](https://github.com/cyanheads/gdelt-mcp-server/issues/18)). `parseGdeltJson` (now exported for direct testing) matches the known rejection bodies and throws a new `invalid_query` `ValidationError`/-32007 reason with a hint tailored to what GDELT rejected.
|
|
24
|
+
- **`stations` field description** on `gdelt_search_tv`, `gdelt_get_tv_clips`, `gdelt_get_tv_context` — corrected; omitting `stations` is rejected by the GDELT TV API, it does not fall back to "all stations" as previously described.
|
|
25
|
+
|
|
26
|
+
## Dependencies
|
|
27
|
+
|
|
28
|
+
Clears 8 transitive advisories from this release's dependency refresh (2 high, 6 moderate) — `bun audit` is clean.
|
|
29
|
+
|
|
30
|
+
- **`hono`** `4.12.26` → `4.12.28`, **`js-yaml`** `3.14.2` → `3.15.0` — pulled in by the `@cyanheads/mcp-ts-core` bump above.
|
|
31
|
+
- High: [GHSA-88fw-hqm2-52qc](https://github.com/advisories/GHSA-88fw-hqm2-52qc) — hono CORS middleware reflects any Origin with credentials when `origin` defaults to the wildcard.
|
|
32
|
+
- Moderate: [GHSA-wwfh-h76j-fc44](https://github.com/advisories/GHSA-wwfh-h76j-fc44) hono `serve-static` Windows path traversal, [GHSA-j6c9-x7qj-28xf](https://github.com/advisories/GHSA-j6c9-x7qj-28xf) hono Lambda `Set-Cookie` merge, [GHSA-rv63-4mwf-qqc2](https://github.com/advisories/GHSA-rv63-4mwf-qqc2) hono Lambda body-limit bypass, [GHSA-wgpf-jwqj-8h8p](https://github.com/advisories/GHSA-wgpf-jwqj-8h8p) hono Lambda@Edge header drop, [GHSA-h67p-54hq-rp68](https://github.com/advisories/GHSA-h67p-54hq-rp68) js-yaml quadratic-complexity DoS.
|
|
33
|
+
- **`vite`** `8.0.14` → `8.1.4` — pulled in by the `vitest` `^4.1.9` → `^4.1.10` bump below.
|
|
34
|
+
- High: [GHSA-fx2h-pf6j-xcff](https://github.com/advisories/GHSA-fx2h-pf6j-xcff) — `server.fs.deny` bypass on Windows alternate paths.
|
|
35
|
+
- Moderate: [GHSA-v6wh-96g9-6wx3](https://github.com/advisories/GHSA-v6wh-96g9-6wx3) — `launch-editor` NTLMv2 hash disclosure via UNC path handling on Windows.
|
|
36
|
+
|
|
37
|
+
### Dependency bumps
|
|
38
|
+
|
|
39
|
+
- `@cyanheads/mcp-ts-core` `^0.10.9` → `^0.10.14`
|
|
40
|
+
- `@socketsecurity/bun-security-scanner` added, `^1.1.2`
|
|
41
|
+
- `@types/node` `^26.0.0` → `^26.1.1`
|
|
42
|
+
- `ignore` `^7.0.5` → `^7.0.6`
|
|
43
|
+
- `tsc-alias` `^1.8.17` → `^1.9.0`
|
|
44
|
+
- `vitest` `^4.1.9` → `^4.1.10`
|
package/changelog/template.md
CHANGED
|
@@ -15,9 +15,11 @@ summary: ""
|
|
|
15
15
|
# usage. Flagged as `Breaking` in the rollup.
|
|
16
16
|
breaking: false
|
|
17
17
|
|
|
18
|
-
# Set `true`
|
|
19
|
-
#
|
|
20
|
-
#
|
|
18
|
+
# Set `true` ONLY for a security fix in THIS project's own source code — a
|
|
19
|
+
# vulnerability or hardening in code you ship. A dependency or transitive CVE
|
|
20
|
+
# bump is routine maintenance, NOT a security release: record it under
|
|
21
|
+
# `## Dependencies` (with the advisory ID) and leave this `false`. When true,
|
|
22
|
+
# pairs with the `## Security` section below and flags `Security` in the rollup.
|
|
21
23
|
security: false
|
|
22
24
|
|
|
23
25
|
# Optional free-form notes for maintenance agents processing this release.
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* @fileoverview Shared date-range input constraints for the GDELT tools that accept
|
|
3
|
+
* an explicit startDatetime/endDatetime window — the YYYYMMDDHHMMSS field pattern
|
|
4
|
+
* and the both-or-neither pairing predicate.
|
|
5
|
+
* @module mcp-server/tools/date-range
|
|
6
|
+
*/
|
|
7
|
+
/**
|
|
8
|
+
* GDELT's datetime wire format: exactly 14 digits, YYYYMMDDHHMMSS, no separators.
|
|
9
|
+
*
|
|
10
|
+
* Applied as a field-level Zod `.regex()` so it serializes into the advertised JSON
|
|
11
|
+
* Schema as `pattern`, letting a caller see the constraint before it calls.
|
|
12
|
+
*/
|
|
13
|
+
export declare const GDELT_DATETIME_PATTERN: RegExp;
|
|
14
|
+
/**
|
|
15
|
+
* True when exactly one of the two boundaries is present.
|
|
16
|
+
*
|
|
17
|
+
* GDELT honors an explicit date range only when both boundaries are set, so a lone
|
|
18
|
+
* boundary is dropped during URL construction and the query silently runs against a
|
|
19
|
+
* different window than the caller asked for.
|
|
20
|
+
*
|
|
21
|
+
* The rule is cross-field, so each tool handler enforces it rather than a Zod
|
|
22
|
+
* object-level refinement: a schema-level rejection is raised before the handler runs,
|
|
23
|
+
* which returns a raw Zod issue dump with no `structuredContent` — dropping the
|
|
24
|
+
* `reason` + `recovery.hint` contract every other error path on these tools carries.
|
|
25
|
+
*/
|
|
26
|
+
export declare function isUnpairedDateRange(startDatetime?: string, endDatetime?: string): boolean;
|
|
27
|
+
//# sourceMappingURL=date-range.d.ts.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"date-range.d.ts","sourceRoot":"","sources":["../../../src/mcp-server/tools/date-range.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH;;;;;GAKG;AACH,eAAO,MAAM,sBAAsB,QAAa,CAAC;AAEjD;;;;;;;;;;;GAWG;AACH,wBAAgB,mBAAmB,CAAC,aAAa,CAAC,EAAE,MAAM,EAAE,WAAW,CAAC,EAAE,MAAM,GAAG,OAAO,CAEzF"}
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
/**
|
|
2
|
+
* @fileoverview Shared date-range input constraints for the GDELT tools that accept
|
|
3
|
+
* an explicit startDatetime/endDatetime window — the YYYYMMDDHHMMSS field pattern
|
|
4
|
+
* and the both-or-neither pairing predicate.
|
|
5
|
+
* @module mcp-server/tools/date-range
|
|
6
|
+
*/
|
|
7
|
+
/**
|
|
8
|
+
* GDELT's datetime wire format: exactly 14 digits, YYYYMMDDHHMMSS, no separators.
|
|
9
|
+
*
|
|
10
|
+
* Applied as a field-level Zod `.regex()` so it serializes into the advertised JSON
|
|
11
|
+
* Schema as `pattern`, letting a caller see the constraint before it calls.
|
|
12
|
+
*/
|
|
13
|
+
export const GDELT_DATETIME_PATTERN = /^\d{14}$/;
|
|
14
|
+
/**
|
|
15
|
+
* True when exactly one of the two boundaries is present.
|
|
16
|
+
*
|
|
17
|
+
* GDELT honors an explicit date range only when both boundaries are set, so a lone
|
|
18
|
+
* boundary is dropped during URL construction and the query silently runs against a
|
|
19
|
+
* different window than the caller asked for.
|
|
20
|
+
*
|
|
21
|
+
* The rule is cross-field, so each tool handler enforces it rather than a Zod
|
|
22
|
+
* object-level refinement: a schema-level rejection is raised before the handler runs,
|
|
23
|
+
* which returns a raw Zod issue dump with no `structuredContent` — dropping the
|
|
24
|
+
* `reason` + `recovery.hint` contract every other error path on these tools carries.
|
|
25
|
+
*/
|
|
26
|
+
export function isUnpairedDateRange(startDatetime, endDatetime) {
|
|
27
|
+
return Boolean(startDatetime) !== Boolean(endDatetime);
|
|
28
|
+
}
|
|
29
|
+
//# sourceMappingURL=date-range.js.map
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
{"version":3,"file":"date-range.js","sourceRoot":"","sources":["../../../src/mcp-server/tools/date-range.ts"],"names":[],"mappings":"AAAA;;;;;GAKG;AAEH;;;;;GAKG;AACH,MAAM,CAAC,MAAM,sBAAsB,GAAG,UAAU,CAAC;AAEjD;;;;;;;;;;;GAWG;AACH,MAAM,UAAU,mBAAmB,CAAC,aAAsB,EAAE,WAAoB;IAC9E,OAAO,OAAO,CAAC,aAAa,CAAC,KAAK,OAAO,CAAC,WAAW,CAAC,CAAC;AACzD,CAAC"}
|
|
@@ -35,6 +35,16 @@ export declare const gdeltGetCoverageBreakdown: import("@cyanheads/mcp-ts-core")
|
|
|
35
35
|
readonly code: JsonRpcErrorCode.NotFound;
|
|
36
36
|
readonly when: "No breakdown data returned for the query.";
|
|
37
37
|
readonly recovery: "Broaden the query, extend the timespan, or verify the query operators are correct.";
|
|
38
|
+
}, {
|
|
39
|
+
readonly reason: "invalid_date_range";
|
|
40
|
+
readonly code: JsonRpcErrorCode.ValidationError;
|
|
41
|
+
readonly when: "Exactly one of startDatetime / endDatetime was supplied.";
|
|
42
|
+
readonly recovery: "Supply both startDatetime and endDatetime to pin an explicit window, or omit both and use timespan instead.";
|
|
43
|
+
}, {
|
|
44
|
+
readonly reason: "invalid_query";
|
|
45
|
+
readonly code: JsonRpcErrorCode.ValidationError;
|
|
46
|
+
readonly when: "GDELT rejected the query string as malformed — bad keyword length, unbalanced parentheses, or an illegal character.";
|
|
47
|
+
readonly recovery: "Read the recovery hint for the specific rule GDELT rejected, then fix the query and retry.";
|
|
38
48
|
}, {
|
|
39
49
|
readonly reason: "gdelt_unavailable";
|
|
40
50
|
readonly code: JsonRpcErrorCode.ServiceUnavailable;
|