Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@theosis-ancient-context-mcp search Coptic SCRIPTORIUM for 'Jesus'"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
FastMCP stdio service for ancient text corpora. Part of the Theosis ancient-context integration.
Corpus | Language(s) | Status | Licence |
TLA (Thesaurus Linguae Aegyptiae) | Egyptian | Remote/status-only | Free non-commercial research |
Coptic SCRIPTORIUM | Coptic | Local optional | CC-BY (exceptions exist) |
HPM/HDivT (Hittite ritual texts) | Hittite | Remote/status-only | Academic |
CUC (Copenhagen Ugaritic Corpus) | Ugaritic | Local optional | CC BY-NC 4.0 |
DASI | Arabic epigraphic | Remote/status-only | Academic |
OCIANA | Akkadian/Sumerian | Remote/status-only | Academic |
CDLI | Akkadian/Sumerian/Elamite | Remote/status-only | Open access |
DPPC | Phoenician/Punic | Deferred | Not published |
CIP | Punic | Deferred | Not published |
Related MCP server: DEFAIR MCP Server
DPPC and CIP are NOT integrated — no public API, data, or licence has been confirmed. They are registered as deferred with no scraper or adapter.
CUC is CC BY-NC and local-only — commercial use is prohibited. The adapter only works when CUC_CORPUS_DIR is configured to point at a local checkout of the corpus.
TLA, HPM, DASI, OCIANA are remote/status-only until a stable public API contract is verified. They return structured remote_only results with provenance envelopes.
CDLI is status-only until the REST JSON API shape is confirmed from cdli.earth/docs/api.
Coptic SCRIPTORIUM requires a local corpus directory. The adapter supports meta.json-backed metadata and bounded text-file search.
list_corpora — all registered corpus records with metadata
get_corpus_status(corpus) — detailed status, local path, availability
search_corpus(corpus, query, limit) — search with explicit status results
get_text(corpus, reference) — text retrieval with provenance envelope
get_text_metadata(corpus, reference) — metadata retrieval with provenance
# Install
uv sync --extra dev
# Run tests
uv run pytest -v
# Compile check
uv run python -m compileall src/theosis_ancient_context -q
# Run the server (stdio)
uv run python -m theosis_ancient_context# Coptic SCRIPTORIUM
export COPTSCRIPTORIUM_CORPUS_DIR=/path/to/corpora
# Copenhagen Ugaritic Corpus
export CUC_CORPUS_DIR=/path/to/cucAll results include a provenance envelope with:
source_layer — integration type (local_optional, remote_only, deferred, etc.)
corpus_id — canonical corpus identifier
source_url — upstream URL
licence — licence summary
licence_warning — detailed licence notes and restrictions
access_status — current integration status
Path traversal prevention for all local file access
Bounded search results and text retrieval
No persistent cache
No secrets required
No network requests in v0.1.0 (all adapters are local or status-only)
Get detailed status for a specific corpus.
Includes configured local path, availability checks, and version/commit info when discoverable.
| Name | Required | Description | Default |
|---|---|---|---|
| corpus | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does add behavioral detail: it reports configured local path, performs availability checks, and returns version/commit info only when discoverable. This conveys conditional, best-effort behavior beyond the schema, though it omits any discussion of permissions, side effects, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff: the first states the purpose, and the second enumerates the status contents. All text earns its place and is front-loaded around the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the description does not need to explain return values. Still, the lack of parameter semantics and absence of any guidance relative to sibling tools leave enough ambiguity that the description is only minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only repeats that the action applies to 'a specific corpus.' It does not clarify whether corpus expects a name, ID, path, or any format constraints, so the agent still lacks the semantic information needed to fill the parameter reliably.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get detailed status') on a specific resource ('a specific corpus'), which is clear and distinguishes it from list_corpora and search_corpus. It does not explicitly name sibling tools, so it loses the last point for explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: an agent can infer this tool is for examining one corpus rather than listing all corpora. However, there is no explicit guidance about when to choose this over list_corpora, search_corpus, or other siblings, and no mention of prerequisites or non-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve text content by reference identifier.
For local adapters, returns bounded text with provenance. For deferred/remote-only sources, returns explicit status.
| Name | Required | Description | Default |
|---|---|---|---|
| corpus | Yes | ||
| reference | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 does well by disclosing that local adapters return bounded text with provenance while deferred/remote-only sources return an explicit status, revealing behavior an agent cannot infer from the schema. It does not detail error semantics or size limits beyond 'bounded', but for a read-style retrieval tool this is meaningful disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, with the core action front-loaded and the conditional behavior kept in a compact second sentence. No filler, and each clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The existence of an output schema reduces the need to describe return values, and the adapter distinction adds useful context. However, with no annotations, one undocumented required parameter, and no usage guidance, the description is not fully self-sufficient for an agent deciding when and how to call it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no property descriptions, and the description only clarifies that 'reference' is an identifier; the 'corpus' parameter is left completely unexplained in terms of name, format, or relationship to reference. With 0% schema coverage, this partial compensation is insufficient to safely construct the two required arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses the verb 'Retrieve' with a specific object ('text content') and a retrieval key ('reference identifier'), making the tool's function immediately clear. It is implicitly distinguishable from siblings like search_corpus and get_text_metadata, but it does not explicitly call out those differences, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to prefer get_text over search_corpus or get_text_metadata, nor any exclusions or prerequisites. The adapter-dependent behavior (local vs deferred/remote-only) is stated, but it does not tell the agent which tool to select in a given scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve metadata for a text reference.
For local adapters, returns file metadata and provenance. For deferred/remote-only sources, returns explicit status.
| Name | Required | Description | Default |
|---|---|---|---|
| corpus | Yes | ||
| reference | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose meaningful behavioral variation: local adapters return file metadata and provenance, while deferred/remote-only sources return explicit status. It does not cover read-only guarantees or error behavior, but it adds substantive context beyond a simple 'get metadata' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose in the first sentence and necessary adapter-specific nuance in the second. There is no filler, repetition, or redundant restatement of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter metadata lookup with an output schema present, the description covers the core purpose and important adapter-dependent behavior. The main gaps are parameter clarification and explicit sibling routing, but the output schema reduces the need to describe return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain what 'corpus' or 'reference' mean, their formats, or how they relate. The parameter names are somewhat self-explanatory, but the description adds no semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb, 'Retrieve metadata', with a clearly identified resource, 'a text reference'. This differentiates it from sibling tools like get_text (content retrieval) and get_corpus_status (corpus-level status) without needing to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides conditional context for local adapters vs deferred/remote-only sources, which helps set expectations, but it does not explicitly say when to choose this tool over alternatives or when not to use it. Usage is implied rather than clearly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all registered ancient text corpora with metadata.
Returns registry records for TLA, Coptic SCRIPTORIUM, HPM/HDivT, CUC, DASI, OCIANA, CDLI, DPPC, CIP — each with source_type, language, period, access_status, source_url, licence notes, and integration notes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It clearly states that the tool returns registry records, enumerates the supported corpora, and lists the fields included, which is strong transparency for a read-only listing. It does not cover edge cases like missing data or response size, but those are less critical with an output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the purpose is stated first, and the second sentence adds enumerative detail without redundancy. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a parameterless list operation and an output schema exists, the description is complete: it specifies the universe of corpora and the metadata fields returned. The sibling tools are clearly different in function, so no additional disambiguation is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema already exhaustively documents the interface. The description adds no parameter detail, and none is needed; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and object: 'List all registered ancient text corpora with metadata'. Names the exact registry sources and fields, making the scope unmistakable and distinguishing it from sibling per-item tools like get_corpus_status and search_corpus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a full inventory of corpora is needed but does not explicitly contrast with siblings such as get_corpus_status or search_corpus, nor state when not to use it. Still, the 'list all' framing gives enough context for an agent to select it for broad enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search a corpus for a query string.
For enabled/local adapters, returns matching results. For deferred or remote-only sources, returns an explicit not_ready/remote_only result with provenance envelope rather than failing ambiguously.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| corpus | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses that deferred or remote-only sources return an explicit not_ready/remote_only result with a provenance envelope rather than failing ambiguously, which is non-obvious behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs: a one-sentence purpose statement followed by a focused behavior note. No filler; every sentence adds value and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core purpose and the special adapter behavior are covered, and an output schema exists, so return structure is not the description's job. However, with zero parameter documentation in the schema and no annotations, the missing limit semantics and lack of usage boundaries keep it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies that corpus is the target and query is the search string, but says nothing about limit or expected formats, leaving a required-capability gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'Search a corpus for a query string' names a specific verb and resource, and the tool name reinforces it. It is clearly distinct from siblings like list_corpora and get_text_metadata, though it does not explicitly call out any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool for querying a corpus, but it never says when to prefer it over alternatives or when not to use it. The adapter-mode information is behavioral rather than selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_corpus_statusget_textget_text_metadatalist_corporasearch_corpusScored across 5 tools
Each tool targets a distinct resource and action: listing all corpora, checking one corpus's detailed status, searching within a corpus, retrieving text content, and fetching text metadata. There is no meaningful functional overlap, and even the status-related tools are cleanly separated by all-versus-one scope.
All tools use a consistent verb_noun snake_case pattern: list_corpora, get_corpus_status, search_corpus, get_text, get_text_metadata. Plural and singular nouns are used naturally for collection-level versus single-item operations, so the naming is predictable.
Five tools is a well-scoped size for a read-only ancient-text corpus access server. Each tool earns its place in the workflow without redundancy or unnecessary surface area.
The tool surface covers the apparent domain completely: discover available corpora, inspect corpus status, search for texts, retrieve text content, and retrieve metadata. Deferred or remote-only sources are handled explicitly rather than resulting in dead-end errors, and no CRUD operations are expected for this read-only context.
Bible corpus MCP server: scripture, Greek/Hebrew interlinear data, cross-refs, semantic search.
Read-only scripture-study engine: complete-or-fail concordance over Greek NT, Hebrew OT, LXX.
Query SEC EDGAR filings, XBRL financials, and company data through MCP. STDIO & Streamable HTTP.
Read-only Wheel of Heaven corpus: myth search, primary texts, datasets, typed graph. CC0.
