Skip to main content
Glama

governance

Read-onlyIdempotent

DEF 14A proxy data for US companies: board, named-executive pay, CEO pay ratio, say-on-pay. Three modes:

  • "snapshot" (default): one company's proxy, latest or for fiscal_year. "What does Apple's CEO earn?"

  • "trend": multi-year board composition and pay for one company.

  • "peer": rank an explicit peer set (companies) on one metric; there is no index or sector filter.

Args: company: Name, ticker or CIK; required for snapshot and trend. companies: Peer set (2+ names, tickers or CIKs); required for peer. fiscal_year: Snapshot / peer; omit for the most recent proxy. years / from_year / to_year: Trend rows (newest first, default 8, max 25) and fiscal-year bounds. metric: Peer: "ceo_pay_ratio" (default), "ceo_total_pay", "board_independence", "female_director_ratio", "median_employee_pay" or "sop_percent_for". direction: Peer: "desc" (default) or "asc".

Returns: Snapshot: {company_name, ticker, cik, proxy {fiscal_year, board, executive_compensation, insider_ownership, say_on_pay, ceo_pay_ratio, source_url}}. Trend: {..., trend[]}. Peer: {metric, direction, peers[], companies_not_resolved, coverage, missing}.

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

Input Schema

NameRequiredDescriptionDefault
modeNosnapshot
yearsNo
metricNoceo_pay_ratio
companyNo
to_yearNo
companiesNo
directionNodesc
from_yearNo
fiscal_yearNo

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, and the description is consistent with all of them. Beyond that, it discloses operational traits an agent needs: default row count (8), hard cap (25), newest-first ordering, default metric and direction, and that unresolved peers surface as companies_not_resolved/coverage/missing. It does not discuss failure modes for missing proxy filings or partial retrieval, which keeps 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?

Purpose and modes are front-loaded, and the Args/Returns blocks are scannable rather than prose-heavy. The Returns block partly duplicates the existing output schema, which is minor waste but also briefly names the non-obvious fields (coverage, missing) worth flagging.

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 9-parameter, three-mode tool with zero schema documentation, the description supplies mode selection, per-mode parameter requirements, defaults, limits, and a return-shape sketch. An agent has everything needed to construct a valid call in any mode without guessing.

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% across 9 parameters, so the description carries the full burden and does so with an Args block mapping every parameter to its mode and semantics. It even enumerates the six legal metric values and both direction values, which the schema does not constrain via enums.

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?

Opens with a specific verb+resource ('DEF 14A proxy data for US companies') and enumerates the exact data domains (board, named-executive pay, CEO pay ratio, say-on-pay). The three-mode breakdown lets an agent distinguish this from siblings such as get_ceo_barometer or compare_companies without inspecting 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?

Each mode is given a use case with a natural-language question ('What does Apple's CEO earn?'), plus per-mode required parameters. It explicitly bounds the tool with 'there is no index or sector filter', which routes agents with peer-set needs to the explicit-companies path rather than a guessed sector filter.

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.