API Ninjas

getEarningsCallSpeaker

Read-only

Searches earnings-call speakers by name, company, analyst firm, role or type, or returns one speaker's profile, coverage and appearance history when id is given.

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

Input Schema

Name	Required	Description	Default
`id`	No	Resolved speaker_id. When provided, the endpoint returns that single speaker's profile, per-company coverage, and appearance history (detail mode). Search filters are ignored in detail mode, except ticker/year/quarter (which filter the appearance list) and limit/offset (which paginate it).
`name`	No	Substring match on the speaker's name (search mode).
`role`	No	Substring match on role/title (search mode).
`year`	No	Filter by fiscal year.
`limit`	No	Search mode: speakers per page (default 25, max 100). Detail mode: appearances per page (default 50, max 200).
`offset`	No	Number of results to skip for pagination. Default 0.
`ticker`	No	In search mode, restrict to people who appeared on this company's calls. In detail mode, filter the appearance list to this company.
`company`	No	Substring match on an executive's primary company (search mode).
`quarter`	No	Filter by fiscal quarter (1-4). In search mode, requires year.
`sort_by`	No	Sort field (search mode).	appearance_count
`sort_dir`	No	Sort direction (search mode). Defaults to desc, or asc when sort_by=name.
`analyst_firm`	No	Substring match on an analyst's firm (search mode).
`speaker_type`	No	Filter by speaker type (search mode).
`include_appearances`	No	When true (search mode), include each returned speaker's appearance list.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 9, 2026

TDQS

A3.9/5.0

Behavior3/5

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

readOnlyHint=true already establishes this as a safe read. The description adds that detail mode returns profile, coverage, and appearance history, which is useful behavioral context beyond annotations, but it omits return format, pagination semantics, and ordering behavior that the schema covers only partially.

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?

A single well-formed sentence that front-loads the verb and packs search fields plus the detail-mode trigger without filler. Slightly dense because it compresses two distinct modes into one clause, but nothing is wasted.

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 a 14-parameter dual-mode tool with 100% schema coverage and readOnlyHint, the description supplies the essential mode-switching logic. It stops short of describing sort defaults or appearance-list pagination, but those live in the schema, so nothing critical for correct invocation is missing.

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?

Schema description coverage is 100%, so every parameter (including the mode-dependent behavior of limit/offset and ticker/year/quarter) is already documented in the schema. The description's enumeration of filter fields (name, company, analyst firm, role, type) mirrors the schema without adding syntax or format detail, so the baseline 3 applies.

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 (searches/returns) and resource (earnings-call speakers), and cleanly distinguishes its two modes: filtered search vs. single-speaker detail when `id` is given. An agent can tell what this does without opening the 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?

The description makes the mode-selection rule clear ('when `id` is given' triggers detail mode, otherwise search filters apply). However, it names no alternatives among the many earnings-related siblings (getEarningsCallParticipants, searchEarningsTranscripts), so the agent gets context but no explicit when-not routing.

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

All API Ninjas 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?