Skip to main content
Glama
CallMarcus

SecurityScorecard MCP Server

by CallMarcus

Asset Discovery

discover_assets

Identify domains and IPs with security risk context and data completeness validation. Use it to build asset inventories and assess exposure.

Instructions

🔍 ASSET INVENTORY: Discover domains and IPs with security context and data completeness validation. INTELLIGENT RESPONSES: Use 'minimal' for simple questions like 'how many assets?' (20-50 tokens). Use 'standard' for asset overview (200-400 tokens). Use 'detailed' for comprehensive inventory.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoParent domain to discover assets forexample.com
response_modeNoResponse detail levelminimal
include_risk_detailsNoInclude security risk information

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv1.1.1

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full disclosure burden. It never states that this is a read-only operation, whether any authentication or scope is required, whether results are paginated, or how the 'security context' is sourced. 'Discover' implies a safe read but that is left to inference.

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

Conciseness3/5

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

Short overall, but padded with all-caps headers, an emoji, and a self-congratulatory 'INTELLIGENT RESPONSES' label that carry no information. The useful content (mode selection) sits after the fluff rather than being front-loaded.

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

Completeness3/5

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

For a 3-parameter, zero-annotation, no-output-schema tool, the description covers response sizing well but omits the operation's safety profile and return shape, and the schema's placeholder default domain ('example.com') is unexplained. Enough to call the tool, but not enough to call it confidently.

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%, so the baseline is 3, but the description goes beyond the schema for response_mode: the schema only says 'Response detail level' while the description gives concrete token budgets (20-50 / 200-400 tokens) and matching question types. Domain and include_risk_details still get no extra meaning.

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

Purpose4/5

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

States a concrete verb+resource ('Discover domains and IPs') and adds scope ('security context and data completeness validation'), so the agent knows this is an asset inventory operation. However it never distinguishes itself from close siblings such as api_discovery or validate_data_completeness, and the 'data completeness validation' phrase actively overlaps with the latter.

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 clear guidance for one parameter (which response_mode to pick for which question type), which implies the tool is for inventory/summary queries. It never says when to choose this tool over the sibling discovery or validation tools, so the alternative-selection guidance is absent.

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