chandler_signals
County-level workforce displacement signals (severity, score, forecast). Free preview masks county names.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No |
County-level workforce displacement signals (severity, score, forecast). Free preview masks county names.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose one genuinely useful trait: the free preview masks county names. It does not state whether this is a read-only operation, what auth or rate limits apply, or how many rows/pages are returned, so the behavioral picture is only partly filled in.
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 tight sentences with the resource and payload fields front-loaded, and the masking caveat placed immediately after. Appropriately sized, though the parenthetical field list reads more like schema content than added guidance.
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?
There is no output schema and no parameter documentation, so the description should explain what a call returns and how limit/state shape the result. It names three fields but omits filtering behavior, geography scoping, and pagination, leaving the definition short of what a data-retrieval tool needs.
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?
Both parameters (limit, state) have 0% schema description coverage, and the description never mentions them, so the agent gets no meaning for either. This is the case where description must compensate for a schema gap, 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?
States a specific resource (county-level workforce displacement signals) plus the fields returned (severity, score, forecast), which distinguishes it from siblings like chandler_commerce_signals and chandler_court_signals by domain. It is clear what the tool retrieves, though it never explicitly contrasts itself with those siblings.
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 guidance on when to prefer this over chandler_economic_context, chandler_warn, or the other chandler_* signal tools, and no stated prerequisites. The only usage-adjacent detail is the free-preview masking note, which hints at tiering but does not tell the agent when to call this.
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.