Skip to main content
Glama
onsecurity
by onsecurity

get-blocks

Retrieve reusable security finding templates containing standardized vulnerability descriptions, risks, and recommendations for security assessments.

Instructions

Get all blocks data from OnSecurity. Blocks are reusable security finding templates that can be used across different assessments. They contain standardized vulnerability descriptions, risks, and recommendations. Note that you can get how often a block is used, which is a way to get the most common findings ACROSS ALL CLIENTS ONLY as blocks are the basis of findings across pentests and scans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
round_type_idNoOptional round type ID to filter blocks, 1 = pentest round, 3 = scan round
approvedNoOptional filter for approved blocks only
automation_approvedNoOptional filter for automation approved blocks only
sortNoOptional sort parameter in format 'field-direction'. Available values: id-asc, round_type_id-asc, name-asc, approved-asc, used_count-asc, created_at-asc, updated_at-asc, id-desc, round_type_id-desc, name-desc, approved-desc, used_count-desc, created_at-desc, updated_at-desc. Default: id-asc
limitNoOptional limit parameter for max results per page (e.g. 15)
pageNoOptional page number to fetch (default: 1)
includesNoOptional related data to include as comma-separated values. Available: block_business_risks, block_field_variants, block_imports, block_references, block_remediations, block_target_types, block_variables, business_risks, remediations, revisions (e.g. 'block_business_risks,block_remediations')
fieldsNoOptional comma-separated list of fields to return (e.g. 'id,name,approved'). Use * as wildcard.
filtersNoOptional additional filters in format {field: value} or {field-operator: value} where operator can be mt (more than), mte (more than equal), lt (less than), lte (less than equal), eq (equals, default)
searchNoOptional search term to filter blocks by matching text

Implementation Reference

  • The main execution logic for the 'get-blocks' tool: constructs filters from parameters, fetches paginated blocks data via API, handles errors, formats output with pagination and block summaries, returns markdown text response.
    async (params) => {
        const filters: Record<string, string | number> = {};
        
        // Add additional filters if provided
        if (params.filters) {
            Object.entries(params.filters).forEach(([key, value]) => {
                filters[key] = value;
            });
        }
        
        // Add round_type_id filter if provided
        if (params.round_type_id) {
            filters['round_type_id-eq'] = params.round_type_id;
        }
        
        // Add approved filter if provided
        if (params.approved !== undefined) {
            filters['approved-eq'] = params.approved ? 1 : 0;
        }
        
        // Add automation_approved filter if provided
        if (params.automation_approved !== undefined) {
            filters['automation_approved-eq'] = params.automation_approved ? 1 : 0;
        }
        
        const response = await fetchPage<ApiResponse<BlockFeature>>(
            'blocks', 
            params.page || 1, 
            filters, 
            params.sort, 
            params.includes, 
            params.fields, 
            params.limit,
            params.search
        );
        
        if (!response) {
            return {
                content: [
                    {
                        type: "text",
                        text: "Error fetching blocks data. Please try again."
                    }
                ]
            };
        }
        
        const paginationInfo = formatPaginationInfo(response);
        const formattedBlocks = response.result.map(formatBlock);
        
        const responseText = [
            "# Blocks Summary",
            "",
            "## Pagination Information",
            paginationInfo,
            "",
            "## Blocks Data",
            ...formattedBlocks
        ].join('\n');
    
        return {
            content: [
                {
                    type: "text",
                    text: responseText
                }
            ]
        };
    }
  • Input validation schema using Zod for 'get-blocks' tool parameters: pagination (page, limit), sorting, filtering (round_type_id, approved, automation_approved, filters), includes, fields, search.
    {
        round_type_id: z.number().optional().describe("Optional round type ID to filter blocks, 1 = pentest round, 3 = scan round"),
        approved: z.boolean().optional().describe("Optional filter for approved blocks only"),
        automation_approved: z.boolean().optional().describe("Optional filter for automation approved blocks only"),
        sort: z.string().optional().describe("Optional sort parameter in format 'field-direction'. Available values: id-asc, round_type_id-asc, name-asc, approved-asc, used_count-asc, created_at-asc, updated_at-asc, id-desc, round_type_id-desc, name-desc, approved-desc, used_count-desc, created_at-desc, updated_at-desc. Default: id-asc"),
        limit: z.number().optional().describe("Optional limit parameter for max results per page (e.g. 15)"),
        page: z.number().optional().describe("Optional page number to fetch (default: 1)"),
        includes: z.string().optional().describe("Optional related data to include as comma-separated values. Available: block_business_risks, block_field_variants, block_imports, block_references, block_remediations, block_target_types, block_variables, business_risks, remediations, revisions (e.g. 'block_business_risks,block_remediations')"),
        fields: z.string().optional().describe("Optional comma-separated list of fields to return (e.g. 'id,name,approved'). Use * as wildcard."),
        filters: FilterSchema,
        search: z.string().optional().describe("Optional search term to filter blocks by matching text")
    },
  • src/index.ts:658-742 (registration)
    Registration of the 'get-blocks' tool on the MCP server, specifying name, description, input schema, and handler function.
    server.tool(
        "get-blocks",
        "Get all blocks data from OnSecurity. Blocks are reusable security finding templates that can be used across different assessments. They contain standardized vulnerability descriptions, risks, and recommendations. Note that you can get how often a block is used, which is a way to get the most common findings ACROSS ALL CLIENTS ONLY as blocks are the basis of findings across pentests and scans. ",
        {
            round_type_id: z.number().optional().describe("Optional round type ID to filter blocks, 1 = pentest round, 3 = scan round"),
            approved: z.boolean().optional().describe("Optional filter for approved blocks only"),
            automation_approved: z.boolean().optional().describe("Optional filter for automation approved blocks only"),
            sort: z.string().optional().describe("Optional sort parameter in format 'field-direction'. Available values: id-asc, round_type_id-asc, name-asc, approved-asc, used_count-asc, created_at-asc, updated_at-asc, id-desc, round_type_id-desc, name-desc, approved-desc, used_count-desc, created_at-desc, updated_at-desc. Default: id-asc"),
            limit: z.number().optional().describe("Optional limit parameter for max results per page (e.g. 15)"),
            page: z.number().optional().describe("Optional page number to fetch (default: 1)"),
            includes: z.string().optional().describe("Optional related data to include as comma-separated values. Available: block_business_risks, block_field_variants, block_imports, block_references, block_remediations, block_target_types, block_variables, business_risks, remediations, revisions (e.g. 'block_business_risks,block_remediations')"),
            fields: z.string().optional().describe("Optional comma-separated list of fields to return (e.g. 'id,name,approved'). Use * as wildcard."),
            filters: FilterSchema,
            search: z.string().optional().describe("Optional search term to filter blocks by matching text")
        },
        async (params) => {
            const filters: Record<string, string | number> = {};
            
            // Add additional filters if provided
            if (params.filters) {
                Object.entries(params.filters).forEach(([key, value]) => {
                    filters[key] = value;
                });
            }
            
            // Add round_type_id filter if provided
            if (params.round_type_id) {
                filters['round_type_id-eq'] = params.round_type_id;
            }
            
            // Add approved filter if provided
            if (params.approved !== undefined) {
                filters['approved-eq'] = params.approved ? 1 : 0;
            }
            
            // Add automation_approved filter if provided
            if (params.automation_approved !== undefined) {
                filters['automation_approved-eq'] = params.automation_approved ? 1 : 0;
            }
            
            const response = await fetchPage<ApiResponse<BlockFeature>>(
                'blocks', 
                params.page || 1, 
                filters, 
                params.sort, 
                params.includes, 
                params.fields, 
                params.limit,
                params.search
            );
            
            if (!response) {
                return {
                    content: [
                        {
                            type: "text",
                            text: "Error fetching blocks data. Please try again."
                        }
                    ]
                };
            }
            
            const paginationInfo = formatPaginationInfo(response);
            const formattedBlocks = response.result.map(formatBlock);
            
            const responseText = [
                "# Blocks Summary",
                "",
                "## Pagination Information",
                paginationInfo,
                "",
                "## Blocks Data",
                ...formattedBlocks
            ].join('\n');
    
            return {
                content: [
                    {
                        type: "text",
                        text: responseText
                    }
                ]
            };
        }
    );
  • Supporting function to format a single BlockFeature object into a human-readable markdown summary used in the tool's response.
    function formatBlock(block: BlockFeature): string {
        return [
            `Block ID: ${block.id}`,
            `Name: ${block.name}`,
            `Round Type ID: ${block.round_type_id}`,
            `Approved: ${block.approved}`,
            `Automation Approved: ${block.automation_approved}`,
            `Used Count: ${block.used_count}`,
            `Remediation Complexity: ${block.remediation_complexity || "N/A"}`,
            `CVSS Score: ${block.ratings?.cvss?.score || block.cvss?.score || "N/A"}`,
            `Executive Description: ${block.executive_description ? block.executive_description.substring(0, 200) + "..." : "N/A"}`,
            `Executive Risk: ${block.executive_risk ? block.executive_risk.substring(0, 200) + "..." : "N/A"}`,
            `Executive Recommendation: ${block.executive_recommendation ? block.executive_recommendation.substring(0, 200) + "..." : "N/A"}`,
            `Description: ${block.description ? block.description.substring(0, 200) + "..." : "N/A"}`,
            `Evidence: ${block.evidence ? block.evidence.substring(0, 200) + "..." : "N/A"}`,
            `Recommendation: ${block.recommendation ? block.recommendation.substring(0, 200) + "..." : "N/A"}`,
            `Created At: ${block.created_at}`,
            `Updated At: ${block.updated_at}`,
            `--------------------------------`,
        ].join('\n');
    }
  • Generic helper function for fetching paginated data from the OnSecurity API, constructing query parameters for filters, pagination, sorting, includes, fields, and search. Used by get-blocks handler.
    async function fetchPage<T>(
      basePath: string,
      page: number = 1,
      filters: Record<string, string | number> = {},
      sort?: string,
      includes?: string,
      fields?: string,
      limit?: number,
      search?: string
    ): Promise<T | null> {
      // Build query parameters
      const queryParams = new URLSearchParams();
      
      // Add page parameter
      queryParams.append('page', page.toString());
      
      // Add limit if provided
      if (limit) queryParams.append('limit', limit.toString());
      
      // Add sort if provided
      if (sort) queryParams.append('sort', sort);
      
      // Add includes if provided
      if (includes) queryParams.append('include', includes);
      
      // Add fields if provided
      if (fields) queryParams.append('fields', fields);
      
      // Add search if provided
      if (search) queryParams.append('search', search);
      
      // Add filters
      Object.entries(filters).forEach(([key, value]) => {
        queryParams.append(`filter[${key}]`, value.toString());
      });
      
      const url = `${ONSECURITY_API_BASE}/${basePath}?${queryParams.toString()}`;
      return await makeOnSecurityRequest<T>(url);
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that blocks are 'reusable security finding templates' and that usage counts reflect 'most common findings ACROSS ALL CLIENTS', which adds useful context about data scope and aggregation. However, it doesn't address critical behavioral aspects like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior (implied by 'limit' and 'page' parameters but not explained), or error conditions.

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 reasonably concise with three sentences that each add value: defining blocks, explaining their purpose, and noting the usage count feature. It's front-loaded with the core purpose ('Get all blocks data'). While efficient, the third sentence could be slightly more streamlined as it contains some redundancy ('across different assessments' and 'across pentests and scans').

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?

Given the complexity (10 optional parameters, no output schema, no annotations), the description provides adequate but incomplete context. It explains what blocks are and hints at usage analytics, but doesn't address the tool's behavioral characteristics, return format, or error handling. For a data retrieval tool with many filtering options, more guidance on result structure and limitations would be beneficial.

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?

The input schema has 100% description coverage, providing detailed documentation for all 10 parameters. The description adds minimal parameter semantics beyond the schema, only implicitly referencing 'used_count' through the mention of 'how often a block is used'. Since schema coverage is high, the baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding beyond what the schema already provides.

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?

The description clearly states the tool's purpose: 'Get all blocks data from OnSecurity' with a specific verb ('Get') and resource ('blocks data'). It explains what blocks are ('reusable security finding templates'), which helps distinguish them from sibling tools like 'get-findings' or 'get-rounds'. However, it doesn't explicitly differentiate this tool from its siblings in terms of when to use each.

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 provides some implied usage guidance by noting that blocks are 'the basis of findings across pentests and scans' and mentioning that 'you can get how often a block is used' to identify common findings across clients. However, it lacks explicit instructions on when to use this tool versus alternatives like 'get-findings' or 'get-rounds', and doesn't specify prerequisites or exclusions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/onsecurity/onsecurity-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server