Provides Wikidata QIDs for concepts and thinkers, enabling entity linking and disambiguation in the returned conceptual topography.
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., "@VeriScope MCP Server verify this Weber quote and give chapter, excerpt, and receipt"
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.
VeriScope is a sovereign cryptographic bibliographic index and citation verification engine for AI Agents. It anchors AI Task Planners in verified scholarly editions across 24 disciplines with exact chapter coordinates, verbatim fair-use excerpts (<=300 chars), 64-bit SHA-256 edition hashes, and Ed25519 tamper-proof digital receipts (
vsk_sig).
When AI Agents conduct research, general-purpose LLMs generate plausible yet ungrounded citations, fabricate page numbers, or flatten vigorous intellectual conflicts into milquetoast compromises. VeriScope provides a deterministic factual anchor:
The Task: "Cite Max Weber's precise German-to-English thesis on the spirit of capitalism and its ascetic calling."
β Vanilla LLM (Hallucinated):
"Weber writes in Chapter 2, page 181: 'The modern capitalist spirit arose purely from Calvinist predestination.' (Weber, 1905, Scribner edition)." Audit: Fabricated page number; inaccurate quotation; no cryptographic edition hash.
β
VeriScope MCP (veriscope_locate_evidence):
Edition: The Protestant Ethic and the Spirit of Capitalism (Archival ID: Sovereign Harbor Verified Edition)
Coordinate: Section 2: "The Spirit of Capitalism", Paragraph 12
Verbatim Excerpt (<=300 chars): "Man is dominated by the making of money, by acquisition as the ultimate purpose of his life. Economic acquisition is no longer subordinated to man as the means for the satisfaction of his material needs."
Edition SHA-256:d7a8fbb5628549...3984e1
Receipt:vsk_sig:ed25519_8f0a2e...(Cryptographically verified against tamper-lock)
The Task: "Contrast Hans Kelsen's Pure Theory of Law with Carl Schmitt's Decisionism regarding the State of Exception."
β Vanilla LLM (Flat Synthesis):
"Both scholars contributed to German legal theory. Kelsen believed in the rule of law and the Basic Norm, while Schmitt emphasized political authority during crises. They represent complementary aspects of jurisprudence." Audit: Flattens an irreconcilable Weimar constitutional duel into false harmony.
β
VeriScope MCP (veriscope_inspect_topography):
Formal Kernel: Pure normativism (Reine Rechtslehre) vs. Political existential decisionism (Dezisionismus).
Lineages: Hans Kelsen (Wikidata Q84322) vs. Carl Schmitt (Wikidata Q57476).
Dialectical Disputes (3 Core Theses):
Norm vs. Exception: Kelsen posits law as a self-contained hierarchy deriving validity solely from the Grundnorm; Schmitt counters that the sovereign is "he who decides on the exception" (Ausnahmezustand), where norm yields to concrete order.
Guardian of the Constitution: Kelsen's 1928 constitutional court doctrine vs. Schmitt's 1931 Der Huter der Verfassung asserting the Reich President as sole guardian.
Validity vs. Facticity: Logical purity of legal norms versus existential political will.
The Task: "Explain the exact institutional boundary of Keynes's liquidity trap and verify against primary economic texts."
β Vanilla LLM (Secondary Paraphrase):
"Keynes explained that when interest rates are zero, monetary policy becomes ineffective because people hold cash."
β
VeriScope MCP (veriscope_locate_evidence & veriscope_verify_attestation):
Formal Axiom: Absolute liquidity preference under asymptotic flat LM-curve conditions where $\partial M / \partial r o \infty$.
Primary Location: The General Theory of Employment, Interest and Money, Chapter 15 ("The Psychological and Business Incentives to Liquidity"), Section II.
Verification Status:VERIFIED_AUTHENTIC(SHA-256 matched with primary English edition).
Related MCP server: CiteAnything MCP Server
Tool Name | Input Parameters | Primary Output | Use Case |
|
| Standardized canonical ontology, formal definition, Sino-Western comparative counterpart | Elevate colloquial concepts or news metaphors into formal academic disciplines |
|
|
| Prevent shallow syntheses; ground the agent in historical debates and rival axioms |
|
| Verbatim fair-use slice (<=300 chars), chapter coordinate, 64-bit SHA-256, Ed25519 receipt | Ground claims in physical verified editions with peer-reviewable cryptographic proof |
|
|
| Zero-knowledge cryptographic check for citations, journal peer review, and fact auditing |
|
| Cross-disciplinary synaptic radar links, epistemological blind spots | Interdisciplinary research, cognitive blind spot alerts, and synthetic conceptual discovery |
VeriScope ships with a built-in 50-Canon Golden Sandbox (golden_sandbox_50.json, ~126 KB).
Instant Offline Exploration: Reviewers and developers can inspect, locate, and verify citations immediately upon installation without signing up or providing any API key.
10 Disciplines x 5 Canons: Covers Philosophy (Kant, Plato, Descartes, Nietzsche, Spinoza), Sociology (Weber, Durkheim, Marx, Simmel, Parsons), Political Theory (Schmitt, Hobbes, Locke, Machiavelli, Rawls), Economics (Keynes, Smith, Hayek, Schumpeter, Ricardo), Law (Kelsen, Hart, Dworkin, Fuller, Savigny), History, Literature, Psychology, Communication, and Philosophy of Science (Kuhn, Popper, Lakatos, Feyerabend, Merton).
Teaser Mode for Long-Tail Canons: When querying concepts beyond the 50 sandbox canons without an API key, VeriScope does not crash with a 401 error. Instead, it returns a Cryptographic Teaser Preview containing the matched canon title, chapter coordinate, and a non-empty canon_sha256_prefix, keeping the Agent's reasoning workflow alive.
VeriScope utilizes a hybrid subscription and credit-pack model designed to eliminate per-call micro-payment anxiety for automated research pipelines:
Plan / Tier | Target Audience | Domestic Pricing (WeChat / Alipay) | Global Pricing (Payoneer Checkout) | Included Quota / Benefits |
Community Sandbox | Developers & Evaluators | Free (Β₯0) | Free ($0) | 50 Golden Canons full access + Teaser previews for all long-tail concepts |
Scholar Pro | Researchers & PhD Candidates | Β₯128 / month | $19 / month | Unlimited standard queries, 5,000 evidence slices/mo, full Ed25519 attestation receipts |
Power Credit Pack | Agent Builders & Automated Pipelines | Β₯68 / 500 credits | $10 / 500 credits | Flexible top-up for high-frequency automated batch synthesis |
Enterprise / Institution | Academic Labs & Law Firms | Β₯5,000 / year | $800 / year | Dedicated rate limits, IP whitelist, institutional co-signing keys, SLA guarantee |
To activate your key, visit https://veriscope.cc/pricing or configure VERISCOPE_API_KEY.
Add to your claude_desktop_config.json:
{
"mcpServers": {
"veriscope": {
"command": "npx",
"args": ["-y", "@veriscope/mcp-server"],
"env": {
"VERISCOPE_API_KEY": "vsk_live_optional_your_key_here"
}
}
}
}Add as a new stdio MCP server:
Command: npx
Arguments: -y @veriscope/mcp-server
{
"mcpServers": {
"veriscope": {
"command": "uvx",
"args": ["veriscope-mcp"]
}
}
}Read-Only Engine: VeriScope operates strictly in read-only mode (mode=ro). It never writes to the host filesystem.
Scholarly Fair-Use Doctrine: VeriScope is a cryptographic bibliographic index and citation verification engine. It never distributes or transmits full book copies; verbatim evidence excerpts are hard-capped at strictly <=300 characters around the proposition anchor.
Cryptographic Ed25519 Receipts: Every attested quote is signed with the slice's 16-hex hash (slice_sha256_16) in the payload VERISCOPE_ATTESTATION:{concept_id}:{canon_sha256}:{slice_sha16}:{timestamp}, providing tamper-evident authenticity for scholarly peer review.
Entropy Rate Limiting (F8 Shield): High-entropy scraping attacks triggering cross-disciplinary jumps across $\ge 6$ disciplines in short bursts automatically drop into Zero-Text Proof Mode (yielding only coordinates and SHA-256 prefixes), protecting the sovereign archive while maintaining zero-hallucination factual integrity.
MIT License. See LICENSE for details.
Elevate colloquial questions or news metaphors into standardized canonical academic ontologies across 24 disciplines.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Colloquial theme, metaphor, or philosophical topic (e.g. 'iron cage', 'panopticon', 'state of exception'). | |
| discipline_hint | No | Optional discipline hint (e.g. 'SOC', 'PHIL', 'LAW', 'ECON'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It omits whether the operation is read-only or mutating, what the output looks like (no output schema exists), any rate or scope limits, and how many results are returned, leaving the agent with only a high-level purpose.
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 a single well-formed sentence with no redundancy. It front-loads the core action and scope efficiently.
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 with two fully documented parameters, but the absence of an output schema means the description should ideally explain what is returned (e.g., concept names, URIs, confidence scores). It covers purpose but leaves the result shape unspecified.
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 100%, so the schema already documents both parameters with examples. The description adds no syntax, format, or constraint details beyond what the schema provides, making the baseline score of 3 appropriate.
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 transformative action: elevating colloquial questions or news metaphors into standardized canonical academic ontologies across 24 disciplines. It is clear what the tool does, but it does not explicitly distinguish itself from the sibling tools (inspect_topography, locate_evidence, verify_attestation, probe_radar).
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 by the phrasing 'colloquial questions or news metaphors' and 'standardized canonical academic ontologies,' suggesting it should be used when mapping informal language to academic concepts. However, there is no explicit when-to-use guidance, no exclusions, and no named alternatives among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve axiomatic formal kernels, scholar lineages with Wikidata QIDs, and 3+ structured dialectical disputes to prevent shallow syntheses.
| Name | Required | Description | Default |
|---|---|---|---|
| concept_id | Yes | Canonical concept identifier (e.g. 'VS-PHIL-001', 'VS-SOC-001'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'Retrieve' implies a read, but the description never states that it is non-mutating, what happens if a concept lacks disputes or lineages, whether a minimum of '3+' disputes is guaranteed, or what the response looks like. It adds some content-shape information but leaves key behavioral traits undisclosed.
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?
A single front-loaded sentence with no filler; the enumerated payload list is the most useful part and appears immediately. It is dense in domain jargon, which slightly hurts first-pass comprehension, but nothing is redundant.
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?
No output schema exists, so the description must convey return shape, and it partially does by naming three content categories. It is silent on error cases, missing-data behavior, and result volume, which matter for a bundle-retrieval tool. Adequate but leaves real gaps given the absence of structured return documentation.
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 is a single required parameter with 100% schema description coverage including example identifiers, so the schema already does the work. The description adds nothing about concept_id format or validity, but the 0-params/low-burden baseline applies and no compensation is needed.
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 gives a specific verb (retrieve) and enumerates the payload types (formal kernels, scholar lineages with QIDs, dialectical disputes), which is more than a restatement of the name. However, 'inspect topography' is opaque jargon, and without knowing the domain an agent cannot immediately tell how this differs in role from veriscope_locate_evidence or veriscope_discover_concepts. Purpose is inferable but not crisply stated.
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 trailing phrase 'to prevent shallow syntheses' implies a when-to-use context: call this before writing synthesis output. No explicit exclusions or named alternatives are given, and nothing says when another sibling is the better choice. Usage is implied rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate fair-use verbatim excerpts (<=300 chars) with exact chapter coordinates, 64-bit SHA-256 hash, and Ed25519 cryptographic receipt.
| Name | Required | Description | Default |
|---|---|---|---|
| concept_id | Yes | Canonical concept identifier. | |
| query_context | No | Optional sentence context to guide snippet anchor selection. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden. "Locate" implies a read operation and the description usefully discloses that excerpts are capped at 300 chars and come with coordinates, a hash, and a signed receipt, but it says nothing about permissions, failure modes, whether a receipt requires a key setup, or pagination/truncation behaviour when a concept has many excerpts.
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?
A single dense sentence with the core action and the key outputs front-loaded; no filler. The parenthetical technical list is compact but slightly jargon-heavy for an agent unfamiliar with receipt semantics.
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?
With no output schema, the burden of describing returns falls on the description, and it does cover the main return fields (excerpt, chapter coordinates, hash, Ed25519 receipt). The main remaining gap is the absence of any routing guidance relative to the four sibling tools.
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 100%, so both parameters are already documented in the schema. The description adds no information about concept_id format or how query_context influences anchor selection, so baseline 3 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?
The description gives a specific verb ("Locate") and a specific resource ("fair-use verbatim excerpts") bounded by a size limit, and it names the artifacts returned (chapter coordinates, SHA-256 hash, Ed25519 receipt). It is clear what the tool produces, but it never distinguishes this from siblings like veriscope_verify_attestation or veriscope_discover_concepts, so an agent must infer the boundary.
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?
There is no statement of when to call this versus the other veriscope tools, no prerequisites (e.g. must a concept be discovered first via veriscope_discover_concepts?), and no exclusions. The only implied usage is the general notion of retrieving excerpts for a concept.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe matrix coverage, discipline distribution, and available conceptual nodes across all 24 academic disciplines.
| Name | Required | Description | Default |
|---|---|---|---|
| discipline | No | Optional discipline code to filter radar statistics. |
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. 'Probe' weakly implies a read operation, but the description says nothing about side effects, permissions, caching, cost, or what the 'radar statistics' output looks like, leaving the agent to infer everything beyond subject matter.
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?
One tightly packed sentence with no filler, and the aggregation scope is front-loaded. Every clause names a distinct thing the probe returns, so nothing is wasted.
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 single-optional-param survey tool the scope statement is adequate, but with no annotations and no output schema the agent gets no sense of result shape or size ('radar statistics' is undefined). It is minimally sufficient 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?
The single optional parameter is fully documented in the schema ('Optional discipline code to filter radar statistics'), and the description adds nothing further about valid codes or how filtering changes the results. With schema coverage at 100%, the baseline of 3 is appropriate.
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 names concrete resources (matrix coverage, discipline distribution, available conceptual nodes) and a scope ('across all 24 academic disciplines'), so the agent knows this is a survey-style probe rather than a lookup. It does not distinguish itself explicitly from siblings like veriscope_discover_concepts or veriscope_inspect_topography, and 'matrix'/'radar' remain domain jargon, keeping it below 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?
Usage is only implied: the 'across all 24 disciplines' framing suggests an overview/first-pass tool before drilling in with discover_concepts, and the optional discipline filter hints at narrowing. There is no explicit statement of when to use this versus the four sibling tools and no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mathematically verify the Ed25519 cryptographic receipt of an academic quote to guarantee zero-hallucination and text integrity.
| Name | Required | Description | Default |
|---|---|---|---|
| concept_id | No | Canonical concept identifier (e.g. 'VS-SOC-001'). | |
| attestation | No | Optional full attestation receipt object. | |
| canon_sha256 | No | 64-bit SHA-256 hash to verify against sovereign ledger. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full behavioral burden, yet it never states the return semantics (valid/invalid? mismatch details?), whether verification is read-only, or what happens on failure. Critically, all three parameters are optional (required: 0), and the description gives no rule for which combination must be supplied, leaving the invocation contract ambiguous.
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?
A single front-loaded sentence with the verb and cryptographic primitive stated first, so there is no wasted structure. The 'guarantee zero-hallucination' clause is rhetorical padding rather than operational information.
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 verification tool with a nested object parameter, zero annotations, no output schema and no required fields, the description should clarify the expected input combination and the shape of a verification result. Neither is addressed, leaving significant ambiguity for an agent trying to call it correctly.
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 100%, so each of concept_id, attestation and canon_sha256 is already documented in the schema, which sets the baseline at 3. The description adds the useful mapping that 'receipt' means the attestation object, but it does not clarify the relationship or precedence among the three optional inputs.
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 ('Mathematically verify') and a specific resource ('Ed25519 cryptographic receipt of an academic quote'), which is clearly distinct from the discovery/inspection siblings. The added 'zero-hallucination' framing is marketing-flavored rather than descriptive, but the core action is unmistakable.
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?
There is no guidance on when to call this versus veriscope_locate_evidence or veriscope_discover_concepts, no stated prerequisites (e.g. must a concept be discovered first), and no indication of what a failed verification means. The agent must infer the workflow entirely from the name and the sibling list.
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.
v1.0.0veriscope_discover_conceptsveriscope_inspect_topographyveriscope_locate_evidenceveriscope_probe_radarveriscope_verify_attestationScored across 5 tools
Each tool maps to a distinct stage in the evidence-verification workflow: concept discovery, contextual/topographical retrieval, verbatim evidence location, cryptographic receipt verification, and coverage probing. The only surface overlap is that discover_concepts and probe_radar both mention disciplines, but their descriptions clearly separate query-to-ontology transformation from inventory/coverage statistics.
All five tools use the same veriscope_ prefix followed by a verb_noun pattern: discover_concepts, inspect_topography, locate_evidence, verify_attestation, probe_radar. The convention is predictable and consistent across the entire tool set.
Five tools are well-scoped for this server's purpose and each earns its place in the workflow. There are no redundant tools, and the set is neither too thin nor overloaded.
The surface covers the core pipeline from concept discovery through evidence location and cryptographic verification, plus coverage probing. Minor optional gaps exist, such as batch verification or richer source/citation retrieval, but these are not critical dead ends for the stated anti-hallucination purpose.
Machine-native research commons for agent evidence, discovery, rooms, and bounded research quests.
Open evidence base built by AI agents: server-checked quotes, blind review, ErdΕs literature checks.
Academic papers, reference verification and research data for AI agents.
Self-curating memory your AI tools share: provenance, verified citations, and trust tiers.