Skip to main content
Glama

Generate Kundli Matching Report (PDF or HTML)

astroway_reports_kundli_matching

The /vedic/compatibility/couple-report reading as an A4 PDF (default), HTML or Markdown: the summary (Guna Milan out of 36, Dashakoota out of 39, Porutham factors out of 10, doshas left uncancelled), the eight kootas with both partners' values, the ten Porutham factors with the essential ones marked, Mangal, Nadi and Bhakoot dosha with the rules that cancel them, the navamsa of both, and their Vimshottari periods side by side. chart1 is the groom and chart2 the bride, as on every /vedic/compatibility route; coordinates are required for both. No AI.

[Group: Reports] [Endpoint: POST /v1/reports/kundli-matching] [Required: chart1, chart2] [Cost: 5,000 credits (Tier 7)] ⚠️ Premium — ~50% of free monthly budget. Confirm with user before invoking.

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": {
      "chart1": "<chart1>",
      "chart2": "<chart2>"
    },
    "name": "astroway_reports_kundli_matching"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearsNoLength of the dasha window, 1 to 30 years. Default 10.
chart1YesGroom. Porutham counts from the bride's star to the groom's, as /vedic/compatibility/*.
chart2YesBride.
fieldsNoCompact mode: comma-separated dotted paths to keep, relative to `data`, e.g. "planets.name,planets.longitude,houses.cusp". Omit for the whole response.
formatNo`pdf` (default) stores a PDF and answers with its `url`. `html` returns one self-contained `text/html` document, `markdown` returns `text/markdown` with the same sections and tables; neither is stored. Same price in every format.
schoolNoPorutham school, default tamil.
fromDateNoStart of the dasha window, YYYY-MM-DD (UTC). Today when omitted.
languageNo
precisionNoCompact mode: round fractional numbers to this many decimals. Longitudes carry 14 by default; 2 is finer than any chart is drawn.
whitelabelNo
mangalSchoolNoHouses and reference points for Kuja dosha, default south.

Output Schema

NameRequiredDescriptionDefault
urlNo
expires_atNo
page_countNo
byte_lengthNo
duration_msNo
storage_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already flag a non-read-only, non-idempotent, open-world call, and the description adds genuinely new behavioral facts: 'No AI' (no model-generated narrative), the 5,000-credit Tier 7 price at ~50% of the free monthly budget, and the requirement to confirm before invoking. What it does not cover (whether the stored PDF URL expires, latency) is minor.

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?

The output format and resource identification are front-loaded, and each clause enumerating report sections carries information. The single very long sentence is dense but not padded; it could be split for readability but nothing is redundant.

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?

An output schema exists, so return-value explanation is not required, and the description covers purpose, contents, format routing, groom/bride convention, and cost/compliance. An agent could call this correctly from the description plus schema, with only minor ambiguity about when to prefer it over the raw JSON compatibility endpoints.

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 description coverage is 82%, so the schema already documents format, school, mangalSchool, fromDate, years and the chart objects. The description adds the fixed groom/bride assignment for chart1/chart2 and the note that coordinates are required for both, but that largely restates schema text ('Groom', 'Bride', 'coordinates are required here').

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?

States a specific resource (the /vedic/compatibility/couple-report reading) and the concrete artifact produced (A4 PDF by default, HTML or Markdown), then enumerates the report's sections. It never names the JSON sibling astroway_vedic_compatibility_couple_report or astroway_reports_synastry directly, so differentiation is implied rather than stated.

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

Usage Guidelines3/5

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

Usage context is implied by 'the reading as a PDF' and made explicit by the premium-cost warning ('Confirm with user before invoking'), which is real operational guidance. However, there is no explicit statement of when to choose this over the plain couple-report endpoint or the western synastry report, so the agent must infer the split.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources