MCP manifest audit: tool names are clear, but DXT manifest lacks per-tool descriptions

[silvermango9927]

Hi! I’m working on audit-mcp, a local CLI that reviews MCP tool surfaces for discoverability issues: overlapping tools, unclear primary vs follow-up actions, weak trigger language, and places where agents may not have enough signal to pick the right tool. (Also really sorry because I wasn't sure what template this issue fit under)

I tried to run it against the local Stripe MCP package. Since the local package proxies to the hosted Stripe MCP server and requires a valid key, I could not safely get a runtime tools/list export. Instead, I audited the DXT manifest in this repo:

tools/modelcontextprotocol/manifest.json

So please treat this as manifest-level feedback only. If the hosted/runtime tools/list already includes rich descriptions, this may not apply.

Summary from manifest-level audit

• Tools declared in manifest: 23
• Manifest lists tool names but no per-tool descriptions
• Average score from manifest-only audit: 64.3
• Main finding: names are clear, but clients reading only the manifest do not get enough per-tool activation guidance.

Manifest tools with no descriptions

The manifest declares names like:

• search_documentation
• create_customer
• list_customers
• create_product
• list_products
• create_price
• list_prices
• create_payment_link
• create_invoice
• create_invoice_item
• finalize_invoice
• create_refund
• list_payment_intents
• list_subscriptions
• cancel_subscription
• update_subscription
• update_dispute
• list_disputes

The names are readable, but payment workflows have important safety and sequencing distinctions. For example, an agent may need clearer guidance for:

• when to create a customer before an invoice/payment link
• when to create an invoice item before finalizing an invoice
• when refund/subscription/dispute mutation should require explicit user review
• when to search docs instead of touching account resources

Possible direction

If DXT consumers use this manifest for tool discovery, adding descriptions could improve activation quality.

Example pattern:

Use when: the user explicitly wants to create a draft invoice for an existing Stripe customer.
Returns: the created invoice object and ID.
Do not use when: the invoice should be finalized or sent; use `finalize_invoice` only after user review.
Safety: creates account state; require explicit confirmation for customer, amount, currency, and line items.

Why I’m sharing

This may be a false positive if the hosted MCP runtime provides richer tool descriptions than the DXT manifest. If so, a sample tools/list export in the repo/docs would make this kind of audit much more accurate.

I’m trying to learn whether MCP maintainers find this kind of tool-surface feedback useful or noisy, especially for high-impact domains like payments.