layer_infoGet an ArcGIS Feature/Map Service layer's schema by url: fields (name + type), geometry type, total record count, and capabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Feature/Map Service layer url, e.g. ".../FeatureServer/0". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating safe, repeatable operation. Description adds valuable context about what exactly is returned (fields, geometry type, etc.), which is not covered by annotations. 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?
Single sentence that is front-loaded with the main action and resource, then lists all returned elements. Every word is necessary; no fluff. Highly efficient.
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?
With no output schema, the description adequately lists the main returned components (fields, geometry type, record count, capabilities). Could mention error handling or format structure, but for a simple schema tool this is sufficient. Context signals (e.g., 1 param, no output schema) are properly addressed.
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?
Input schema has one parameter 'url' with a brief description. The description adds a real-world example and context ('by url'), enhancing meaning beyond the schema. Schema coverage is 100%, so baseline is 3; additional context justifies a 4.
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 verb 'Get' and resource 'ArcGIS Feature/Map Service layer's schema'. Lists specific returned information (fields, geometry type, record count, capabilities). Distinguishes from sibling tools like query_layer (queries data) and search_datasets (finds datasets) by focusing on schema retrieval.
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 explicit when-to-use or when-not-to-use guidelines. Usage is implied by tool name and description (for obtaining layer schema). Does not mention alternatives like query_layer for data queries, thus leaving ambiguity for the agent.
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.
While individual tool descriptions are detailed and specific, the set includes overlapping tools like ask_pipeworx and ask_pipeworx_grounded, and several prediction market tools with similar purposes (bet_research, polymarket_edges, polymarket_arbitrage). The broad range of unrelated domains means many tools are distinct, but some pairs are ambiguous.
Tool names use snake_case but follow no consistent pattern. Some are verb_noun (ask_pipeworx, query_layer), some noun_verb (ai_visibility_check, entity_profile), and some have inconsistent structure (discover_tools, recent_alerts). The mix of conventions reduces predictability.
33 tools is excessive for a server named 'Arcgis Tucson', as only 3 tools relate to ArcGIS (search_datasets, layer_info, query_layer). The rest span completely unrelated domains (Pipeworx data, Polymarket, memory, npm scanning, etc.), creating a severe mismatch between server name and tool functionality.
Considering the actual tool surface (a diverse data retrieval and prediction market analysis set), it is reasonably complete for common lookups (SEC, FDA, economics, news, bets). However, it lacks web search and the ArcGIS tools are minimal. The absence of a cohesive domain makes completeness hard to judge, but for the implied data-retrieval purpose, it's passable.