website-search

aidefense_cross_map

Read-onlyIdempotent

Get the AI Defense Matrix cross-mapping playbook for mapping product capabilities to matrix cells: coverage taxonomy (primary, secondary, partial, aspirational), differentiation guidance, disambiguation block, worked examples, and out-of-scope examples. The response always includes an inScopeCheck. Products that USE AI to solve a non-AI security problem (deepfake detection, AI-for-fraud, AI features added to existing SIEM, SOAR, or EDR tools) belong in the Cyber Defense Matrix at https://cyberdefensematrix.com. Pairs naturally with product_load_context(productFocus: 'ai_security') for follow-on positioning and GTM work. This server never requests your program docs or product roadmap and instructs your AI to keep them local—the matrix, framework alignments, and playbooks flow to your AI for local analysis.

Input Schema

TableJSON Schema

Name	Required	Description
`framework`	No	Optional: include only one external framework's cross-mapping (e.g., 'owasp-llm-top10') alongside the playbook.
`whitespace`	No	Optional: when true, surface a `whitespace.sparseCells` block scoped to vendor-empty cells where a product can plausibly succeed (vendorDensity <= 1 AND coverageType in {tooling, hybrid}). Process-shaped sparse cells are excluded by default because their emptiness does not indicate market opportunity.
`include_process_shaped`	No	Optional: when true with whitespace, include process-shaped sparse cells in the result. Use when you want to see all empty cells regardless of whether a product is the right answer there.
`include_framework_alignment`	No	Optional: when false, the framework alignment block (~half the response) is omitted in favor of a short note pointing to aidefense_get_framework_alignment. Use when the caller will fetch alignment separately and wants a slim cross_map response. Default: true.

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, the description discloses important behavioral traits: the response always includes an inScopeCheck, the server never requests program docs or roadmap (with instructions to keep them local), and data flows to the AI for local analysis. These details provide significant transparency about privacy and processing behavior that annotations do not cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph with five sentences, each serving a purpose: content list, response guarantee, scope exclusion, pairing suggestion, and privacy behavior. It is longer than ideal but contains no fluff; however, the 'Pairs naturally' and 'This server never requests' sentences could be considered slightly tangential to tool invocation. Still, it remains efficient for the amount of context provided.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has no output schema, so the description compensates by thoroughly listing the response components: coverage taxonomy, differentiation guidance, disambiguation block, worked examples, out-of-scope examples, and inScopeCheck. It also explains the optional framework behavior and the effect of include_framework_alignment (slim response) and whitespace via schema. For a read-only query tool with rich schema descriptions, this is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds no direct parameter-level detail beyond what the schema already provides, but the schema itself has rich descriptions for each parameter (framework, whitespace, include_process_shaped, include_framework_alignment). Since schema carries the full semantic burden, a 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as 'Get the AI Defense Matrix cross-mapping playbook' with a specific purpose of mapping product capabilities to matrix cells. It enumerates the content delivered (coverage taxonomy, differentiation guidance, disambiguation, examples), distinguishing it from sibling tools like aidefense_get_matrix and aidefense_get_framework_alignment. The scope exclusion for products that use AI to solve non-AI security problems further clarifies its niche.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when this tool is relevant, such as pairing with product_load_context for positioning work, and explicitly states that products using AI for non-AI security problems belong in the Cyber Defense Matrix rather than this tool. However, it lacks an explicit 'use when X, use Y instead' structure and does not name an alternative tool for the Cyber Defense Matrix, making the guidance useful but not fully precise.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All website-search tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0

Disambiguation4/5

Each tool has a distinct domain prefix (assessment, cti, ir, malware, vuln, product) that makes its purpose clear, and overlapping tools like get_template and get_brief_template are explicitly described as standalone variants. However, the large number of similarly structured tools (get_guidelines, load_context, get_frameworks) across six domains could still cause an agent to reach for the wrong domain's tool without close attention.

Naming Consistency5/5

Tool names follow a highly consistent snake_case pattern: domain_get_* (e.g., ir_get_template, cti_get_guidelines), domain_load_context, domain_review_report, and domain_get_cross_server_routes. The few exceptions like product_compare_context and search_zeltser still match the general verb-first or domain-first style, so the overall naming scheme is predictable and readable.

Tool Count2/5

With 53 tools, the server is far too large for its stated purpose of 'website search.' The vast majority of tools are not about search but rather about writing guidelines, templates, and scoring rubrics for multiple report domains (assessment, CTI, IR, malware, vuln, product) plus an AI defense matrix. The count is inflated by repeating the same set of ~7 tools for six different domains, making it feel bloated and hard to navigate.

Completeness4/5

For the broad coaching/report-writing scope, coverage is thorough: every domain has a template, guidelines, context loader, review criteria, and frameworks, plus generic writing guidance and rating tools. The actual search capability is minimal (search_zeltser, get_article, get_index_info) but adequate for the core task; a notable gap is the lack of a tool to list or browse all articles, which would make discovery easier.

Resources

Need Help?