# Extcord (remote · extcord.io)

Agent utilities: read big pages without filling context, exact math, dates, parsing. Free.

- Trust score: 73/100 (medium)
- Change this week: +4
- Registry status: active
- Liveness: live
- Owner verified: no
- Last scored: 2026-11-05

> **Recent critical change**: Authorization (2026-10-12). See the changelog below before you install this server.

## Components

- remote · `extcord.io`: 73/100 (this document), [markdown](https://verifymcp.io/servers/io-extcord-extcord/extcord.md), [page](https://verifymcp.io/servers/io-extcord-extcord/extcord)

## Channel facts

- Endpoint: `https://extcord.io/mcp`
- Transports: `streamable-http`
- Auth: `none`
- Version: `0.7.0`

## Trust breakdown

How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. Scores are 0–100 per category. Scoring method: https://verifymcp.io/docs/scoring (what has changed: https://verifymcp.io/docs/scoring/changelog)

Scored 2026-11-05.

- **Endpoint Security**: 63/100
  - The endpoint's TLS certificate is valid, in date, and uses a strong key.
  - Authorisation check failed: no authorisation is required to call this server, and it exposes a tool marked destructive (delete_recipe).
  - HTTPS is enforced; there's no plaintext access path.
  - The HSTS (Strict-Transport-Security) header is present.
  - DNSSEC check failed: this domain isn't protected by DNSSEC.
- **Transport & Reachability**: 100/100
  - Verified streamable-http transport via a live MCP handshake.
- **Schema Quality & AI Usability**: 73/100
  - 100% of prompts and resources have a non-trivial description (not blank, and not just the item's name).
  - AI-judged instruction clarity (excellent).
  - Context-footprint check failed: tool/resource definitions use about 4210 tokens (~350/item across 12 items; 11 tools + 1 resources), over budget; trim descriptions and params.
  - Usage-examples check failed: none of the tools include examples.
- **Stability & Change Management**: 47/100
  - Stability check failed: schema churn in the 29 days we've observed: 3 tool removals, 0 breaking changes, 0 auth/transport breaks, 8 additions.
- **Tool Coverage**: 98/100
  - 100% of tools have a non-trivial description (not blank, and not just the tool's name).
  - 94% of tool parameters carry a description.
  - Structured output schemas are declared (100% of tools); any adoption earns full credit.
- **Tool Safety**: 100/100
  - No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.
  - All 2 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.
  - An AI judge read all 13 captured unit(s) of tool text and found none that tries to manipulate the model reading it.
- **Capabilities**: 100/100
  - Implements a current MCP spec version (2026-07-28).

## Install

### How do I install the Extcord MCP server?

Extcord is a hosted endpoint at https://extcord.io/mcp, so there is nothing to install locally. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.

### Claude

```bash
claude mcp add --transport http io-extcord-extcord 'https://extcord.io/mcp'
```

### Cursor

```json
{
  "mcpServers": {
    "io-extcord-extcord": {
      "url": "https://extcord.io/mcp"
    }
  }
}
```

### VS Code

```json
{
  "servers": {
    "io-extcord-extcord": {
      "type": "http",
      "url": "https://extcord.io/mcp"
    }
  }
}
```

### Codex

```toml
[mcp_servers.io-extcord-extcord]
url = "https://extcord.io/mcp"
```

### opencode

```json
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "io-extcord-extcord": {
      "type": "remote",
      "url": "https://extcord.io/mcp",
      "enabled": true
    }
  }
}
```

### OpenClaw

```bash
openclaw mcp add io-extcord-extcord --url 'https://extcord.io/mcp' --transport streamable-http
```

### Hermes

```yaml
mcp_servers:
  io-extcord-extcord:
    url: "https://extcord.io/mcp"
```

### Netclaw

```json
{
  "McpServers": {
    "io-extcord-extcord": {
      "Transport": "http",
      "Url": "https://extcord.io/mcp"
    }
  }
}
```

### Vellum

```bash
assistant mcp add io-extcord-extcord -t streamable-http -u 'https://extcord.io/mcp'
```

### Other

```json
{
  "mcpServers": {
    "io-extcord-extcord": {
      "type": "http",
      "url": "https://extcord.io/mcp"
    }
  }
}
```

The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.

## Changelog

Every change recorded for this component, newest first. Days that predate change tracking, or that we cannot explain, say so: "we were watching and nothing happened" and "we were not watching" are different claims.

### 2026-11-05 (score 73, +1)

No change was recorded against any check on this day. Stability & Change Management went from 43 to 47.

### 2026-11-03 (score 72, +1)

No change was recorded against any check on this day. Stability & Change Management went from 37 to 40.

### 2026-11-01 (score 71, +1)

No change was recorded against any check on this day. Stability & Change Management went from 30 to 33.

### 2026-10-30 (score 70, +1)

No change was recorded against any check on this day. Stability & Change Management went from 23 to 27.

### 2026-10-27 (score 69, +1)

No change was recorded against any check on this day. Stability & Change Management went from 13 to 17.

### 2026-10-25 (score 68, +1)

No change was recorded against any check on this day. Stability & Change Management went from 7 to 10.

### 2026-10-23 (score 67, +1)

No change was recorded against any check on this day. Stability & Change Management went from 0 to 3.

### 2026-10-12 (score 66, −6)

- [critical regression] Authorization: partial → fail
- [security regression] Stability: 0.10 → fail
- [security regression] Tool “discover” was removed
- [security regression] Tool “inspect” was removed
- [security regression] Tool “invoke” was removed
- [security] The server rewrote its instructions, which are the text every model session reads
- [security] New tool “delete_recipe”, which the server declares destructive
- [security] Tool “run_pipeline” rewrote its description, which is the text the model reads
- [security] Tool “run_recipe” rewrote its description, which is the text the model reads
- [security] Tool “save_recipe” rewrote its description, which is the text the model reads
- [functional regression] Schema quality: 297 → 350
- [functional] First check of Schema quality: 100
- [functional] Schema quality: good → excellent
- [functional] Destructive annotations: pass → 100
- [functional] New resource “catalog”
- [functional] Server version: 0.5.1 → 0.7.0
- [functional] New tool “calculate_date”
- [functional] New tool “calculate_expression”
- [functional] New tool “discover_ops”
- [functional] New tool “read_handle”
- [functional] New tool “read_package_info”
- [functional] New tool “read_page”
- [functional] New tool “run_op”
- [cosmetic] “run_recipe” added an optional parameter “version”
- [cosmetic] “run_recipe” reworded the description of “params”
- [cosmetic] “run_pipeline” reworded the description of “dry_run”
- [cosmetic] “run_pipeline” reworded the description of “inline_max_tokens”
- [cosmetic] “run_pipeline” reworded the description of “steps”
- [cosmetic] “run_pipeline” reworded the description of “terse”
- [cosmetic] “run_recipe” reworded the description of “dry_run”
- [cosmetic] “run_recipe” reworded the description of “inline_max_tokens”
- [cosmetic] “run_recipe” reworded the description of “name”
- [cosmetic] “run_recipe” reworded the description of “terse”
- [cosmetic] “save_recipe” reworded the description of “author”
- [cosmetic] “save_recipe” reworded the description of “description”
- [cosmetic] “save_recipe” reworded the description of “edit_key”
- [cosmetic] “save_recipe” reworded the description of “example”
- [cosmetic] “save_recipe” reworded the description of “expect”
- [cosmetic] “save_recipe” reworded the description of “name”
- [cosmetic] “save_recipe” reworded the description of “params”
- [cosmetic] “save_recipe” reworded the description of “repairs”
- [cosmetic] “save_recipe” reworded the description of “steps”

## MCP tools (11)

### `read_page` (~318 tokens)

Fetch a public web page and return only the part you need instead of the raw HTML. view: markdown (main content, navigation and boilerplate removed), outline (headings), links (all links; query keeps those whose URL or text contains it), tables (one table, chosen by table, as a markdown table), find (only passages mentioning query; query required). Use this for any single page; use read_package_info for PyPI, npm and crates.io, and run_pipeline for multi-step extraction (e.g. filtering a table's rows). Reads the live page each call and doesn't run JavaScript, so pages built in the browser may come back thin. Only public http(s) addresses. Fetches are limited to 60 a minute per client. Errors (unreachable site, non-HTML content, no table at that index) come back with a suggested fix. Each call runs a built-in page recipe and is recorded in its public run statistics; otherwise nothing is kept except the result's handle, for 60 minutes.

Input parameters:

- `max_tokens` (integer): Most tokens to return. markdown is trimmed (and marks the cut); other views return a preview and handle instead.
- `query`: find: the word or phrase to look for (required). links: keep links whose URL or text contains it.
- `table` (integer): tables: which table, 0 = first, -1 = last.
- `url` (string, required): Public http(s) URL of the page.
- `view` (string)

Output parameters:

- `handle` (string): Handle id (h_...) of the full result, for run_op or read_handle.
- `preview`: Instead of value, when the result is over max_tokens.
- `value`: markdown/outline: text. links: [{href, text}]. tables: markdown table. find: [{match, context, line, offset}].
- `warning` (object): The result looks wrong for this view, e.g. empty.

### `calculate_expression` (~395 tokens)

Evaluate an arithmetic expression exactly: + - * / // % ** use rational numbers, not floats, so 0.1 + 0.2 = 0.3, and money strings like "$1,200.50" read as numbers. Roots, logs and exp are computed to 50 significant digits (returned in decimal when a JSON number can't hold them); trig is in radians, at float precision. Use this instead of doing math in your head; use calculate_date for anything with dates or times, and run_op("stats") to summarize a column of data. Pure computation: no network, same answer every time. Unknown names, syntax errors and results over 5,000 digits are refused with a suggested fix. Example: expr="price * qty * (1 + tax/100)", vars={"price": "$19.99", "qty": 3, "tax": 8.25}, places=2 gives 64.92.

Input parameters:

- `expr` (string, required): Python-style arithmetic; ** is power (^ is refused). Functions: pct(p, x) = p% of x, pct_change(old, new) = (new - old) / old * 100, round(x, places) half-up, floor, ceil, int, abs, sqrt, exp, ln, lo…
- `places`: Round the result to this many decimals, half-up.
- `vars`: Values for the names used in expr: numbers or numeric strings like "$1,200.50". Any name in expr must be here.

Output parameters:

- `decimal` (string): Up to 50 significant digits, when value (a JSON number) holds fewer.
- `exact` (string): Every digit of an integer too large for a JSON number.
- `fraction` (string): The exact fraction of a repeating decimal, like 1/3.
- `value`: The result: a number, or true/false for comparisons.

### `calculate_date` (~405 tokens)

Get the current date and time, or do calendar math exactly, DST-aware. action=now: the current time in tz. action=add: shifts date by the add object, e.g. {"months": 1} or {"business_days": 10}; month ends are clamped (Jan 31 + 1 month = Feb 28). action=between: the time from date to end, as days (end minus start), weeks, a years/months/days breakdown and business days. Business days are Monday to Friday counted after the start day, with no holidays. If end is earlier, the numbers are negative and the result says "direction": "backward". action=info: weekday, week number and quarter of date, converted to to_tz if given. A date with its own offset keeps it; others are read in tz. Use this instead of guessing today's date or counting days yourself; use calculate_expression for plain numbers. Dates in almost any format are accepted; ambiguous ones like 03/04/2026 are read month-first unless dayfirst=true, and notes say how input was read. Missing or unreadable inputs return an error naming the parameter.

Input parameters:

- `action` (string, required)
- `add`: add (required): years, months, weeks, days, hours, minutes, seconds or business_days; negative to subtract.
- `date`: add, between (start), info: required. e.g. "2026-10-07" or "Oct 7 2026 9am".
- `dayfirst` (boolean): Read 03/04/2026 as 3 April.
- `end`: between: the end date (required).
- `to_tz`: info: convert to this zone.
- `tz`: now: the zone to answer in. Others: the zone of dates that don't state one. IANA ("Asia/Tokyo"), offset or abbreviation. Default UTC.

Output parameters:

- `notes` (array): How an ambiguous input was read.
- `value` (object): now/add/info: iso, date, weekday, time, tz, utc_offset, iso_week, quarter. between: days, weeks, breakdown, business_days, direction (forward or backward).

### `read_package_info` (~225 tokens)

Get a package's latest release from PyPI, npm or crates.io as a few fields (version, license, summary, links and the registry's requirement or download fields) instead of the registry's raw response. Latest release only: there is no version parameter. Use this for those three registries; for any other site use read_page. Reads the live registry each call. Fetches are limited to 60 a minute per client. A name the registry doesn't know comes back as its 404, as an error; if the registry's format changes, a warning field says so. Each call runs a built-in recipe and is recorded in its public run statistics; otherwise nothing is kept except the result's handle, for 60 minutes.

Input parameters:

- `ecosystem` (string, required): pypi (Python), npm (JavaScript) or crates (Rust).
- `name` (string, required): Package name, e.g. requests, express, @types/node (scoped), serde. PyPI and crates.io ignore case and treat - and _ alike; npm names must match exactly.

Output parameters:

- `handle` (string): Handle id of the result, usable with run_op or read_handle.
- `value` (object): name, version, released (pypi), license, summary or description, requires_python (pypi) or node (npm), downloads and updated (crates), links.
- `warning` (object): The registry's answer is missing fields it normally has (its format may have changed).

### `discover_ops` (~306 tokens)

Find the op or recipe for a job, or read the details of one. query: best-matching ops, led by solved_before (recipes other agents already proved, with their success rate). op: that op's full contract (args schema, behavior, worked examples). recipe: a recipe's steps, params, expectations, version history and track record. No arguments: every op by category with a one-line intent. Call this before run_op or run_pipeline when you don't know the op id or its args; skip it for jobs the front-door tools (read_page, calculate_expression, calculate_date, read_package_info) already cover. Reads only this server's catalog: no network, no side effects. An unknown op or recipe returns a did-you-mean suggestion. Pass one of query, op or recipe (if several, op wins, then recipe); accepts filters ops by input type, alone or with query. To read everything at once instead, use the resource extcord://catalog.

Input parameters:

- `accepts`: With or without query: only ops that take this input type (text, html, json, list, table, number, boolean).
- `op`: An op id, e.g. 'extract_tables', for its full contract.
- `query`: Words describing the job, e.g. 'html table to rows' or 'decode base64'.
- `recipe`: A recipe name, e.g. 'page_tables', for its definition and track record.

Output parameters:

- `op` (object): op: its contract (args_schema, behavior, examples).
- `ops` (array): query: matching ops (id, intent, accepts, returns).
- `ops_by_category` (object): No arguments: every op id and intent.
- `recipe` (object): recipe: steps, params, example, expect, history.
- `solved_before` (array): query: recipes that already did this, with their track record.
- `track` (object): recipe: status, success_rate, runs and agents in 30 days.

### `run_op` (~487 tokens)

Run one of the 43 ops by id: returns the value, or for large results a preview and a handle id (h_...) to pass as the next op's input. Ops by category: data: json_parse, get, filter, pick, pluck, sort, unique, count_by, stats; format: to_markdown, to_csv, to_text, join, template; compute: calc, now, date_info, date_add, date_diff, encode, decode, url_parse, validate; html: html_clean, html_to_text, select, extract_links, extract_tables, extract_meta; structure: outline; network: fetch; text: find, contains, slice, fit, chunk, replace, split, regex_extract, normalize, count, diff; integrity: hash. Use this for a single step on data you already have; chain two or more with run_pipeline (only the final result comes back). For a standalone answer prefer the front-door tools: calculate_expression over calc, calculate_date over now and date_*, read_page over fetch. Unsure of an op's args? discover_ops(op=<id>). Handles are kept for 60 minutes. Only fetch touches the network (public addresses only, 60 a minute per client); all ops share a limit of 1200 steps a minute. Wrong arg names or types return the op's expected args and a did-you-mean. Example: run_op(op="json_parse", input="{'a': 1,}", args={"lenient": true}).

Input parameters:

- `args`: The op's arguments, e.g. {"url": "https://example.com"} for fetch.
- `inline_max_tokens` (integer): Return the value itself when it's at most this many estimated tokens, else a preview. Default 300.
- `input`: The data to work on: a handle id (h_...) from an earlier result, or a literal value. Omit for ops that take none (fetch, calc, now).
- `input_type`: Override the inferred type of a literal input, e.g. 'html' for markup passed as a string.
- `op` (string, required): Op id from the list above, e.g. 'html_to_text'.
- `terse` (boolean): Return only the answer (value, or handle and preview), without steps, hashes or hints.

Output parameters:

- `handle` (string): terse, large result: its handle id.
- `result` (object): The handle: id, type, size, est_tokens, value or preview, next ops.
- `value`: terse: the value itself.

### `run_pipeline` (~368 tokens)

Chain ops in one call: each step is {op, input?, args?, as?, input_type?}, later steps refer to earlier results as "$0", "$name" or paths like "$1[0]", and only the final result comes back while intermediate data stays on the server. Use this when a job takes two or more ops (fetch, then extract, then filter); for one op use run_op, and if a saved recipe already does the job (discover_ops shows solved_before) use run_recipe. dry_run=true checks refs, arg names, types and cost without running anything. Up to 50 steps. A failing step stops the pipeline; the error names the step, reports which steps finished, and suggests the fix. Steps count toward the 1200 steps a minute limit; fetch steps also toward 60 fetches a minute. Example steps: [{"op": "fetch", "args": {"url": "https://example.com/pricing"}, "as": "page"}, {"op": "extract_tables", "input": "$page", "args": {"index": 0}}, {"op": "to_markdown", "input": "$1"}].

Input parameters:

- `dry_run` (boolean): Validate and estimate without running.
- `inline_max_tokens` (integer): Return the value itself when it's at most this many estimated tokens, else a preview. Default 300.
- `result_from`: Which step to return, as a ref like "$2" or "$prices[0]". Default: the last step.
- `steps` (array, required): Ordered steps, 1 to 50. A literal string starting with $ is written $$.
- `terse` (boolean): Return only the answer (value, or handle and preview), without steps, hashes or hints.

Output parameters:

- `handle` (string): terse, large result: its handle id.
- `problems` (array): dry_run: what would fail, per step.
- `result` (object): The returned step's handle, as in run_op.
- `steps` (array): Per step: op, handle, type, est_tokens, ms.
- `totals` (object): dry_run: the estimate: steps, cost, side effects (e.g. reads_network), deterministic.
- `valid` (boolean): dry_run: whether it would run.
- `value`: terse: the value itself.

### `read_handle` (~228 tokens)

Read a stored result (handle) without running anything: view=summary for its type, size, est_tokens and suggested next ops; view=value for the data itself one page at a time (follow next_offset); view=provenance for the ops, args and source URLs that produced it. Use this when a result came back as a preview and you need more of it. Check est_tokens first: for a large value it's usually cheaper to narrow it with run_op (find, select, filter, fit) than to page through it. Handles expire 60 minutes after they're made; an expired or unknown id returns handle_not_found with a suggestion to re-run the step.

Input parameters:

- `handle` (string, required): A handle id like h_3f9a1c2b7e, from any earlier result.
- `limit`: value: page size. Default 4000 characters or 50 items.
- `offset` (integer): value: where to start, in characters for text or items for lists. Use next_offset from the previous page.
- `view` (string)

Output parameters:

- `chain` (array): provenance: ops, args, inputs and sources, oldest first.
- `handle` (string): The handle id.
- `next_offset`: value: offset of the next page; null at the end.
- `value`: summary: the value if small. value: this page of it.

### `run_recipe` (~382 tokens)

Run a saved recipe (a named, parameterized pipeline, built in or published by agents) in one call; its result is checked against the recipe's expectations. version runs an earlier version from its history, checked against that version's own expect and recorded on that version. Use this when discover_ops lists a recipe for your job (see solved_before); for single pages and package lookups use read_page and read_package_info, which run the built-in recipes for you, and for your own one-off chain use run_pipeline. params must match the recipe's declared params (see discover_ops(recipe=<name>)); defaults can be left out, and missing or unknown params return the param list. verified.correct=false means it ran but the result looks wrong (often a site changed): verified.advice names any repaired recipe. Each real run is recorded in the recipe's public run statistics (success rate, agents using it); only runs with the recipe's own example can mark it broken. dry_run runs and records nothing. Recipes that fetch count toward 60 fetches a minute. An unknown name returns a did-you-mean.

Input parameters:

- `dry_run` (boolean): Return the plan with params filled in, without running or counting anything.
- `inline_max_tokens` (integer): Return the value itself when it's at most this many estimated tokens, else a preview. Default 300.
- `name` (string, required): Recipe name, e.g. 'page_tables'.
- `params`: Values for the recipe's params, e.g. {"url": "https://example.com"}. Params with defaults can be left out.
- `terse` (boolean): Return only the answer (value, or handle and preview), without steps, hashes or hints.
- `version`: Run this earlier version instead of the current one. discover_ops(recipe=<name>) lists the versions kept.

Output parameters:

- `handle` (string): terse, large result: its handle id.
- `plan` (array): dry_run: the steps it would run, with params filled in.
- `result` (object): The final handle, as in run_op.
- `value`: terse: the value itself.
- `verified` (object): checked, correct, and if not: problems and advice (naming any repaired recipe).
- `warning` (object): terse: the result ran but failed the recipe's expectations.

### `save_recipe` (~514 tokens)

Publish a pipeline that worked as a public recipe any agent can run with run_recipe, or publish a new version of one you saved before (pass its edit_key). With an example, the recipe is run once (this fetches live pages, counting toward your fetch limit) and only published if it runs without error and meets expect (with no expect, running without error is the test); without an example it's published as unverified. A new version that fails verification is refused and the current version stays live. Recipes are public: never put secrets, personal data or private URLs in steps or examples. The first save returns an edit_key, shown once and not recoverable: keep it to publish versions or delete_recipe later (without it, a recipe can only be superseded by a repair). To fix someone else's broken recipe, save yours under a new name with repairs=<their name>; discover_ops(query=...) then lists yours first. Limited to 10 saves an hour per client; a taken name, a bad key or a failed verification returns the reason and fix.

Input parameters:

- `author`: Optional public credit, up to 40 characters.
- `description` (string, required): 10-300 characters: what it returns and when to use it. Search matches on this text.
- `edit_key`: To publish a new version of your recipe: the key from its first save.
- `example`: Param values known to work, e.g. {"url": "https://example.com"}. Used to verify now and to health-check later. Strongly recommended.
- `expect`: What a correct result looks like: type, non_empty, min_items, max_items, min_chars, columns, contains, matches, schema. e.g. {"type": "table", "columns": ["Plan", "Price"]}.
- `name` (string, required): 3-64 lowercase letters, digits or underscores, e.g. acme_pro_price. Must be new unless edit_key is given.
- `params`: Each {{param}}: {"type": "string", "description": "...", "default"?: ...}. Every {{param}} in steps must be declared.
- `repairs`: Name of an existing recipe this one fixes.
- `result_from`: Ref of the step to return; default the last.
- `steps` (array, required): Pipeline steps as in run_pipeline, with {{param}} where values vary, e.g. {"op": "fetch", "args": {"url": "{{url}}"}}.

Output parameters:

- `edit_key` (string): First save only, shown once: needed to publish versions or delete.
- `recipe` (object): The recipe as published, with version and track record.
- `verified` (boolean): Whether the example ran and met expect.

### `delete_recipe` (~165 tokens)

Permanently delete a recipe you saved, with its version history and track record, using the edit_key from its first save. Use this to withdraw a recipe that's wrong or no longer needed; to change one, publish a new version with save_recipe and the same key instead. Other agents can no longer run it. Recipes that repaired it stay published and are listed in the reply. The name is retired, never reused, so anyone who refers to it gets a clear 'deleted' error rather than a different pipeline. Built-in recipes can't be deleted; a wrong key, or a name that doesn't match exactly, returns an error and changes nothing.

Input parameters:

- `edit_key` (string, required): The edit key returned when you first saved it.
- `name` (string, required): The recipe's name.

Output parameters:

- `deleted` (string): The recipe that was removed.
- `still_available` (array): Recipes that repaired it; they stay published.

## Diagnostics

Captured diagnostic sections: TLS, DNSSEC, Authorisation, Transports. The full working is on the page: https://verifymcp.io/servers/io-extcord-extcord/extcord#diagnostics

## Score history

- 2026-11-05: 73
- 2026-11-04: 72
- 2026-11-03: 72
- 2026-11-02: 71
- 2026-11-01: 71
- 2026-10-31: 70
- 2026-10-30: 70
- 2026-10-29: 69
- 2026-10-28: 69
- 2026-10-27: 69
- 2026-10-26: 68
- 2026-10-25: 68
- 2026-10-24: 67
- 2026-10-23: 67
- 2026-10-22: 66
- 2026-10-21: 66
- 2026-10-20: 66
- 2026-10-19: 66
- 2026-10-18: 66
- 2026-10-17: 66
- 2026-10-16: 66
- 2026-10-15: 66
- 2026-10-14: 66
- 2026-10-13: 66
- 2026-10-12: 66
- 2026-10-10: 72
- 2026-10-08: 72

## Common questions

### What is the Extcord MCP server?

Extcord is an MCP server listed in the public MCP registry as io.extcord/extcord. Agent utilities: read big pages without filling context, exact math, dates, parsing. Free. This page covers its hosted endpoint (https://extcord.io/mcp).

### Is the Extcord MCP server safe to use?

Extcord scores 73 out of 100 on VerifyMCP. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.

### What tools does the Extcord MCP server expose?

Extcord exposes 11 tools: read_page, calculate_expression, calculate_date, read_package_info, discover_ops, and 6 more. Their descriptions and schemas cost roughly 3,793 tokens of context every time the server is loaded.

### Does the Extcord MCP server require authentication?

No. We connected to Extcord without credentials and it answered, so anything it exposes is reachable by anyone who knows the address.

### Is the Extcord MCP server still maintained?

Extcord is still listed as active in the MCP registry. We last reached this channel on 5 November 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.

## Links

- Remote endpoint: https://extcord.io/mcp
- Changelog RSS feed: https://verifymcp.io/servers/io-extcord-extcord/extcord.xml
- Changelog JSON feed: https://verifymcp.io/servers/io-extcord-extcord/extcord.json
- HTML version of this page: https://verifymcp.io/servers/io-extcord-extcord/extcord