AstroCalc: Vedic astrology

Find a birth place

search_place

Read-onlyIdempotent

Finds a city or town and its coordinates, Indian places ranked first, from the same city list AstroCalc's kundli form uses. Useful before the birth-chart, matching or life-phase tools when a place name is ambiguous or misspelled (e.g. "Bombay", "Prayagraj", several towns with one name); pass the chosen label as place, or its lat and lon. Returns up to 5 matches with label, state, country, latitude and longitude.

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": {
      "query": "<query>"
    },
    "name": "search_place"
  }
}

Input Schema

Name	Required	Description	Default
`lang`	No	Language of the summary text: 'en' (default) or 'hi'.
`query`	Yes	Place name, optionally with state or country, e.g. 'Varanasi' or 'Aurangabad, Bihar'.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds real behavior beyond that: Indian results are ranked first, the underlying list is the same one the kundli form uses, and at most 5 matches come back.

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, then usage, then return shape, with no filler. It is dense, with the examples and downstream-passing note packed into one long sentence, but every clause earns its place.

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

Completeness4/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 correctly supplies the return contract: up to 5 matches with label, state, country, latitude, and longitude. It covers nearly all an agent needs, with the only gap being what lang actually affects in the response.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already explains query and lang. The description adds that the chosen label can be handed downstream as place or as lat/lon, which is useful cross-tool context, but it does not clarify the query format or the lang effect beyond the schema, and the place/lat/lon wording could be misread as parameters of this tool.

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 and resource: finds a city or town and its coordinates, drawn from the same city list the kundli form uses, with Indian places ranked first. That is enough to separate it from siblings such as free_kundli or kundli_milan, which consume a place rather than resolve one.

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?

Explicitly says to use it before the birth-chart, matching, and life-phase tools when a place name is ambiguous or misspelled, and names concrete examples ("Bombay", "Prayagraj", duplicate town names). No when-not guidance is given, but the upstream/downstream placement is clear.

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

All AstroCalc: Vedic astrology 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?