support readme_url #40
Conversation
| @@ -123,6 +124,10 @@ components: | |||
| example: "Node.js server implementing Model Context Protocol (MCP) for filesystem operations." | |||
| repository: | |||
| $ref: '#/components/schemas/Repository' | |||
| readme_url: | |||
There was a problem hiding this comment.
I think the notion of README is too specific to developers.
The registry should be an MCP server directory that is not specifically designed for developer persona end-users. I'd feel a lot more comfortable with this if the field was simply named url.
| readme_url: | |
| url: |
There was a problem hiding this comment.
Even if the end user doesn't care about the readme, they might care about its contents and knowing it in a deterministic way allows:
- Registry UI's to reliably display the server description, e.g. https://mcp.so/server/github/modelcontextprotocol
- Tooling to ingest the documentation, e.g. VS Code and I assume Cline(?) pull in the readme to do AI-assisted server setup
The readme/documentation might differ from the homepage of the MCP server. An alternative is embedding the readme in the registry record itself, which npm and pypi do, but that is a bit bulkier for the server to deal with.
There was a problem hiding this comment.
I think it's worth continuing this discussion here: #39 (comment)
I think rendering a README is a bad pattern to encourage -- we deliberately chose to not do so with PulseMCP because of the bad UX it creates:
- README's vary wildly in quality, and the poor ones can make your MCP marketplace look bad by association
- They vary wildly in structure, so it can be a disorienting experience flipping from one to another
- If you are interested in a specific MCP client, it may not be present in the README, or your competitors may be the only ones present
- If you actually want the README as an end-user, you may as well click the "View Source" button to get it straight from the source, instead of potentially looking at a stale version of it
The discussion on #39 (comment) is more about a generic (perhaps purpose-crafted for the official registry) markdown file, which IMO is a little better than shoehorning a technical README - but I still have versioning and perhaps spam-related concerns with adopting it. I think it's fair to hack it into an MVP implementation on the client side, but these are my hesitations with enshrining it as a long-term standard.
| @@ -123,6 +124,10 @@ components: | |||
| example: "Node.js server implementing Model Context Protocol (MCP) for filesystem operations." | |||
| repository: | |||
| $ref: '#/components/schemas/Repository' | |||
| readme_url: | |||
| type: string | |||
| description: URL to the README markdown file of the server | |||
There was a problem hiding this comment.
| description: URL to the README markdown file of the server | |
| description: URL to additional information about the server, such as a markdown README file or marketing landing page describing the server's functionalities. |
|
I'm not too particular on |
Ref #39
Add readme_url property to the server object. This is url to the README markdown file of the server. Returns readme content in markdown format.