A search-based context engine indexes what already exists (code, pull\nrequests, tickets, docs, chat) and, when the agent asks a question, retrieves\nthe passages that look most relevant. Its strength is coverage: it can surface\na design discussion nobody thought to write up, or the reason behind an odd\nline of code.
\nIts scope is what your team has written. It answers with the passages that\nmatch the question best, which suits questions whose answer lives in a\ndiscussion, a ticket or a commit. A question such as who owns the billing\nservice is different: the agent needs the one current answer your team has\ndeclared, not every passage that mentions it.
\nA catalog holds facts someone declared on purpose: this service exists, this\nteam owns it, it depends on these three services, this is its API. The agent\ndoes not infer the answer from text. It looks it up.
\nIn Componecat that structure is explicit. Every entity has a kind and an\nowning team, relationships are typed (depends-on, parent-of and your own),\nand interfaces carry protocol, URL and auth for an API, or registry and\ncoordinates for a package. An agent can ask for a service's dependencies and\nget a list, or run impact analysis and get the blast radius of a change,\nupstream, downstream or both.
The cost of declared facts is keeping them true. That is why the catalog reads\ncomponecat.yaml descriptors that teams commit next to their code (a scheduled\nscan finds new ones and every push re-reads a changed one), syncs\ndocumentation from Markdown in the repository, and mirrors team ownership from\nGitHub, GitLab, Atlassian or Microsoft 365. These integrations come with Pro\nand Enterprise.
| The agent needs to know | \nBetter answered by | \n
|---|---|
| Who owns this service, and who reviews a change | \nA catalog | \n
| What depends on this, and what a change would affect | \nA catalog | \n
| How to call another service's API | \nA catalog (its interfaces) | \n
| Which conventions apply to this kind of component | \nA catalog (its wiki guides) | \n
| Why a past decision was made | \nSearch, or an ADR section on the entity | \n
| What a teammate said about a bug last week | \nSearch | \n
The two meet in the middle. Componecat can also rank by meaning: on Pro and\nEnterprise, with an embedding model configured, an agent can describe what it\nis looking for ("the service that sends invoices") and get the closest\nentities or documentation sections, then follow declared relationships from\nthere. Search finds the\nstarting point; the catalog supplies the facts around it.
\nComponecat serves the catalog over MCP, so Claude, ChatGPT, Cursor, VS Code\nand other MCP clients can query it. Access is granted read or write per\nresource, and a read-only agent is never offered the editing tools. The\nMCP server page covers what an agent can do, and\nConnect AI agents\nwalks through each client.
\nThe Free plan includes the MCP server, up to 5 users and 50 catalog entities.\nThat is enough to declare one system and the services around it.
\n","summary":"Two ways to give coding agents context (search over what your team has written, or a catalog of declared facts) and where each one fits.","tags":["ai-agents","mcp","context-engineering"]}]}