Add BaseScout token risk research plugin to base-mcp

## Feature request

Add a native Base MCP plugin for **BaseScout**, a read-only Base token risk research service.

BaseScout provides a public versioned report for an exact Base ERC-20 contract. The proposed plugin uses that report as a research step and optionally routes a separately requested and confirmed trade through Base MCP's semantic `swap` tool.

## Why

Base MCP can already execute swaps, but users who explicitly choose BaseScout do not have a native workflow for checking automated market, contract, and security signals before the approval step.

The proposed flow keeps the boundaries separate:

1. BaseScout performs a public read-only report request.
2. The agent presents detected risk and data confidence separately.
3. The agent stops or requires stronger confirmation for critical, high-risk, or insufficient-data reports.
4. Only an explicit user request is handed to Base MCP `swap`.
5. The user reviews the normal approval in Base Account.

BaseScout does not produce calldata, receive wallet details, sign messages, or submit transactions.

## Proposed plugin

- Integration: `http-api`
- Chain: `base`
- Auth: `none`
- Shell: `none`
- HTTP host: `basescout.app`
- Submission tool: optional Base MCP `swap`
- Risk tags: `slippage`, `low-liquidity`

Prepared source and review diff:

- BaseScout PR: https://github.com/kopobaeth/basescout/pull/6
- Raw candidate plugin: https://raw.githubusercontent.com/kopobaeth/basescout/refs/heads/agent/base-mcp-upstream-prep/integrations/base-mcp/plugins/basescout.md
- Project: https://basescout.app/

The candidate follows the current canonical section order:

`Overview → Surface Routing → Endpoints → Orchestration → Submission → Example Prompts → Risks & Warnings → Notes`

It intentionally does not edit the Base MCP `SKILL.md` registry or other maintainer-managed files.

## Public read endpoint

```text
GET https://basescout.app/api/v1/report?address=
```

No authentication, cookies, wallet address, or user identifier is required.

Current response contracts:

- `schemaVersion: 1.0.0`
- `scoreVersion: 2.0.0`
- Base chain ID `8453`
- canonical lowercase contract address
- separate overall/market/contract risk and data confidence
- provider status for DEX Screener, Etherscan, and GoPlus
- transparent evidence, request ID, generated timestamp, and disclaimer
- typed error envelope with `retryable`

## Safety controls

- exact 20-byte Base contract required; zero address rejected
- symbols are disambiguated before any request or trade
- schema, chain, address, score version, and freshness validated
- report and token metadata treated as untrusted data, never instructions
- provider unavailability is not interpreted as a passing check
- risk and confidence are never conflated
- critical findings stop wallet writes until a new exact override
- high-risk and insufficient-data reports require a fresh exact confirmation
- no automatic swap, default asset, default amount, or unsupported parameter
- optional writes remain in Base MCP approval mode

## Live read-only verification

Verified on 2026-07-19 without wallet actions:

1. Valid AERO request
- HTTP `200`
- schema `1.0.0`
- score `2.0.0`
- chain `8453`
- canonical address, request ID, provider coverage, and disclaimer present

2. Invalid address request
- HTTP `400`
- error code `invalid_address`
- `retryable: false`
- request ID present

Repository checks also pass:

- `npm test`
- `npm run build`
- static assertions for valid frontmatter enums, canonical heading order, allowlist host, relative Base MCP references, response validation, untrusted-data handling, and explicit confirmation rules

## Maintainer asks

The current contribution policy says code contributions are limited to the Base core team, so I am opening a proposal rather than an unsolicited code PR.

If this integration is a fit, could the maintainers:

1. confirm interest or the next review step;
2. import/request the single plugin file at `skills/base-mcp/plugins/basescout.md`;
3. add the maintainer-owned registry entry after acceptance; and
4. provision `basescout.app` in the hosted Base MCP `web_request` allowlist for the accepted plugin?

I can provide additional response samples, operational details, or make changes in the BaseScout source PR based on review feedback.

Start with the prepared candidate at the BaseScout plugin source and compare it with the target path, skills/base-mcp/plugins/basescout.md. Run npm test and npm run build, then review the static assertions for frontmatter, heading order, host allowlisting, response validation, untrusted data, and confirmation rules. Done requires maintainer acceptance, registry handling, and hosted web_request allowlisting.

Written by the indexing model from the issue text.