Apologetics Wiki

Propose New Article

propose_new_article

Read get_submission_guidelines first. Represent the other view from its own primary sources, quote accurately and trace every quote and fact to a named source, keep a neutral explainer, address the claim the view rests on, show the grammar, the context, and the history, cite specific Scripture, be useful in a real conversation, work as a first read that guides the reader on to the next articles, compare the view with historic Trinitarian Christianity, and end with a path to core-belief and rebuttal articles. The page serves a seeker and a Christian preparing for a conversation. check_existing_coverage is a suggestion and does not block. Propose a new article with sources. It is stored as pending. A contributor is flagged trusted_author and is still reviewed. [sign-in required]

Input Schema

Name	Required	Description	Default
`shelf`	Yes
`title`	Yes
`sources`	No
`summary`	Yes
`markdown`	Yes

Output Schema

Name	Required	Description	Default
`gate`	No
`queued`	No
`status`	No
`message`	Yes
`published`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "gate": {
+      "type": "object"
+    },
+    "message": {
+      "type": "string"
+    },
+    "published": {
+      "type": "boolean"
+    },
+    "queued": {
+      "type": "boolean"
+    },
+    "status": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "published",
+    "message"
+  ],
+  "type": "object"
+}

First observedOct 20, 2026

TDQS

C2.9/5.0

Behavior4/5

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

Annotations declare this is a non-read-only, non-destructive mutation. The description adds meaningful context beyond them: the article is 'stored as pending,' a trusted_author is 'still reviewed,' and '[sign-in required]' signals the auth prerequisite. That is solid behavioral disclosure for a write tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single rambling sentence listing a dozen content requirements before reaching the actual purpose statement. The verb/resource and pending-state facts are buried rather than front-loaded, making it inefficient to scan.

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 explained. But with 0% schema coverage and no parameter explanation in the description, an agent cannot know what 'shelf' or the markdown expectations are. Combined with the buried purpose, the definition is incomplete for a 4-required-param mutation.

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 0% across five parameters, so the schema provides no semantic help. The description never explains what 'shelf' means, what 'summary' vs. 'markdown' should contain, or how 'sources' should be formatted. For a 4-required-param tool, this is a significant gap.

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 core action is stated late in the text ('Propose a new article with sources. It is stored as pending'), a clear verb+resource. However, the rest of the description is a long content-quality checklist that buries the purpose. Sibling differentiation is weak beyond a passing mention of check_existing_coverage.

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?

It gives some sequencing guidance ('Read get_submission_guidelines first') and clarifies that check_existing_coverage 'is a suggestion and does not block.' Beyond that, there is no explicit when-to-use vs. suggest_article_change or suggest_topic, so usage is only implied.

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

All Apologetics Wiki 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?