Fetches recent earthquakes magnitude 2.5 or greater from USGS. Returns count and most recent quake details (magnitude, place, time). Cache TTL 2min. Use for disaster monitoring or when the agent needs current seismic activity.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds valuable context beyond annotations: the cache TTL (2 min), the return structure (count and most recent quake details), and the data source. This gives the agent important expectations about data freshness and output format.
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?
The description is two sentences, with no fluff. The first sentence states the core function, the second provides the usage context. Every word earns its place: magnitude threshold, source, return contents, cache TTL, and use case are all packed efficiently.
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?
For a zero-parameter, read-only tool with no output schema, the description is complete. It tells the agent what data is fetched (USGS earthquakes ≥2.5), what will be returned (count and most recent details), and the freshness constraint (cache TTL). The tool is simple enough that no further detail is necessary.
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?
The tool has zero parameters, so the description carries no parameter burden. It does explain the output (count and most recent quake details), which is helpful given the lack of an output schema. Baseline for 0 params is 4, and no deductions are needed.
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 uses a specific verb ("fetches") and resource ("recent earthquakes magnitude 2.5 or greater from USGS"), clearly stating the tool's scope. It distinguishes itself from siblings like tf_climate_earthquakes by naming the data source and magnitude threshold, making its purpose unambiguous.
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?
Provides explicit when-to-use guidance: "Use for disaster monitoring or when the agent needs current seismic activity." It does not explicitly mention when not to use it or alternative tools, but the context is clear and actionable.
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.
Most tools have clearly distinct purposes (e.g., tf_btc_price vs tf_fear_greed), but there is some overlap between free and premium aggregated tools (e.g., tf_briefing, tf_premium_briefing, tf_premium_agent_context). However, descriptions explicitly differentiate them by content and cost.
All tools follow a consistent pattern: 'tf_' prefix (with 'tf_premium_' for premium ones) and snake_case. Names are descriptive and predictable, e.g., tf_btc_price, tf_earthquakes, tf_premium_macro.
27 tools is on the high side, but the server covers a broad domain (crypto, finance, earthquakes, AI trends, payment system, etc.). Each tool serves a specific purpose, so the count is borderline acceptable but feels slightly heavy.
The tool surface covers a wide range of data feeds: crypto, forex, macro indicators, earthquakes, HN, HuggingFace, prediction markets, payment system, and service status. Minor gaps exist (e.g., no dedicated stock prices tool beyond premium macro, no weather), but overall it's comprehensive for a terminal feed.
