Skip to main content
Glama
Sign In

Footprint

by io.github.TigerManOnFire
OverviewDiscussionsAdmin

Building growth, land rates and price outlook for one area

footprint_get_area
Read-onlyIdempotent

Report on the ~0.7 sq km area at a point in India: what land costs, how fast it is being built on, and the price outlook.

Use for questions like "how fast is Whitefield growing", "what is the govt. land rate in Karumuru", "is this locality built out". Give place or both lat and lon (coordinates are exact; a name takes the best match). Returns: price today and what kind of price it is (city-wide average, govt. plot rate, or none), price outlook per year with a 5-year range, share of ground built on, building growth over 5 years, building count and height, the state's govt. plot and farmland rates with their year, nearby asking prices where listed, a reliability grade, and a link to the area's page with the charts. Covers India only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "footprint_get_area"
  }
}

Input Schema

NameRequiredDescriptionDefault
latNo
lonNo
placeNoA place name, e.g. 'Whitefield Bengaluru'. Used when lat/lon are not given; takes the best match and says so if the name is ambiguous.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower; the description still adds real context: ~0.7 sq km spatial granularity, India-only coverage, and a reliability grade on results. It does not mention rate limits, ambiguity handling beyond the name-matching note, or failure behavior, so not a 5.

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 purpose in the first sentence, then usage examples, then input rules, then returns. The returns sentence is a long enumerated list but is justified given there is no output schema; a little tightening would help.

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

Completeness2/5

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

No output schema exists, so the description carries the burden of explaining return values, and it does enumerate them. However, key operational details for a geo lookup are missing: what happens when place is ambiguous or unmatched, what 'none' price means, whether results for ocean/multiple matches return errors, and how the reliability grade should be interpreted.

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?

Goes beyond the schema by specifying precedence and tradeoffs: coordinates are exact, a name takes the best match and flags ambiguity, and both lat and lon are needed together. That relationship and accuracy differential is not expressed by the schema alone, even though the schema already describes each parameter at some level.

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

Purpose4/5

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

Names a specific verb and resource: a report on a ~0.7 sq km area in India covering land cost, build-out pace, and price outlook. It is precise about the unit of analysis, which implicitly separates it from compare/top/search siblings, but it never names or contrasts those siblings explicitly.

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?

Gives concrete trigger questions ("how fast is Whitefield growing", "is this locality built out") and states the input condition: give `place` or both `lat` and `lon`. No explicit when-not or alternative-tool routing is provided, which keeps it below a 5.

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

All Footprint toolsInspect
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