offnadir-delta-mcp 1.11.1 → 1.12.0

package/README.md

@@ -16,7 +16,7 @@ satellite can actually resolve it, and produce a collection-ready plan.
 Real-time event and geospatial intelligence for OSINT, geopolitical risk, and GEOINT work —
 source-linked, geolocated, and current, not a training snapshot.
 
-`24` tools · MCP server version `1.11.1` · [full reference](https://offnadir-delta.com/docs/mcp)
+`25` tools · MCP server version `1.12.0` · [full reference](https://offnadir-delta.com/docs/mcp)
 
 ## What it does
 
@@ -77,7 +77,7 @@ locally from a generated catalog, so registries can introspect it without creden
 
 ### First call — free
 
-12 of the 24 tools cost nothing, so the first thing you run is free:
+12 of the 25 tools cost nothing, so the first thing you run is free:
 
 > Give me the latest Daily World Brief. Lead with the three most significant developments,
 > explain why each matters, and cite the supporting signals.
@@ -124,6 +124,7 @@ Turn reporting into a cited assessment you can audit afterwards.
 | `ask_analyst` | Ask the Delta Analyst an OSINT/GEOINT question. | 5–123 tok |
 | `get_analyst_job` | Fetch the status and result of an ask_analyst run by job_id. | free |
 | `query_claims` | Read the LEDGER of claims this key has been given — every factual assertion the Analyst made, with its evidence class (CONFIRMED / REPORTED / PARTY_CLAIM / ASSESSMENT), how many INDEPENDENT source families backed it, and the publishers. | free |
+| `refine_location` | Research one signal's location further and, if the sources genuinely narrow it, store and return the better coordinate. | 3–29 tok |
 | `measure_index_series` | Measure a spectral index over an area, scene by scene, back through the Sentinel-2 archive — the answer to "how has this changed since <year>". | 0.5 tok |
 | `detect_ships` | Count vessel-like targets in ONE SAR scene over an area, using CFAR detection on Sentinel-1. | 5 tok |
 

package/dist/catalog.js

@@ -13,7 +13,7 @@
  * Actual `tools/call` / `resources/read` / `prompts/get` requests are forwarded
  * to the remote server with the caller's OFFNADIR_DELTA_API_KEY (see index.ts).
  */
-// Generated for Off-Nadir Delta MCP 1.11.1.
+// Generated for Off-Nadir Delta MCP 1.12.0.
 export const TOOLS = [
     {
         "name": "query_signals",
@@ -1671,6 +1671,43 @@ export const TOOLS = [
             "destructiveHint": false
         }
     },
+    {
+        "name": "refine_location",
+        "description": "Research one signal's location further and, if the sources genuinely narrow it, store and return the better coordinate. Most signals are geolocated once, for free, from a single article's place string: measured across production, about two thirds sit at ±5 km or have no bounded radius at all. This reads the source article and live search for a source that names something finer — a facility, bridge, district, port — resolves it, and verifies it before accepting it. **You are charged only if the precision actually improves**, between 3 and 29 tokens by what the run consumed; a signal that cannot be narrowed costs nothing, and a signal an earlier caller already refined is returned free. Read the result honestly: `improved: false` with a `reason` is the common and correct outcome when no source is more specific — it does NOT mean the event is unlocated, and it is not a failure to retry. When it does improve, `evidence` lists the sources that named the place; a location without evidence is never stored, so do not present a refined point without citing them. `footprint_kind` says whether the answer is a POINT or an AREA — if it is an area, describe an area, because an admin-level place has no finite radius and drawing it as a dot misstates where the event was. `uncertainty_m: null` means unbounded, not unknown.",
+        "inputSchema": {
+            "type": "object",
+            "required": [
+                "signal_id"
+            ],
+            "properties": {
+                "signal_id": {
+                    "type": "integer",
+                    "description": "The signal (global_event_id) whose location should be researched further."
+                }
+            }
+        },
+        "outputSchema": {
+            "type": "object",
+            "properties": {
+                "summary": {
+                    "type": "string",
+                    "description": "One-line natural-language summary of the result, ready to relay to a user."
+                },
+                "result": {
+                    "type": "object"
+                },
+                "meta": {
+                    "type": "object",
+                    "description": "Query echo, token charge/balance (meta.tokens), and pagination where applicable."
+                }
+            }
+        },
+        "annotations": {
+            "readOnlyHint": false,
+            "openWorldHint": false,
+            "destructiveHint": true
+        }
+    },
     {
         "name": "measure_index_series",
         "description": "Measure a spectral index over an area, scene by scene, back through the Sentinel-2 archive — the answer to \"how has this changed since <year>\". Give a polygon (or a bbox), an index (ndvi, evi, savi, ndmi, ndwi, mndwi, ndbi, ndsi, nbr, iron-oxide, clay, ferrous) and a date range; each scene is measured over the samples INSIDE the ring, and the result is the per-scene mean/median/min/max with a first-to-last change. Costs 0.5 tokens per scene actually measured; a scene that fails to read is reported in `skipped` and is not charged. **Call it once with `estimate_only: true` first** — that is free and returns how many scenes match, the real date span available, and what measuring them would cost, so the user can agree to the spend. Three things the result carries that any answer must respect: the Sentinel-2 archive begins 2015-06-27, so an earlier start is clamped and `clamped_to_archive` says so (those years are genuinely unavailable, not empty); at most 24 scenes are measured per call, so a longer period comes back as a SAMPLE and the rest appear in `skipped`; and `trend` compares the first and last measured scene only — it is not a fitted rate, so do not attach a slope or a confidence to it. `scenes_found` is what the catalog holds; `scenes_examined` is the newest page this call read, so `candidate_date_span` is the edge of that page and NOT how far the archive reaches — read `notes` before saying when coverage begins. For a SAR quantity, or to keep measuring as new imagery arrives, use create_monitored_area instead. Cite the returned `attribution`.",

package/dist/index.js

@@ -21,7 +21,7 @@ import { Client } from '@modelcontextprotocol/sdk/client/index.js';
 import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';
 import { CallToolRequestSchema, GetPromptRequestSchema, ListPromptsRequestSchema, ListResourcesRequestSchema, ListResourceTemplatesRequestSchema, ListToolsRequestSchema, ReadResourceRequestSchema, } from '@modelcontextprotocol/sdk/types.js';
 import { PROMPTS, RESOURCES, RESOURCE_TEMPLATES, TOOLS } from './catalog.js';
-const VERSION = '1.11.1';
+const VERSION = '1.12.0';
 const REMOTE_URL = new URL(process.env.OFFNADIR_DELTA_MCP_URL ?? 'https://offnadir-delta.com/api/v1/mcp');
 /** Lazily-connected client to the hosted remote MCP server. */
 let remote = null;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "offnadir-delta-mcp",
-  "version": "1.11.1",
+  "version": "1.12.0",
   "description": "Local (stdio) MCP server for Off-Nadir Delta \u2014 live, geolocated world-event intelligence, a Daily World Brief, satellite-imagery search, and an OSINT/GEOINT analyst. Forwards to the hosted server with your API key.",
   "type": "module",
   "bin": {