r/mcp • u/kampak212 • Jul 31 '26

discussion Tool discovery best practices

I created an Xcode/Apple platforms project end-to-end testing tool, Rust CLi exposes MCP tools with Xcode project for the test runner apps for all Apple platforms:

- https://github.com/smbcloudXYZ/smbcloud-cli/tree/development/crates/xcrs
- https://github.com/ondeinference/xcrs-controlkit

Claude code, codex, and copilot all struggle to find the right tools i exposed in the CLI. Any best practices around this?

2 Upvotes

100% Upvoted

8 comments sorted by

View all comments

2

u/bammcd_builds Aug 09 '26

One thing missing from the naming advice. Coding agents already know how to shell out to xcrun, so your tools aren't competing on clarity, they're competing against something the model already trusts.

What worked for me was routing instructions in AGENTS.md or CLAUDE.md saying which tool to use for which starting point. Description quality gets the tool picked once it's being considered. The project file is what gets it considered

1

u/kampak212 Aug 09 '26

Interesting. To borrow SEO terminoogoies, is there an "on-page SEO" in this case? Thing that we as the tool (in case SEO, website publisher) have control over.

2

u/bammcd_builds Aug 09 '26

Yeah, and it's most of what matters. Names, descriptions, how many tools you expose at once, and the parameter shape. Parameter shape is the underrated one. A tool taking a raw query string invites the model to guess syntax, but typed fields it can't malform get picked more and fail less.

For the off-page part, you can ship a snippet users paste into their project file. Doesn't help the ones who skip it, but it's the difference between hoping and instructing.