Skip to main content
Glama
ty-meador

civ-v-llm-harness

by ty-meador

religion_overview

Retrieve faith totals, Great Prophet progress, pantheon and founded religions with beliefs, city followers and pressure, and auto-purchase options to plan religion strategy.

Instructions

Religion Overview screen: faith, next Great Prophet threshold, my pantheon/religion and beliefs, all founded religions with their beliefs and city counts, per own city the followers and pressure of each religion, and auto_purchase: the automatic faith purchase pull-down (current selection and every option it lists with its faith cost; change it with set_faith_purchase).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.11.0

TDQS

A4.2/5.0
Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. It implies a read-only overview by listing returned data and directing changes to set_faith_purchase, but it does not explicitly state that the tool has no side effects or what permissions/constraints apply.

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 description is a single, front-loaded sentence that lists the returned fields efficiently. It is dense but not padded, and the alternative tool for changing auto_purchase is placed at the end of the relevant clause.

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

Completeness5/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 must explain the return contents, and it does so comprehensively: faith, Great Prophet threshold, pantheon/religion beliefs, all founded religions with beliefs and city counts, per-city followers and pressure, and auto_purchase options with faith costs. This is complete for a parameterless overview tool.

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?

The tool takes no input parameters, so there is no parameter semantics to explain. The baseline for zero parameters is 4, and the description appropriately focuses on returned screen content instead.

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?

The description names the specific resource ('Religion Overview screen') and enumerates exactly what it contains: faith, Great Prophet threshold, pantheon/religion beliefs, founded religions, city followers/pressure, and auto_purchase options. It also distinguishes the mutation sibling by stating that auto_purchase can be changed with set_faith_purchase.

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?

It clearly indicates the tool is for reviewing religion data and explicitly routes the one mutation case to set_faith_purchase. It does not give broader when-to-use guidance against other religion tools such as found_pantheon or enhance_religion, but the context is clear.

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

Deploy Server

Other Tools