Skip to main content
Glama

ecosystem_index_diff_latest

Fetch the most recent persisted index diff for the current project. Returns counts of new, reactivated, deactivated, stale, and archived entries so you can track ecosystem changes.

Instructions

Fetch the latest IndexDiff snapshot for the current project.

Maps to GET /api/ecosystem/index_diffs/latest. Returns the most recent diff row produced by a real ecosystem_index_update (dry_run=False) run. Dry-run previews are not persisted and therefore never appear here.

Returns: Diff available: {success: True, diff: {id, diff_type, new_count, reactivated_count, deactivated_count, stale_count, archived_count, markdown_summary, alerted, generated_at}}. No diffs yet (fresh project): {success: True, diff: None, message: 'No index diffs found yet.'}. Endpoint missing (the API answers 404): {success: False, error: 'P0.4 will implement', detail}. Other failure: {success: False, error, detail}. success semantics: True = call completed (diff may be None when the project has never run a non-dry index_update); False = API/endpoint error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.9.0

TDQS

A3.7/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 most of it well: it discloses that dry-run previews are never persisted, that a 404 maps to an unimplemented endpoint ('P0.4 will implement'), and it explicitly defines success=True vs success=False semantics including the case where diff is None. That is genuinely useful non-obvious behavior; only auth/permission caveats are absent.

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

Conciseness3/5

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

The lead sentence is well front-loaded, but the large 'Returns' block enumerates field-by-field payload shapes that an output schema already supplies, adding bulk without adding much interpretive value. Some of that space could have gone to sibling differentiation instead.

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 parameterless read with an output schema, this is close to complete: the dry-run non-persistence rule and the success-flag semantics are the pieces an agent actually needs and would not otherwise get. Auth/permission requirements remain unstated.

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 tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. It correctly gives no parameter guidance because none is needed.

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?

States a specific verb and resource ('Fetch the latest IndexDiff snapshot for the current project') and pins the exact endpoint, so the agent knows precisely what is being retrieved. It does not explicitly differentiate itself from the sibling ecosystem_diff_period or ecosystem_index_update, which would be the natural confusions.

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

Usage Guidelines3/5

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

It implies when this is useful by explaining that only persisted non-dry-run diffs appear here, which helps an agent understand what it will get. However, it never says when to call this versus ecosystem_diff_period or ecosystem_index_update, leaving the sibling routing to inference.

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

Deploy Server

Other Tools