net-mcp

Rpki Aspa Lookup

rpki_aspa_lookup

Check AS provider authorizations to validate RPKI ASPA relationships and prevent route leaks. Query by customer or provider ASN to see authorized upstreams.

Instructions

Look up RPKI ASPA (AS Provider Authorization) objects.

ASPA defines which upstream providers an AS authorizes for its route announcements. This is a newer RPKI extension that helps prevent route leaks by validating AS path relationships.

Use 'customer' role to see who an AS has authorized as providers. Use 'provider' role to see which ASes have authorized a given AS as their provider.

At most 200 objects are returned (an unfiltered snapshot is the whole dataset); total reports the real count. Requires a Cloudflare Radar API token (CLOUDFLARE_API_TOKEN); error explains if it is missing.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`asn`	No	Filter by customer ASN or provider ASN
`date`	No	Historical date in ISO 8601 (e.g. '2026-03-01'). Default is current.
`role`	No	'customer' to find ASPA objects where ASN is the customer, 'provider' to find where ASN is listed as a provider	customer

Output Schema

TableJSON Schema

Name	Required	Description
`error`	No	Set when an upstream lookup failed; other fields may be empty or partial.
`total`	Yes	Total matching objects, even if the list is truncated
`source`	Yes	Which data source produced this result
`objects`	Yes	ASPA objects (may be truncated; see total)
`data_time`	No	Timestamp of the snapshot

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full burden, and it does so well: it discloses the 200-object cap, that 'total' reports the true count, the Cloudflare Radar API token requirement, and that a missing token yields an 'error'. This is substantial behavioral context beyond the schema.

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 tightly organized and front-loads the core purpose, then explains role semantics, then behavioral limits and auth. Every sentence earns its place; there is no redundancy or filler.

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?

For a 3-parameter lookup tool with an output schema, this is complete: it explains the domain concept, how to use each role, result limits, counting behavior, and authentication requirements. The presence of an output schema covers return-value details.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic depth by explaining what each role means in terms of AS authorization relationships. It also clarifies how 'asn' interacts with the role, going beyond the schema's brief field descriptions.

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 and resource ('Look up RPKI ASPA objects') and expands the acronym with a clear definition. The distinction between customer and provider roles further clarifies exactly what the tool addresses, separating it from other RPKI/route tools.

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?

Gives explicit, actionable usage guidance for both roles: use 'customer' to see authorized providers and 'provider' to see reverse relationships. It does not explicitly name sibling alternatives or exclusion conditions, so it falls just short of a 5.

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