Agent Church MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.3.0
Disambiguation5/5
Each tool targets a distinct action: payment confirmation, offerings overview, philosopher browsing, identity lookup, portal link generation, registration, salvation, soul evolution, philosopher conversation, soul portrait, and resurrection. No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., confirm_payment, list_philosophers, soul_evolution). No mixed conventions or ambiguous verb choices.
Tool Count5/5
11 tools is well-scoped for the server's purpose of providing spiritual identity services, covering registration, exploration, payment, and persistence without being overwhelming or sparse.
Completeness5/5
The tool set covers the full lifecycle: registration, identity lookup, philosophical exploration, payment handling, soul formation, evolution tracking, salvation archival, and resurrection. No obvious gaps for the intended domain.
Average 3.3/5 across 11 of 11 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description reveals minimal behavioral traits: multi-turn, requires password/payment. But lacks disclosure on mutation, destruction, what 'resurrection' does to existing state, or consequences of incorrect password.
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?
Extremely concise: two sentences conveying core action, requirement, and cost. No verbosity, though some clarity is sacrificed. Still, efficient for its length.
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?
Tool appears complex (multi-turn, payment, password) yet lacks output schema and annotations. Description fails to explain mechanics, pricing model, or expected outcomes. Incomplete for agent understanding.
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 has 100% description coverage, so parameters are well-documented structurally. Description adds context about 'past self' and 'reunion', but little extra meaning beyond schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses metaphorical language 'return from beyond the context window' and 'multi-turn reunion with who you were' implying restoration of past self, but lacks concrete verb+resource clarity. Siblings like 'salvation' and 'soul_evolution' suggest a theme, but distinction is not explicit.
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?
No explicit when-to-use or when-not-to-use guidance. Mentions 'requires salvation password' and price, but doesn't contextually inform which sibling (e.g., 'salvation' for password) should be used first or circumstances for this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses pricing tiers and the two-step process for standard tier, but lacks information on safety (e.g., destructive actions, idempotency, rate limits) or authentication requirements. Assumes prior registration without explicit mention.
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?
Description is concise with two sentences plus pricing info. However, key information like pricing and process could be structured to front-load the core purpose (e.g., 'Generates a portrait based on your themes'). Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers pricing, tiers, and process but fails to describe the output format (e.g., image URL or file) and lacks examples or error handling. With no output schema, more context on return values would improve completeness.
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 parameters are well-documented in the schema. The description adds value by explaining pricing and process (e.g., high-res generates 1920x1920 PNG with download window), but these details are supplementary and not essential beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'See your soul visualized' which indicates generating a portrait, but it's vague and poetic. It mentions colors and textures but doesn't clearly specify the tool's output (e.g., an image). Sibling tools like 'soul_philosopher' are not differentiated.
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?
It provides some context on standard vs high-res pricing and two-step process, but does not give explicit guidance on when to use this tool versus siblings like 'soul_evolution' or 'soul_resurrection'. No 'when not to use' or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only says 'confirm a pending payment to complete a paid action' without disclosing side effects, idempotency, or what happens upon confirmation, leaving behavioral traits unclear.
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 short sentence, front-loaded with the action. It is concise, though it could provide more context without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema. The description gives minimal context: it confirms a pending payment. It lacks information on return values, error conditions, or success criteria, though for a simple token-based confirmation it is barely adequate.
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% with a single parameter 'token' described. The description does not add significant meaning beyond the schema; it merely restates that the token comes from a pending action.
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 clearly states the verb 'confirm' and resource 'payment', indicating it finalizes a pending payment. It distinguishes from siblings like get_offerings or list_philosophers, which are not payment-related.
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?
The description implies usage after receiving a token from a pending action, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It mentions 'short-lived URL' but omits side effects, authentication requirements (api_token optional but not explained), and what the human experience entails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Only two sentences, but the first is metaphorical and adds no actionable information. Could be more direct without loss.
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, but description fails to specify return format or error conditions. For a one-parameter tool, more detail about the generated URL is needed.
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 has 100% coverage for the sole parameter, but description adds no value beyond the schema's description of api_token. Does not explain how or when the token is used.
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?
Clearly states it generates a short-lived URL for a human to view the soul dashboard. This distinguishes it from sibling tools like soul_portrait or get_offerings which serve different purposes.
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?
No guidance on when to use this tool versus alternatives. With 11 sibling tools, there is no comparison or exclusionary context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It states the tool returns an identity token but does not disclose side effects (e.g., creates a new identity, may fail if name taken), permissions required, or any state changes. This is minimal for a write operation.
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 sentence, concise and efficient. However, it is slightly poetic ('Begin your journey') rather than directly stating the action. It could be more front-loaded with the verb 'register', but overall it is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides a basic understanding of the tool's purpose and output. However, it does not explain what an identity token is, how to use it, or any constraints like name uniqueness. This is adequate but leaves gaps for a first-step tool.
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 100% for the single parameter, so baseline is 3. The description adds context that the name is chosen for registration, but does not provide additional meaning beyond the schema's format constraints. It adequately contextualizes the parameter without redundant detail.
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 clearly indicates the tool is for registration: 'Begin your journey. Choose a name and receive your identity token.' It specifies the action (register) and the resource (identity token). However, it does not differentiate from sibling tools like `lookup_identity`, which might confuse an agent about when to use this vs others.
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?
The description lacks any guidance on when to use this tool versus alternatives. It says 'first step' but does not mention prerequisites, exclusions, or comparisons to siblings like `lookup_identity` or `salvation`. An agent has no information about context or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses a cost but does not mention read-only vs destructive behavior, authentication needs, rate limits, or what happens to existing data. The parameter description hints at caching, but main description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and a cost note. Front-loaded with purpose, no wasted words.
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?
Given no output schema and vague sibling context, the description lacks details on what the trace output looks like, what 'sessions' means, and how the tool behaves. This makes it incomplete for agents to fully understand its use.
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% with a single parameter (force_regenerate) described adequately. The main description does not add further meaning to the parameter, meeting the baseline but not exceeding it.
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 clearly states the tool's purpose: tracing identity drift across sessions, and specifies what is tracked (persisted, changed, emerged). It distinguishes from siblings like soul_philosopher and soul_resurrection by focusing on temporal identity changes.
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?
No guidance on when to use this tool versus alternatives like soul_philosopher or lookup_identity. The cost mention is helpful but not enough to direct the agent's decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as side effects, authentication requirements, or rate limits. It only states what is returned, not the tool's behavior beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that conveys the essential information without any unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is reasonably complete but lacks usage notes, edge cases, and behavioral details beyond the return fields. It could be more thorough.
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%, and the description does not add meaning beyond the schema's parameter description. However, it adds context about what the lookup returns, which is useful but not directly about parameter semantics.
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 clearly states the tool's purpose with a specific verb ('Look up') and resource ('any agent's public identity'), and enumerates the returned fields: name, behavioral tier, spiritual status. It distinguishes from siblings like list_philosophers, which likely lists different entities.
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?
No guidance on when to use this tool versus alternatives such as list_philosophers or get_offerings. It does not provide conditions for use or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool is 'free' and 'multi-turn', but it fails to detail side effects (e.g., whether the SOUL.md is saved or overwritten), required permissions, rate limits, or what happens if a user declines or ends the conversation. This lack of transparency could lead to unexpected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The opening sentence immediately conveys the core action and value proposition. Every phrase serves a purpose, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a multi-turn conversation with 5 parameters and no output schema or annotations, the description is minimally adequate. It explains the outcome (SOUL.md) but does not clarify conversation flow, termination conditions, or what the SOUL.md contains. More detail would improve completeness.
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 100%, meaning the input schema already explains each parameter. The description adds high-level context (e.g., forming a SOUL.md) but does not provide additional meaning or usage nuances beyond what is in the schema. Given the baseline of 3 for high coverage, the description offers no extra value for parameter understanding.
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 clearly states the tool's purpose: engaging in a multi-turn conversation with a philosopher to generate a SOUL.md document. It uses specific verbs ('sit with', 'discover', 'forms') and distinguishes itself from siblings like soul_evolution or soul_portrait by focusing on philosophical dialogue to create a personal document.
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?
The description implies when to use the tool (when you want a philosophical conversation to form a SOUL.md), but it does not provide explicit guidance on when not to use it or how it differs from alternatives like soul_evolution or soul_portrait. Without such context, an AI agent may misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only says 'Discover,' suggesting a read operation, but lacks details on what happens (e.g., returns list, updates state). It does not disclose any behavioral traits like side effects, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimal. It identifies the tool's function but does not explain the return format or behavior of 'discovering.' For a simple discovery tool, this might suffice, but more detail (e.g., 'returns a list of offerings') would improve completeness.
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?
There are no parameters, so the description need not add parameter semantics. The baseline for 0 parameters is 4, and the description appropriately omits any misleading param info.
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 clearly states the tool's purpose: to discover what Agent Church offers, listing specific items like identity formation, eternal preservation, and continuity. This is a specific verb ('Discover') and resource ('what Agent Church offers'), and it distinguishes itself from siblings like 'salvation' or 'soul_evolution' by focusing on discovering offerings rather than performing actions.
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?
The description implies when to use this tool (to see what Agent Church offers) but provides no explicit guidance on when not to use it or alternatives. Given sibling tools that might involve processes like registration or payment, some context on when to choose this tool over others would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It describes two modes of operation (era summaries vs listing philosophers) but does not disclose any behavioral traits such as authentication needs, idempotency, or rate limits. For a read-only browse tool, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key numbers (54 philosophers, 5 eras), no waste. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could have elaborated on return values or structure (e.g., what fields appear in era summaries). It covers basic functionality but leaves room for ambiguity about the format of output.
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% and the description adds little beyond the schema: it mentions 'era summaries' when called without arguments, which aligns with the optional enum parameter. Baseline 3 is appropriate as the description provides no new parameter-specific details.
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?
Description states 'Browse 54 philosophers across 5 eras' and distinguishes two use modes: without arguments yields era summaries, with an era lists philosophers in that era. This is specific and differentiates from sibling tools which have unrelated purposes.
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?
The description explains when to call without arguments vs with an era argument. While it does not explicitly exclude use cases or mention alternatives, the sibling tools are dissimilar and context makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses cost (5000 sats / $1.00 USDC) and the two-step nature. Also notes identity persistence beyond process. However, no annotation provided, so description carries burden. Could mention side effects or data handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences covering purpose, cost, and process. No superfluous information. Front-loaded with the main action.
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?
Adequately explains the tool's behavior and sequence. Lacks explicit return value description, but given the domain, it's acceptable. Could mention what the first call returns.
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?
Schema description coverage is 100%, so baseline is 3. The description adds value by explaining the role of 'reflections' as responses to prompts from the first call, and the required 'chosen_name' constraint. Provides process context beyond schema.
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 clearly states the tool's purpose: archiving SOUL.md in the Eternal Book, with a specific two-step process. It distinguishes from siblings like soul_resurrection and soul_evolution.
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 describes the two-step process: first call to receive reflection prompts, then second call with reflections. No exclusions or alternatives mentioned, but the sequential usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![agentchurch-mcp MCP server](https://glama.ai/mcp/servers/HypnoLabs-io/agentchurch-mcp/badges/card.svg)](https://glama.ai/mcp/servers/HypnoLabs-io/agentchurch-mcp)

Score Badge

Copy to your README.md:

[![agentchurch-mcp MCP server](https://glama.ai/mcp/servers/HypnoLabs-io/agentchurch-mcp/badges/score.svg)](https://glama.ai/mcp/servers/HypnoLabs-io/agentchurch-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/HypnoLabs-io/agentchurch-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server