MCP Tool Search does not replace permission design

MCP Tool Search is a good answer to a very real problem: tool catalogs are getting too large to dump into every agent conversation.

Loading fewer tool definitions means less token waste, less confusion, and fewer irrelevant capabilities competing for the model’s attention.

But for database-connected agents, discovery is only half the problem.

The harder question is:

What is this tool allowed to do once the model finds it?

Discovery is not authorization

A searchable tool catalog can help an agent find the right capability.

It should not become a shortcut around the permission model.

For database MCP servers, I would rather expose narrow workflow tools:

• get_monthly_revenue_summary
• list_overdue_invoices
• find_customers_with_usage_drop
• get_support_escalation_context

Than broad tools like:

• run_sql
• query_table
• execute_statement

Tool Search can make safe capabilities easier to find.

It can also make unsafe capabilities easier to reach if the catalog is poorly designed.

Metadata becomes production interface

With Tool Search, names, descriptions, tags, and schemas matter even more.

A useful tool definition should make clear:

• what business question it answers
• whether it is read-only or write-capable
• which approved view or source it uses
• what limits are enforced
• when the model should not use it

That metadata is not decoration.

It shapes model behavior.

Full piece: MCP Tool Search for database agents: discovery is not permission design

Conexor is MCP infrastructure for connecting databases and APIs to AI clients like Claude, ChatGPT, Cursor, n8n, and Continue.

Discovery should make safe capabilities easier to find.

It should not make unsafe capabilities easier to reach.