Skip to main content
Glama
Sign In
Vicarius vRx MCP Server

Vicarius vRx MCP Server

by Space-C0wboy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vulnerability_search

Search for vulnerabilities and CVEs using RSQL filters such as sensitivity level. Required inputs: query, start index, and page size.

Instructions

Search vulnerabilities/CVEs. RSQL q filter, e.g. q=vulnerabilitySensitivityLevel.sensitivityLevelName=='Critical'. size<=500, from<=10000. Required: q, from, size.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "vulnerability_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoquery param q (str)
sortNoquery param sort (str)
groupNoquery param group (str)
from_Noquery param from (int)
sizeNoquery param size (int)
includeFieldsNoquery param includeFields (str)
bodyNoJSON request body

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.5/5.0
Behavior2/5

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

No annotations are provided, so the description must convey behavioral traits. It only states constraints and an example filter, but does not disclose whether the tool is read-only, what it returns, or any side effects, leaving significant gaps.

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 concise (two sentences) and front-loads the purpose, then provides an example and constraints. It is efficient, though could be structured slightly better for readability.

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

Completeness2/5

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

Without an output schema, the description should explain return values or expected behavior after invocation. It does not mention the response format, pagination beyond size/from, or any usage notes, leaving the agent underinformed.

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

Parameters4/5

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

Schema coverage is 100% with descriptions, but the tool description adds value by explaining the RSQL filter format for 'q' and specifying numerical constraints on 'size' and 'from' (e.g., size<=500). This goes beyond the schema's minimal parameter descriptions.

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 states the tool's purpose: 'Search vulnerabilities/CVEs.' It specifies the resource and action, and provides an example filter using RSQL, which distinguishes it from other search tools.

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

Usage Guidelines3/5

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

The description gives constraints on parameters (size<=500, from<=10000) and mentions required parameters (q, from, size), but does not contrast with sibling tools like vulnerability_count or other search tools, leaving usage comparisons implicit.

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

Deploy Server

Other Tools