EosLog Free Tools

Look up gas leaf blower rules

gas_leaf_blower_rules

Read-onlyIdempotent

Lists adopted local laws that ban or restrict gas leaf blowers in one US state, or one city or town in it, from EosLog's sourced table: the rule, when it took or takes effect and any later phases, who is cited, the penalty, and the official sources with the date each row was checked. Also reports a state law that blocks local bans (Florida, Georgia, Texas, Iowa, and Indiana). Without a city it lists every place in the state briefly; pass city for the full row. A place with no row may still have a rule EosLog has not confirmed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "state": "<state>"
    },
    "name": "gas_leaf_blower_rules"
  }
}

Input Schema

Name	Required	Description	Default
`city`	No	Optional city, town, village or county name, for example Los Angeles.
`state`	Yes	Two-letter code (CA) or full name (California). DC is included.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 20, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/closed-world, and the description adds real substance beyond them: the exact fields returned (rule, effective date and later phases, who is cited, penalty, official sources with per-row verification date) and the summary-vs-full-row behavior. The false-negative caveat ('a place with no row may still have a rule EosLog has not confirmed') is a genuinely valuable disclosure about result trustworthiness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then the returned fields, then the city/no-city behavior and the caveat. The first sentence is dense but each clause carries information; little is wasted, though it could be split for faster scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the burden of describing returns and does so thoroughly, plus coverage limits and the preemption-law edge case. An agent has everything needed to call it and interpret an empty result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds behavioral meaning to city that the schema does not: omitting it produces a brief per-place listing, supplying it produces the full row. State semantics are only implied (one state, DC included comes from the schema).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (lists) and a specific resource (adopted local laws banning/restricting gas leaf blowers) with an explicit scope: one US state, or one city or town within it. It also names the data source (EosLog's sourced table) and a secondary behavior (state preemption laws in FL, GA, TX, IA, IN), so there is no ambiguity about what the tool returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear guidance on how to call it: omitting city yields a brief list of every place in the state, while passing city returns the full row. The caveat that an absent row may still mean an unconfirmed rule is useful usage context, though there is no explicit when-not-to-use guidance (the sibling tools are unrelated, so this matters less).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All EosLog Free Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?