Which integrations are available for this server?

Allows checking whether Docker images are alive, dormant, abandoned, archived, or deleted, using lastseen.dev observations. Allows checking the survival status of GitHub repositories and organizations, providing dated observations on whether they are alive, dormant, abandoned, archived, or deleted. Enables parsing GitHub Actions workflows and checking the status of the actions (uses: refs) they depend on, based on lastseen.dev observations. Enables checking whether npm packages are alive, dormant, abandoned, archived, or deleted, using lastseen.dev observations.

How do I use lastseen-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@lastseen-mcp Check if actions/checkout is alive or abandoned." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

lastseen-mcp

by agentidx

Overview Schema Related Servers Score Discussions

Python

Remote

lastseen-mcp

mcp-name: dev.lastseen/mortality

last seen code: MIT

Is this dependency dead? Dated observations of whether an npm package, GitHub Action, MCP server, or Docker image is alive, dormant, abandoned, archived, or deleted — published by lastseen.dev. Free, no API key, zero telemetry.

There are two ways in, and they answer the same question from the same dated data:

Call the free HTTP API directly — the durable, machine-native path (below). An agent that keeps a dependency list can re-check it on every build.
Run it as an MCP server — a thin stdio wrapper over that same API, for MCP clients.

1. The free API (call it directly)

No key. No signup. 60 requests/minute, anonymous GET. Every response is a dated observation with its source — not a score, not advice. Base URL https://lastseen.dev.

# one component (owner/repo)
curl https://lastseen.dev/api/v1/entity/actions/checkout

# everything held under a GitHub owner/org
curl https://lastseen.dev/api/v1/org/actions

# a whole manifest at once (names-only body)
curl -X POST https://lastseen.dev/api/v1/manifest \
  -H 'content-type: application/json' \
  -d '{"channel":"api","components":[{"name":"actions/checkout","kind":"github-action"}]}'

# self-describing API docs (JSON)
curl https://lastseen.dev/api/v1/docs

A single-component response carries the latest_state, the dated series behind it, the source_of_record, and interval-censoring notes — enough to re-check any verdict against GitHub yourself. This is the recurring path: wire GET /api/v1/entity/{owner}/{repo} into CI and a dead dependency shows up on the build that introduces it, not months later.

Contract

Lookups, not advice. Every answer is a dated observation with its source. Never "use X instead", never a composite score, never a ranking by preference, never urgency language.
Fails closed. An unknown or fabricated subject returns a clean not_observed — never a fabricated result. A network/store error degrades (try later); it is never read as "dead".
Absence ≠ gone. No record means "not checked", never "deleted". Only an authoritative HTTP 404 is a deletion.

States

alive (≤180d since last commit) · dormant (180–365d) · abandoned (>365d) · archived (repo archived) · deleted (authoritative HTTP 404) · eol (declared end-of-life) · unknown-stale (the observation the verdict rests on is older than the 180-day threshold and was not re-verified — no state asserted; not a death) · not_observed (403 / 429 / timeout / not held — not dead).

Related MCP server: mcp-dependency-version

2. Run it as an MCP server

A pure-standard-library stdio wrapper over the API above — no mcp package, no requests, no FastAPI/Starlette, nothing that can conflict with a host app. It speaks JSON-RPC 2.0 over stdio and calls the free API over urllib.

Install

pipx install lastseen-mcp
# or run without installing:
uvx lastseen-mcp

Requires Python ≥ 3.10. No dependencies.

Add to an MCP client

{
  "mcpServers": {
    "lastseen": { "command": "lastseen-mcp" }
  }
}

(If you use uvx, set "command": "uvx", "args": ["lastseen-mcp"].)

Tools

Tool	What it does
`check_entity(slug, live?)`	Dated survival series for one `owner/repo` (e.g. `actions/checkout`). `live=true` attaches a live GitHub read (absence ≠ gone).
`check_org(name)`	Dated states for every held component under a GitHub owner/org.
`check_manifest(paste)`	Paste a GitHub Actions workflow (`uses:` refs) or `owner/repo` lines; get the dated state per component. Unheld components are `not_observed`.
`survival_profile(category)`	Category ranking — not available over the free API; returns an honest not-supported result pointing to the per-entity/org/manifest lookups and the CC-BY dumps.

check_manifest looks up at most 30 parsed components per call (free-tier rate bound); any remainder is reported as n_truncated.

Privacy

Zero telemetry. The client and the API store nothing and transmit no identifier about you, your org, or the subjects you look up — anonymous GETs only.

Licensing

Code: MIT (see LICENSE).
Data: the mortality/survival observations are published by lastseen.dev under CC-BY-4.0 (attribution required). The two licenses are independent.

Available Tools

4 tools

check_entityA

Dated survival observation(s) for ONE owner/repo (e.g. 'actions/checkout') from lastseen.dev. Returns the recorded state series with dates and sources. Lookup, not advice. Unknown/fabricated subjects return a clean not_observed, never a fabricated result.

ParametersJSON Schema

Name	Required	Description	Default
`live`	No	optionally attach a live GitHub read (absence != gone); default false
`slug`	Yes	owner/repo, e.g. 'actions/checkout'

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the return format ('recorded state series with dates and sources'), the non-advice nature, and the honest failure behavior for unknown/fabricated subjects ('clean not_observed, never a fabricated result'). It stops short of stating rate limits or data freshness, but for a read-only lookup these are minor omissions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, all informative, with the primary subject front-loaded in the first sentence. No filler or redundancy. Each sentence adds a distinct layer: subject, return content, and failure semantics.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with only two parameters and no output schema, the description covers the essential lookup behavior, return value nature, and not-found semantics. It does not detail what a 'survival observation' looks like structurally, but the phrase 'state series with dates and sources' gives enough shape. This is well complete for its simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with both slug and live documented in the input schema. The description adds marginal semantic value by clarifying the subject scope and the return concept, but it does not go beyond what the schema already provides. Baseline 3 is appropriate because the schema handles parameter documentation adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Dated survival observation(s) for ONE owner/repo' from lastseen.dev. It clearly distinguishes itself from siblings by scoping to a single owner/repo and explicitly calling out its lookup nature. The example 'actions/checkout' and the return of a 'recorded state series' make the function unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear usage context: it is for one specific repo ('ONE owner/repo') and is a 'Lookup, not advice.' It also warns about unknown/fabricated subjects returning not_observed, which helps set expectations. It does not explicitly name alternatives like check_org or check_manifest, but the singular repo scope implies when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_manifestA

Parse a pasted manifest (GitHub Actions workflow uses: refs, or a list of owner/repo lines) and return the dated survival state per component from lastseen.dev. Components not held are reported as not_observed. Lookup, not advice.

ParametersJSON Schema

Name	Required	Description	Default
`paste`	Yes	raw manifest text to parse

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does meaningful work: it states the source (lastseen.dev), defines handling for components not held ('reported as not_observed'), and explicitly frames the operation as lookup rather than advice. This is valuable behavioral disclosure beyond what the schema provides.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, front-loaded, and contains no waste. Every clause adds useful information: input format, output behavior, edge-case reporting, and the 'not advice' caveat. It is a model of concise tool documentation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, no-output-schema tool this is largely complete: it tells the agent what input to pass, how it will be interpreted, what results look like, and how missing components surface. It doesn't detail the exact response shape or rate limits, but no output schema exists and those are secondary for a simple lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only says 'raw manifest text to parse', while the description enriches it by specifying the two accepted formats (GitHub Actions uses refs, or owner/repo lines) and the resulting interpretation per component. Since schema coverage is 100% but shallow, the description adds real semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb ('Parse'), the resource (a pasted manifest), and the return value (dated survival state per component). It also enumerates accepted input formats (GitHub Actions uses refs or owner/repo lines), distinguishing it from siblings like check_entity and check_org. 'Lookup, not advice' further clarifies its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly indicates this tool is for parsing manifest-size input rather than a single entity or org, which aligns with the sibling context. It doesn't explicitly name alternatives or say when not to use it, but the input-type signal is strong and the closing 'Lookup, not advice' sets appropriate expectations.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

check_orgA

Dated survival states across the components referenced under an ORG (a github owner slug), from lastseen.dev. Org-level only. Lookup, not advice.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	github owner/org slug, e.g. 'actions'

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the disclosure burden. It conveys the source ('from lastseen.dev'), scope, and non-advisory nature ('Lookup, not advice'), but does not mention read-only behavior, authentication needs, rate limits, or response format. This is adequate for a simple lookup but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. Key scoping information is front-loaded, and every clause adds value: the resource, the source, the scope, and the lookup/advice distinction.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool, the description plus full schema coverage is sufficient for correct invocation. It identifies the input, source, and scope. The lack of an output schema means return values are not detailed, but the description does not need to explain them per rubric. Minor missing context includes possible error conditions or assumptions about org-slug validity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the single required parameter 'name' is already fully documented as a GitHub owner/org slug. The description adds only organizational scope ('Org-level only') and does not provide additional parameter semantics, matching the baseline for high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('Dated survival states across the components referenced under an ORG') and a clear action ('Lookup'). It also scopes the tool with 'Org-level only', which helps differentiate it from sibling tools like check_entity and check_manifest, though it does not name them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Org-level only' gives clear context about when this tool applies, and 'Lookup, not advice' provides an exclusion that prevents misuse. However, it does not explicitly compare against sibling tools such as check_entity or survival_profile, leaving some routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

survival_profileA

Ranked survival profile for a CATEGORY. NOTE: category ranking is not available over the free HTTP API — this returns an honest not_supported result and points to the per-entity/org/manifest lookups and the CC-BY dumps.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	max ranked rows (default 50)
`category`	Yes	e.g. 'mcp', 'github-action', 'github-repo'

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait—that this tool will not perform the expected ranking and instead returns an 'honest not_supported result'—and gives pointers to alternatives. It doesn't detail the exact shape of the not_supported result, but the warning is significant and trustworthy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The main promise is front-loaded, and the limitation plus escape hatch follow immediately. Slightly more detail on the alternatives could push it to 5, but it is already tight and useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a tool that is essentially a guard against a known limitation: the agent knows when it works, when it won't, and what to call instead. No output schema is needed because the primary outcome is the not_supported signal, which is fully explained.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters. The description reinforces the purpose ('category ranking') and the intended resource, but adds no extra syntax or format details beyond what the schema provides. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('ranked survival profile') plus a precise resource (CATEGORY) and immediately distinguishes itself from sibling lookups. It also tells the agent what it is NOT (free HTTP API category ranking) and what it returns instead (honest not_supported result with pointers to alternates).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when category ranking is unavailable (via free HTTP API) and where to go instead (per-entity/org/manifest lookups and CC-BY dumps). This is exactly the kind of conditional routing an agent needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.2Aug 30, 2026
- First observedcheck_entity
- First observedcheck_manifest
- First observedcheck_org
- First observedsurvival_profile

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Disambiguation5/5

Each tool targets a distinct input scope: single owner/repo, org slug, pasted manifest, and category profile. The scopes are clearly described, and the batch manifest tool is unlikely to be confused with the single-entity or org-level lookups.

Naming Consistency4/5

Three of the four tools follow the consistent check_<scope> pattern (check_entity, check_org, check_manifest). survival_profile breaks the verb_noun pattern, but it is a single recognizable exception rather than a systemic inconsistency.

Tool Count4/5

Four tools is a reasonable size for a narrow read-only lookup service. However, survival_profile is effectively an unsupported stub that always returns not_supported, so it pads the count without adding a working capability.

Completeness4/5

The core lookup workflows are covered: single entity, org-wide, and manifest-based batch checks. The main gap is category-level ranking, which survival_profile cannot provide, though the description points to alternative lookups and external dumps as workarounds.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Dependency Health MCP A
io.github.ux-xd
Package alive? Verdict with evidence: deprecated, archived, stale or active; plus runtime EOL dates.
Developer Tools
31
MCPFax Dev Package Intelligence A
com.mcpscores
Is this dependency current, licensed, deprecated, or already carrying a CVE?
Developer Tools Security
51
Readout C
io.github.kaitzyy-dev
Measured readings on open-source dependencies: health, end-of-life, model prices, incidents.
Developer Tools Observability Open Data
3111
Sighttrue B
io.github.kaitzyy-dev
Measured readings on open-source dependencies: health, end-of-life, model prices, incidents.
Monitoring Observability Developer Tools
3111

Related MCP Servers

Dependency Freshness MCP
Developer Tools CI/CD & DevOps
Armigerous
A
license
A
quality
B
maintenance
Checks npm and PyPI packages for outdated versions, deprecation status, and breaking changes with cited sources, enabling AI agents to verify dependency freshness.
Updated 3 months ago (2026-06-12 20:34 UTC)
1
17
ISC
mcp-dependency-version
Developer Tools Security
Tripletex
A
license
Not graded
quality
A
maintenance
Enables users to look up package versions, scan for vulnerabilities, and analyze dependencies across multiple registries (npm, Maven, PyPI, etc.) using exact version recommendations for security.
Updated 2 months ago (2026-07-14 06:10 UTC)
4
MIT
dependency-health-mcp
Developer Tools Security Code Analysis
power-tester
A
license
Not graded
quality
C
maintenance
Monitors and analyzes dependency health in Node.js projects, providing tools to check outdated packages, vulnerabilities, licenses, and suggest safe upgrades.
Updated 7 months ago (2026-01-23 21:12 UTC)
14
MIT
deptrustofficial
Security Developer Tools
clidey
A
license
Not graded
quality
A
maintenance
deptrust is a CLI that checks package versions for known vulnerabilities across npm, PyPI, crates.io, Go modules, RubyGems, NuGet, Maven, Packagist, pub.dev, CocoaPods, Hex.pm, Hackage, GitHub Actions, and more. It runs locally as a CLI and as an MCP server. It calls public package registry and OSV APIs directly; there is no hosted deptrust service to trust or configure.
Updated 18 days ago (2026-08-19 12:26 UTC)
182
61
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agentidx/lastseen-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

lastseen-mcp

1. The free API (call it directly)

Contract

States

2. Run it as an MCP server

Install

Add to an MCP client

Tools

Privacy

Licensing

Links

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

deptrustofficial

Latest Blog Posts

MCP directory API