Summary
Look at what it would take to get finance-query-mcp listed in Anthropic's Claude Connectors Directory, the curated directory shown inside Claude.ai's UI. This is separate from and much bigger than listing on the community MCP Registry (#234).
Problem
I checked fq-mcp against the Directory's actual submission requirements and found a few gaps:
- None of the 32 tools have annotations (title, readOnlyHint, destructiveHint), only description is set. Missing annotations are one of the most common rejection reasons.
- There's no privacy policy anywhere in the repo. A missing privacy policy is an automatic rejection.
- Submission happens through a Team or Enterprise Claude.ai org's admin settings, not a personal account.
Proposed solution
Before submitting, we'd need to decide on and do:
- Add title/readOnlyHint/destructiveHint annotations to all MCP tools
- Write and publish a privacy policy
- Set up a Team or Enterprise Claude.ai org to submit through
- Prepare a few example prompts and a test account for reviewers
Alternatives considered
We could rely on the community MCP Registry (#234) plus Claude.ai's "add custom connector by URL" flow, which already works today without any of the above. Adding OAuth to a currently keyless public API is a real architecture decision, so this should stay a deliberate call rather than something we just check off.
Related to the comment from @Johnson-f on #231.
Summary
Look at what it would take to get finance-query-mcp listed in Anthropic's Claude Connectors Directory, the curated directory shown inside Claude.ai's UI. This is separate from and much bigger than listing on the community MCP Registry (#234).
Problem
I checked fq-mcp against the Directory's actual submission requirements and found a few gaps:
Proposed solution
Before submitting, we'd need to decide on and do:
Alternatives considered
We could rely on the community MCP Registry (#234) plus Claude.ai's "add custom connector by URL" flow, which already works today without any of the above. Adding OAuth to a currently keyless public API is a real architecture decision, so this should stay a deliberate call rather than something we just check off.
Related to the comment from @Johnson-f on #231.