Find Turkish companies, funds, portfolio management firms, and other KAP members by name. Filter results by entity type and active status for disclosure research.
Şirket, fon, portföy yönetim şirketi ve diğer KAP üyelerini arar.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| active_only | No | ||
| entity_types | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing. It does not indicate whether matching is exact/prefix/fuzzy, whether the search is case- or diacritic-insensitive, how pagination works with limit, or what active_only and entity_types actually filter. 'Search' implies a read, but that is the full extent of the behavioral signal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler or repetition. It is appropriately sized for a one-line description, though its brevity reflects under-specification rather than economy of expression.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, 0% schema coverage, and no annotations, the definition is too thin for the tool's complexity. An output schema exists so return values need not be described, but input semantics (query matching behavior, entity_types values, active_only default) remain entirely undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 4 parameters, so the description must compensate and does not. It broadly hints at the entity_types domain by listing companies, funds, and portfolio management companies, but gives no accepted values, no meaning for active_only, and no note that limit defaults to 20.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (arar / searches) and enumerates the resource domain: companies, funds, portfolio management companies, and other KAP members. This is enough to distinguish it from the singular sibling get_entity, though the plural form already implies the distinction and the description never names any sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of alternatives such as get_entity for a known identifier, and no statement of prerequisites. The only usage signal is the word 'search' versus the sibling names, which the agent must infer on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.