retoor
251c3dc2ba
- wire spec: lifecycle, stdio + Streamable HTTP transports, tools, utilities, legacy SSE, versioning, changelog (14 Tier 1) - client ecosystem: Claude Code/VS Code/Cursor/Codex configs, mcp-remote, Smithery, registries, Glama (12 Tier 1) - security/ops: authorization draft, trust model, poisoning, rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards - conclusions: minimal stdlib client on 2025-11-25, normalizer + resolver agent for pasted configs/GitHub URLs, untrusted-until- consent trust model; nothing built yet - audit PASS (14 subjects, 797 sources, 32 conclusions)
53 lines
2.7 KiB
Markdown
53 lines
2.7 KiB
Markdown
# Smithery docs: Introduction
|
|
|
|
## Metadata
|
|
|
|
| Field | Value |
|
|
|---|---|
|
|
| Institute | Molodetz Institute - Research and Retrieval Division |
|
|
| Subject | mcp-client-support |
|
|
| Document type | Source Dossier |
|
|
| Tier | 1 |
|
|
| Source title | Smithery docs (Introduction) |
|
|
| Source URL | https://smithery.ai/docs |
|
|
| Source publisher / author | Smithery |
|
|
| Source type | vendor docs |
|
|
| Source date (published) | Unknown, not stated |
|
|
| Date researched | 2026-10-18 |
|
|
| Researched by | tai (agent), model: Claude Sonnet 5, on behalf of retoor |
|
|
| Research method | gather-subagent direct page fetch, parent synthesis from evidence pack |
|
|
| Confidence | High |
|
|
| Status | Active |
|
|
|
|
## Summary
|
|
|
|
Smithery's introductory documentation, presenting it as a managed catalog plus connection layer for MCP servers: zero OAuth configuration, automatic token refresh, encrypted write-only credential storage, and per-server typed SDKs served from `pkg.smithery.ai` paths shaped like `namespace/slug`. Auth layer is powered by open-source agent.pw.
|
|
|
|
## Key findings
|
|
|
|
- Smithery is a managed catalog + connection layer: "Zero OAuth configuration", "Automatic token refresh", "Secure credential storage... encrypted and write-only", "Stateless for you".
|
|
- Per-server typed SDKs served from `pkg.smithery.ai` paths "shaped like `namespace/slug`", class name = PascalCase slug ("`smithery-ai/github` exports `Github`"). Auth layer powered by open-source agent.pw.
|
|
- API key from `smithery.ai/account/api-keys`, used as `Authorization: Bearer $SMITHERY_API_KEY` against `https://smithery.run/<namespace>/<id>`.
|
|
|
|
## Pros / strengths
|
|
|
|
- States the hosted-connection model plainly: OAuth and token refresh are Smithery's problem, not the client's, which fixes the resolution target for Smithery references.
|
|
- The `namespace/slug` addressing plus PascalCase class convention is stated exactly enough to construct SDK imports mechanically.
|
|
- First-party statement of the credential model (encrypted, write-only) grounds trust claims.
|
|
|
|
## Cons / limitations / caveats
|
|
|
|
- No publish date; hosted-endpoint details could drift without notice.
|
|
- Smithery's legacy `server.smithery.ai/.../mcp?api_key=` URL shape is not present on the two Smithery pages read (which show the `smithery.run` + `mcpUrl` model); treat old-pattern knowledge as stale until re-verified.
|
|
- Vendor doc for a paid/hosted layer: catalog coverage and pricing claims need independent checks before tai depends on them.
|
|
|
|
## Relevance to tai
|
|
|
|
A pasted Smithery reference resolves to a hosted URL + key model (namespace/slug to connection), not a local command: a different resolution path than GitHub/npm. The intro page fixes the addressing scheme tai must parse.
|
|
|
|
## Changelog
|
|
|
|
| Date | Change |
|
|
|---|---|
|
|
| 2026-10-18 | Initial dossier created. |
|