Search the MalloryAI knowledge base using semantic similarity. This searches across all indexed cybersecurity content including articles, reports, and documentation. Use this to find relevant information about security concepts, vulnerabilities, threat intelligence, and best practices.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return | |
| query | Yes | Search query for cybersecurity knowledge and information |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that matching is semantic rather than keyword and that the index spans articles, reports, and documentation, but says nothing about result ordering, score exposure, or that results are ranked by similarity rather than recency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with the action and corpus front-loaded; no filler. Slight redundancy in repeating "searches" / "search" across consecutive sentences, but nothing that needs cutting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A two-parameter read tool with a fully documented schema and no output schema; the description covers what is searched and why. Only the shape of returned results and their ordering are left implicit, which is a minor gap for a simple search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented in-schema, so the baseline of 3 applies. The description adds no parameter-level detail at all — it never mentions limit or how the query string is interpreted for semantic matching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Search the MalloryAI knowledge base using semantic similarity") and defines the corpus as all indexed cybersecurity content. It does not, however, distinguish itself from the sibling searchVulnerabilities, which an agent would reasonably consider an alternative for the same subject matter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this to find relevant information about security concepts, vulnerabilities, threat intelligence, and best practices" gives a usage context but names no alternative and no exclusion. The mention of "vulnerabilities" actively muddies the choice against searchVulnerabilities, leaving the agent to infer that this tool is the broad fallback.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
