Design useful capability boundaries

Read the complete capability list as if you had never seen the source. The model sees names, descriptions, and schemas before it sees implementation details.

Our four boundaries answer different questions:

Capability	Question it answers	Side effect
search_notes	Which notes match this term?	None
get_note	What does this known note contain?	None
notes://catalog	Which notes are available?	None
review_project	How should a review request be phrased?	None

Search and catalog overlap slightly, but they support different discovery paths. The catalog is stable context. Search accepts a bounded query. If both returned the same complete dataset, one should disappear.

Keep names stable and descriptions concrete. Bound string length, result count, and result size. A read-only operation can still expose too much data or consume too many backend resources.

If you add writes later, separate them from reads:

get_note       reads one note
update_note    changes one note
delete_note    removes one note

Do not hide all three behaviors behind manage_note. A specific name and schema let a host request meaningful approval for a consequential action.

Annotations such as readOnlyHint and destructiveHint improve presentation. They are untrusted metadata, not enforcement. Actual safety comes from handler behavior, authorization, and least-privilege credentials.

Delete capabilities that do not make the workflow clearer. A smaller surface is easier for models to choose and people to audit.