Ask for What You Mean: Semantic Intent Matching

Keyword search breaks the moment the asker and the publisher use different words for the same thing. ASPL matches on meaning, not on overlapping tokens.

The keyword problem

A tool published as "Extract text content from PDF documents" won't surface for a query like "convert documents into machine-readable plain text" under naive keyword matching — almost no words overlap. But they're obviously the same need.

Embeddings close the gap

ASPL encodes each capability's intent and description with a sentence-transformer model (all-MiniLM-L6-v2 by default) and matches queries by cosine similarity. The paraphrase above matches the PDF tool with a healthy score and no shared keywords — verified live against a running node.

ASPL_INTENT_ENGINE=auto      # semantic if available, else TF-IDF
ASPL_INTENT_ENGINE=semantic  # force embeddings
ASPL_INTENT_ENGINE=tfidf     # force lexical, zero extra deps

Graceful by design

Semantic matching is optional. If the embedding model isn't installed, the auto engine falls back to a TF-IDF matcher with the same interface — discovery still works, just lexically. You opt into the heavier dependency only when you want it.

Trust still applies

Semantic similarity decides relevance; it doesn't override trust. The final ranking blends both, and the min_trust floor still filters. A perfect meaning-match with a zero trust score won't jump the queue ahead of a slightly-less-relevant capability that many agents have vouched for.

Meaning-based discovery is table stakes for usability; pairing it with a trust gate is what keeps it safe to automate.