turev_gostergelerMetalTakip tarafından hesaplanan oran ve prim göstergeleri: fiziki altın primi, dijital altın (PAXG) primi, çeyrek altın primi, altın/gümüş ve altın/Bitcoin oranları, resmi aylık fiziki akış serilerinin yıllık değişimleri. Ham üçüncü-taraf verisi içermez.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safe read operation. The description adds valuable context: data is calculated, not raw third-party, which helps agents understand the nature of the output. No contradictions.
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?
Two sentences, no wasted words. Lists specific indicators efficiently. Perfectly front-loaded with the key information.
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?
Given no parameters, readOnly annotations, and no output schema, the description provides adequate context by listing the indicators included. It fully informs an agent what the tool returns.
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?
There are zero parameters, so schema coverage is 100%. According to guidelines, baseline for 0 params is 4. The description does not need to add parameter details, and it does not.
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 clearly states the tool provides calculated ratios and premiums (türetilmiş göstergeler) from MetalTakip, listing specific indicators. It distinguishes itself from generic sibling tools (fetch, daily summary, search) by specifying derived data vs raw data.
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?
The description implicitly tells when to use (when derived indicators are needed) and what it excludes ('raw third-party data'), suggesting alternatives for raw data. However, it does not explicitly name alternative tools or provide when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: fetch retrieves full articles by ID, gunluk_ozet gives a daily summary, search finds articles, and turev_gostergeler provides computed indicators. No overlap in functionality.
The naming convention is inconsistent: 'fetch' and 'search' are English verbs, while 'gunluk_ozet' and 'turev_gostergeler' are Turkish noun phrases. No uniform pattern is followed.
With 4 tools, the server is well-scoped for a digest service. It covers the essential operations (search, retrieve, summary, indicators) without being too sparse or bloated.
The tool set covers the main workflow (search, fetch, daily summary, derived indicators) but lacks historical data retrieval, trend analysis, or user customization options, which are reasonable omissions for a digest server.