Skip to main content
Glama

get_sector_peer_set

Read-onlyIdempotent

Return a curated peer set for a sector/country workflow.

Coverage today: one preset, nordic-construction (Finnish and Swedish listed construction companies). There are no US presets yet — for US peer groups use screen_companies (index="sp500" / industry / tag_slugs) or pass an explicit list to compare_companies / screen_metric_trend. Any other sector or countries=["US"] returns sector_preset_not_found with the available presets.

Args: sector: Sector key. Currently "construction" maps to the curated nordic-construction preset when FI/SE/Nordic countries are requested. countries: Optional country filter, e.g. ["FI", "SE"]. The returned peer set is filtered to these countries when provided. preset: Optional explicit preset slug, e.g. "nordic-construction".

Returns: {sector_scope, peer_set, available_presets}. peer_set entries include input, resolved_name, ticker, country, sector_tag, resolution_source and resolution_status so the caller can audit the universe before running comparisons.

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

Input Schema

NameRequiredDescriptionDefault
presetNo
sectorNoconstruction
countriesNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description still adds real behavioral context beyond that: single-preset coverage today, the exact error identifier sector_preset_not_found returned with available presets, and the resolution_status/resolution_source fields for auditing. It does not cover latency or size of returned peer sets, keeping it short of a 5.

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?

It is front-loaded with purpose and coverage, then uses Args/Returns blocks that are easy to scan, and every section earns its place. There is minor redundancy between the coverage paragraph and the sector arg description restating the nordic-construction mapping.

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?

For a three-optional-parameter read tool this covers purpose, valid inputs, failure mode, and alternative routes; even though an output schema exists, the Returns note adds useful audit-field context rather than duplicating a type signature. An agent has everything needed to call it correctly or route elsewhere.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must carry all parameter meaning and it does: sector lists the currently valid key and its default mapping, countries is explained as an optional filter on the returned set, and preset is described as an explicit slug override with an example. That fully compensates for the undocumented schema.

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 opening line states a specific verb and resource ("Return a curated peer set for a sector/country workflow") and the coverage paragraph makes clear this is a preset-backed lookup, not an arbitrary screener. It explicitly contrasts with screen_companies and compare_companies, so an agent can distinguish it from siblings without reading their schemas.

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

Usage Guidelines5/5

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

It states exactly when this tool applies (FI/SE/Nordic construction via the nordic-construction preset) and when it does not ("There are no US presets yet"), naming screen_companies with concrete arguments as the alternative. It also documents the failure path so an agent knows the outcome of an out-of-scope call.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.