The design trades tool-list size for a round trip — a client carries a single tool definition instead of a separate one for every API, and pays a schema fetch before each call, which the tool's own description asks for every time. The consequence for a reader is that the API surface is discovered at runtime through `toolName` rather than read off the tool list, so an agent that guesses names will fail at the shim rather than at the API.
A single-tool front door to RSS3's APIs: API-get-input-schema takes a `toolName` and returns the input schema for that API, which its own description says to fetch before every call.
- A schema lookup by name: API-get-input-schema returns the input schema for the API named in `toolName`, so the argument shape is read from the server rather than assumed.
- A single entry point rather than a separate tool for every API: the APIs reachable this way are addressed through the `toolName` argument, so the client's tool list stays at one definition however many APIs sit behind it.
No credentials are configured. A call needs the name of the API you intend to use, since `toolName` is the only argument the schema lookup takes.
One command — npx mcp-server-rss3