Skip to main content
Glama
hasancagrigungor

kapmcp

Search companies

search_companies
Read-onlyIdempotent

Find KAP members by ticker or name to retrieve their company_id for use with other KAP tools. Exact ticker matches rank first.

Instructions

Find KAP members (companies, funds' founders, brokers…) by ticker or name and get their company_id, which other KAP tools take. Exact ticker matches rank first. Use when the user names a company; use get_company for the full profile.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNo
queryNoTicker (THYAO) or part of the name, Turkish-insensitive. Omit to list by member_type.
offsetNo
member_typeNoFilter by KAP member type; IGS = listed companies

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.7/5.0
Behavior4/5

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

The annotations already cover readOnly, idempotent, openWorld, and non-destructive behavior. The description adds useful extra behavior: exact ticker matches rank first, and the returned company_id is consumed by other KAP tools. This goes beyond the structured annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the main purpose, then the output value, then the routing guidance. There is no filler or repetition of schema details.

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?

The tool has an output schema, strong annotations, and a description that explains purpose, usage conditions, result ranking, output relevance, and an alternative. Nothing an agent needs to decide whether to call this tool or how to use it effectively is missing.

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 50%, so the description does not fully carry the load, but it reinforces query semantics ('by ticker or name') and adds the ordering behavior ('Exact ticker matches rank first'). The remaining limit and offset parameters are self-explanatory with defaults in the schema, so the description does not need to add much.

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 description uses a specific verb ('Find'), names the resource ('KAP members'), and states the searchable fields ('ticker or name') and the key output ('company_id'). It clearly distinguishes itself from get_company by noting that get_company is for the full profile.

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 gives an explicit trigger condition: 'Use when the user names a company.' It also names the main alternative, get_company, and the condition that redirects the agent elsewhere, which is exactly the kind of routing guidance needed.

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