get_crosby_newsRecent local news headlines for Crosby, TX and nearby northeast Harris County communities, aggregated from public sources and filtered for relevance. Empty when nothing recent.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| source | No | ||
| updated | No | ISO 8601 timestamp of the last data refresh. | |
| location | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations: explains source (public sources, filtered) and behavior (empty when nothing recent). Annotations already indicate safety.
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 concise sentences front-loaded with core purpose, no fluff.
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?
Fully covers purpose, scope, and edge case (empty result). Output schema exists, so return details are not required.
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?
No parameters defined; baseline 4 applies as description need not add parameter info.
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?
Description clearly states it provides recent local news headlines for a specific geographic area, distinguishing it from sibling tools like get_alerts or get_traffic.
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?
Description implies usage for latest local news with an empty result when none recent. No explicit when-not or alternatives, but sibling context provides clarity.
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.
All tools have clearly distinct purposes: alerts, news, conditions, emergency contacts, forecast, radar, river levels, school events, traffic, and tropical outlook. There is no overlap or ambiguity.
All tool names follow the consistent pattern 'get_<topic>' using snake_case (e.g., get_alerts, get_forecast, get_radar). No deviations.
With 10 tools covering a broad range of local information (weather, alerts, news, emergency, traffic, schools, etc.), the count is well-scoped and each tool earns its place.
The tool set comprehensively covers the domain of local weather and community info for Crosby, TX: current conditions, forecasts, alerts, radar, river levels, tropical outlook, traffic, school events, news, and emergency contacts. No obvious gaps.