BoardroomList

Search senior roles

search_roles

Read-onlyIdempotent

Search open senior roles (Manager to C-suite) at the 500 largest US companies by words, seniority band, function, work mode, region, city or state, minimum salary and recency. Returns up to 25 roles a page with title, level, location, posted pay range, date and a link. Use it for "VP finance roles in Texas", "remote director of engineering jobs", "what CFO roles are open". Limitation: no company names; the role page shows them to members.

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": "search_roles"
  }
}

Input Schema

Name	Required	Description
`q`	No	Words to search titles, e.g. "CFO" or "VP supply chain".
`band`	No	Seniority: csuite, svp, vp, director, manager.
`mode`	No	Work mode.
`page`	No	Page number, 25 roles a page.
`sort`	No	senior (default), newest, or comp (highest pay first).
`region`	No	us = United States only, intl = outside the US.
`status`	No	open (default), new (7 days), today (24 hours), filled (last 30 days).
`function`	No	Job functions, e.g. Finance, Technology. Call list_filters for the full list.
`location`	No	A city or a US state, by name or code, e.g. Chicago, Texas, TX.
`min_comp`	No	Minimum posted salary in USD.
`posted_within_days`	No	Only roles first seen in the last N days.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 27, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the description's added value is the disclosure of page size (25 per page), the returned fields, and the key limitation that company names are withheld and non-filterable. It does not mention the page ceiling of 40 or result-count behavior.

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?

Front-loaded with purpose, then coverage, then return shape, then limitation — each sentence earns its place. The facet enumeration slightly duplicates schema properties but serves as a quick orientation.

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

Completeness4/5

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

For an 11-parameter, no-output-schema tool, it explains both input coverage and output fields, and flags the main surprise (no company names). Minor gaps: pagination limits and whether total counts are returned.

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 adds real semantics: default ordering implied, page size, and the fact that company is not a searchable dimension despite being returned later. Concrete query phrasings map facets to parameters.

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?

States a specific verb and resource ('Search open senior roles') plus a hard scope (Manager to C-suite at the 500 largest US companies) and enumerates the facets it searches. An agent can separate it from get_role (single role), list_filters (enum values) and search without opening a schema.

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?

Gives concrete example queries and an explicit boundary ('no company names; the role page shows them to members'), which implicitly routes the agent to the role page/get_role for company data. It stops short of naming siblings outright or saying when to prefer search vs search_roles.

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

All BoardroomList tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?