astroway-mcp

Official

by astroway

Overview Schema Source Related Servers Discussions Admin

TypeScript

Remote

MCP Agent Debate

astroway_mcp_agent_debate

Read-onlyIdempotent

Simulate a structured multi-round debate between two named personas on a chosen topic, producing a transcript for comparison, analysis, and decision support.

Instructions

2 personas debate a topic, multi-round transcript.

[Group: MCP Advanced] [Endpoint: POST /v1/mcp/agent-debate] [Required: topic, agentA, agentB] [Cost: 100 credits (Tier 4)]

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": {
      "topic": "<topic>",
      "agentA": "<agentA>",
      "agentB": "<agentB>"
    },
    "name": "astroway_mcp_agent_debate"
  }
}

Input Schema

Name	Required	Description	Default
`chart`	No	Birth data for a single natal chart. Required: date (YYYY-MM-DD), time (HH:mm:ss), latitude and longitude in decimal degrees. The short forms lat, lon, lng and tz are rejected with 400 INVALID_FIELD; pass the full names. timezoneOffset is hours from UTC and defaults to 0, meaning UTC; send timezone instead (an IANA name such as Europe/Kyiv, or auto) and the offset for that date is worked out, summer time included. city is a display label only: nothing here geocodes it, so it never stands in for coordinates. houseSystem is a single house-system letter, P by default; a name such as "Placidus" is refused, and the case matters because I and i are two different Sunshine systems.
`topic`	Yes
`agentA`	Yes
`agentB`	Yes
`rounds`	No
`language`	No		en

Output Schema

Name	Required	Description	Default
`transcript`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.6.1Nov 9, 2026

changedInput schema / properties / chart / description

Previous value: -"Birth data for a single natal chart. Required: date (YYYY-MM-DD), time (HH:mm:ss), latitude and longitude in decimal degrees. The short forms lat, lon, lng and tz are rejected with 400 INVALID_FIELD; pass the full names. timezoneOffset is hours from UTC and defaults to 0, meaning UTC; send timezone instead (an IANA name such as Europe/Kyiv, or auto) and the offset for that date is worked out, summer time included. city is a display label only: nothing here geocodes it, so it never stands in for coordinates. houseSystem is a single Swiss Ephemeris letter, P by default; a name such as \"Placidus\" is refused, and the case matters because I and i are two different Sunshine systems."New value: +"Birth data for a single natal chart. Required: date (YYYY-MM-DD), time (HH:mm:ss), latitude and longitude in decimal degrees. The short forms lat, lon, lng and tz are rejected with 400 INVALID_FIELD; pass the full names. timezoneOffset is hours from UTC and defaults to 0, meaning UTC; send timezone instead (an IANA name such as Europe/Kyiv, or auto) and the offset for that date is worked out, summer time included. city is a display label only: nothing here geocodes it, so it never stands in for coordinates. houseSystem is a single house-system letter, P by default; a name such as \"Placidus\" is refused, and the case matters because I and i are two different Sunshine systems."

Addedv1.6.0Oct 24, 2026

TDQS

C2.9/5.0

Behavior3/5

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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuinely useful operational context the annotations do not: a 100-credit Tier 4 cost and the endpoint, plus the promise of a multi-round transcript. It stops short of saying what agentA/agentB must be (persona ids, names, or free-text personas), which is the main behavioral unknown for a generation call.

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?

One-line purpose followed by bracketed metadata is front-loaded and wastes little. The endpoint line earns its place less than the cost and required-field lines do, but overall it is tight rather than padded.

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?

An output schema exists, so return values need not be described, but the tool is not simple: 6 parameters, a nested required-subfield chart object, and an agent-identity ambiguity. For that complexity the description is too thin to let an agent construct a correct call without reverse-engineering the schema.

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

Parameters2/5

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

Schema description coverage is only 17% across 6 parameters (one a nested chart object), so the description must carry meaning — and it does not. 'Required: topic, agentA, agentB' merely restates the schema's required list, leaving agentA/agentB semantics, the rounds default/max, the language enum, and why a natal chart is accepted all unexplained.

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?

The description gives a concrete verb and resource — two personas debating a topic and returning a multi-round transcript — so an agent can predict the output shape. It does not, however, contrast itself with adjacent siblings such as astroway_mcp_multi_agent_coordinate, which an agent could easily mistake for the same operation.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance; the definition only lists required fields and pricing. An agent facing a 'two agents talking about a topic' request has no stated rule for picking this over multi-agent coordination or plain chat.

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

Deploy Server