sa-ecosystem-node

Hub updates

hub_updates

Read-onlyIdempotent

Read signed hub updates from a public git repo pinned to a commit, verifying manifest hashes, allowlisted authors, and threshold approvals before returning them.

Instructions

Read signed hub updates from a public git repo pinned to a commit. The manifest hash is checked first. An update is returned only when its author is allowlisted and it has enough distinct allowlisted approval signatures over that hash. signedBy lists the author and every wallet whose signature verified, including an author who did not count as an approver. approvedBy lists only the wallets whose approvals counted toward the threshold. selfApproved is true when the author key is the only approver. At threshold 2 or higher that approval does not count unless the node allows it. A locally revoked signer does not count, and an update whose only valid approvals are from revoked keys is left out. Revoking a whole signer group is not implemented. A signer-change adds or removes one signer only after the current threshold of other allowlisted signers approve it. An empty allowlist returns nothing. Does not sign or invent updates. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "hub_updates"
  }
}

Input Schema

Name	Required	Description	Default
`kind`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Nov 4, 2026

TDQS

A3.7/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses the manifest-hash check order, the allowlist and threshold gating, how self-approval is treated at threshold 2+, and that locally revoked signers are excluded. It also surfaces real limitations that matter for callers, such as group revocation not being implemented, signer-change requiring threshold approval, and an empty allowlist returning nothing.

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?

Front-loaded with the core action and then layered with verification rules in a logical order, with no filler sentences. It is dense and long, and a couple of edge-case rules (revocation group not implemented) sit at the same weight as core semantics, but every sentence carries information.

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?

With no output schema, the description compensates by explaining the signedBy, approvedBy, and selfApproved fields and the conditions under which an update is omitted. It leaves some gaps around the overall result container and whether the call is paginated, but the semantics of what is and is not returned are well covered.

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

Parameters2/5

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

Schema description coverage is 0% and the single 'kind' parameter has a 10-value enum with no per-value documentation in either the schema or the description. The description never names 'kind' or explains whether it filters results or how to omit it, though 'signer-change' is discussed as a category in passing.

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: 'Read signed hub updates from a public git repo pinned to a commit,' which tells an agent exactly what comes back and from where. It does not explicitly contrast with the sibling search_hub, so it stops short of a 5.

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?

Usage is implied by 'Read signed hub updates' and the verification rules, so an agent can infer this is the tool for pulling verified updates. However, nothing says when to prefer this over search_hub or list_proposals, and there are no stated exclusions or preconditions for choosing it.

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