Searches the local crypto RAG repository of news, analysis, and reports to retrieve relevant context for a query, with optional filtering by coin and result count.
Yerel RAG deposunda (haber, analiz, rapor) arama yapar.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| coin | No | ||
| query | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
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, yet it says nothing about ranking, whether raw chunks or synthesized answers are returned, latency/cost, or any auth requirement. For a RAG retrieval tool whose behavior varies significantly between implementations, this is a substantial gap.
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 efficient sentence with no padding, and the purpose is front-loaded. However, its brevity reflects under-specification rather than discipline, so it earns no more than an adequate mark.
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?
An output schema exists, so return values need not be explained. But with three undocumented parameters, no usage guidance, and no annotations, the definition is not sufficient for an agent to invoke this tool correctly in the presence of nine siblings.
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?
All three parameters (query, k, coin) have 0% schema description coverage and the description adds no meaning for any of them. In particular 'k' and 'coin' are opaque and entirely unexplained, leaving the caller unable to know that k is result count or that coin filters the corpus.
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?
States a specific verb ('arama yapar' / performs a search) and resource (the local RAG repository), with content types (news, analysis, report) narrowing the scope. This implicitly distinguishes it from sibling browse tools like list_reports or list_analyses, though no sibling is named 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?
No when-to-use guidance, no indication of when to prefer this search over deep_research, run_analysis, or the list_* siblings. The agent must infer that 'search' differs from 'list' on its own.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.