Edgepedia

by ai.edgechat

Overview Discussions Admin

Server Details

Search and read Edgepedia, a free and growing encyclopedia with citations. No key.

Ownership verified

Status: Healthy
Uptime: 100.0% over 26 days
Last Tested: 2026-10-15 09:19
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: EdgePlat/edgepedia-mcp
GitHub Stars: 0
Server Listing: Edgepedia MCP Server

TDQS

A4.2/5.0

Scored 2026-10-07 22:50 across 5 tools

Disambiguation4/5

Each tool has a largely distinct role: search (name-to-facts lookup), resolve (name disambiguation with confidence and alternatives), fetch (read an article), related (nearby articles), connect (link-chain pathfinding). The only friction is between search and resolve, which both map a name to an article, though the descriptions distinguish text-context disambiguation from general fact lookup well.

Naming Consistency4/5

Four tools are single lowercase action verbs (connect, fetch, resolve, search), which is consistent. 'related' is a mild deviation since it reads as an adjective rather than a verb, but it still fits the terse, predictable single-word style.

Tool Count5/5

Five tools is well-scoped for a read-only encyclopedia server, and each tool earns its place: discovery, disambiguation, reading, browsing, and navigation are all covered without redundancy.

Completeness4/5

The surface covers the full read lifecycle: finding articles (search), resolving ambiguous names (resolve), reading them (fetch, including topic trees), and exploring adjacency (related, connect). Minor gaps exist, such as no dedicated topic-listing or citation-only tool, but topic:root plus fetch largely compensate.

Available Tools

5 tools

connectConnect two Edgepedia articlesA

Read-onlyIdempotent

Inspect

Find the shortest chain of in-text links from one Edgepedia article to another (at most 6 hops), with the sentence that makes each hop; pass two ids as search returns them.

ParametersJSON Schema

Name	Required	Description	Default
`to`	Yes	The target article, named the same ways.
`from`	Yes	The starting article's id (such as "koala"), its ep… id, or its title.

Output Schema

ParametersJSON Schema

Name	Required	Description
`to`	Yes
`from`	Yes
`hops`	No
`path`	No
`text`	Yes
`found`	Yes
`steps`	No
`reason`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds real behavior: a hard bound of at most 6 hops and the fact that each hop is returned with the sentence that justifies it, disclosing the shape of the search rather than just its existence.

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?

A single front-loaded sentence with the action and constraint stated before the input-sourcing clause. No filler, no redundancy with the title, and the flow constraint (6 hops) is not buried.

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?

An output schema exists, so return-value explanation is not required, and the description still summarizes it briefly. Combined with annotations and a fully documented schema, an agent has what it needs, though it never states what happens when no chain exists within 6 hops.

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 coverage is 100%, so the baseline is 3. The description goes beyond the schema by clarifying that both arguments are ids obtained from `search`, which tells the agent where to source valid values rather than guessing at titles or slugs.

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?

Specific verb+resource: 'Find the shortest chain of in-text links from one Edgepedia article to another' states exactly what the tool does. It differentiates itself from siblings by tying its input to `search`'s output ('pass two ids as search returns them'), so an agent can distinguish it from fetch/related/resolve/search without opening schemas.

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?

Gives clear context for use: call `search` first, then pass the returned ids. It implicitly positions the tool after search in a workflow, but offers no explicit exclusions (e.g., when to prefer `related` or `resolve` instead), so it falls short of a 5.

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

fetchFetch an Edgepedia articleA

Read-onlyIdempotent

Inspect

Read an encyclopedia article in full: one Edgepedia article as Markdown with its citations, by a search result's id. Returns id, title, text, url, and metadata (topic path, license, credit). A topic: id lists that topic's parent, narrower topics, and articles, 120 a page; topic:root is the top of the tree, topic:geo the geography tree. citations: false gives [n] markers instead of inline source links. Show the credit line with any text you quote.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	The id of a search result (the last part of the article's address, such as "mount-fuji", or a topic's "topic:…" id).
`ids`	No	More ids to fetch with `id` in one call, up to 10 in all.
`cite`	No	Add a reference in this format (csl, bibtex, ris, apa, mla, chicago, harvard).
`page`	No	A topic only: which page of its articles, from 1.
`links`	No	Add the articles linking here (in), the links it makes (out), or both.
`query`	No	Only the 3 passages that best match these words, each with a `cite_url`.
`quote`	No	A sentence from the article, or a chunk id: adds a `cite_url` that opens the page at it.
`chunks`	No	true = the text as paragraphs with stable ids, in `chunks`.
`cursor`	No	Where to continue, from a cut text's `next_cursor`.
`format`	No	The text as plain text, HTML, JSON-LD, or Turtle instead of Markdown.
`length`	No	snippet or lead for a short text; full (default) for the whole article.
`tables`	No	true = add the article's tables as JSON and CSV.
`outline`	No	true = add the list of the article's headings.
`section`	No	Only this section, by its heading ("Etymology", "History").
`citations`	No	Default true. false = [n] markers instead of inline source links; the numbered reference list stays.
`links_page`	No	With links "in" or "both": which 30 articles linking here, from 1.
`max_tokens`	No	Cut the text at a section boundary to about this many tokens; pass `next_cursor` as `cursor` for the rest.

Output Schema

ParametersJSON Schema

Name	Required	Description
`id`	No
`url`	No
`text`	No
`title`	No
`results`	No	With `ids`: one entry per id, in order: that fetch's answer, or { id, error: { code, message } }.
`metadata`	No
`moved_from`	No	The id asked for, when the article has since moved; store `id` or `canonical_id` instead.
`canonical_id`	No	The article's permanent id (ep…); `fetch` takes it, and it outlives an address change.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description goes further by disclosing the return shape, that topic ids page 120 at a time, how `citations: false` changes output, and the licensing obligation to show the `credit` line. It stops short of discussing truncation/cursor behavior, which lives only in the schema.

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?

Purpose and return fields are front-loaded, then progressively more specialized behaviors. Dense and largely earned, though the middle sentences pile several distinct features (topic paging, citations, credit) into a run that could be split.

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?

With 17 params at full schema coverage and an output schema, the description needn't enumerate returns, yet it does enough to orient the agent (Markdown body, citations, topic listing). It omits explicit when-to-use guidance relative to the four siblings, which is the remaining gap.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: the `topic:` id convention with concrete examples (`topic:root`, `topic:geo`), the 120-per-page default, and the behavioral contract of `citations: false`. These go beyond the terse schema strings.

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?

States a specific verb (read), resource (an Edgepedia article), scope (in full, as Markdown with citations) and ties the input to a sibling ('by a `search` result's id'). An agent can tell this apart from search/related/resolve without opening the schema.

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 implies the workflow (get an id from `search`, then fetch it) and explains topic: ids and the citations flag, but never states when to prefer this over siblings like `related` or `resolve`, nor any exclusions. Usage is implied rather than prescribed.

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

relatedRelated Edgepedia articlesA

Read-onlyIdempotent

Inspect

Find encyclopedia articles related to an Edgepedia article: its topic-mates, a few from each neighboring topic, and its geography neighbors. Pass its id, as for fetch. Returns groups of results; fetch a group's topic id for more.

ParametersJSON Schema

Name	Required	Description	Default
`by`	No	"links" = articles cited together with it, and articles linking to what it links to.
`id`	Yes	An article's id, as `search` returns it (such as "mount-fuji").

Output Schema

ParametersJSON Schema

Name	Required	Description
`by`	No
`id`	No
`geo`	No
`url`	No
`title`	No
`cocited`	No
`coupled`	No
`cousins`	No
`siblings`	No

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety bar is covered. The description adds real behavioral context beyond that: results come back grouped, and each group is a `topic` id that can be fetched for more.

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?

Three tight sentences front-load the purpose, then the input convention, then the follow-up. The phrase 'a few from each neighboring topic' is slightly loose but informative rather than filler.

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?

An output schema exists, so return values need not be spelled out, and the description still adds the grouping and pagination-by-topic follow-up. Complete enough for a 2-param read tool with full schema coverage.

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%, so `id` and `by` are already documented in the schema. The description reinforces the `id` convention ('as for `fetch`') but says nothing about `by`, so it adds only marginal value over the structured fields – baseline 3.

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?

Specific verb+resource ('find encyclopedia articles related to an Edgepedia article') and it concretely decomposes 'related' into topic-mates, neighbors, and geography neighbors. It also names the sibling `fetch` for the id convention, so an agent can place it among the siblings without opening schemas.

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?

Clearly implies the retrieval context and gives a concrete chaining rule ('fetch a group's `topic` id for more'), plus the 'id as for `fetch`' convention. It does not explicitly contrast with `connect` or `search`, so exclusions are absent.

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

resolveResolve a name to an Edgepedia articleA

Read-onlyIdempotent

Inspect

Find which encyclopedia article a name means: Edgepedia's best match for a person, place, thing, or concept named in a text, with a confidence, whether the name is ambiguous, and the alternatives. Pass the name ("Mercury"), and optionally words from the text around it (context: "planet orbit") or a topic id the article must sit under (type). Returns result (id, title, url) and alternatives; pass an id to fetch.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name as the text gives it.
`type`	No	Only articles under this topic id (as `fetch` topic:… names it, without "topic:").
`limit`	No	Candidates to return, 1 to 10 (default 5).
`context`	No	Words from the text around the name, which favor the article they fit.

Output Schema

ParametersJSON Schema

Name	Required	Description
`match`	Yes
`query`	Yes
`result`	Yes
`ambiguous`	Yes
`confidence`	Yes
`alternatives`	Yes

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive (and closed-world), so the safety profile is covered. The description adds real behavioral context beyond them — that the result carries a confidence and an ambiguity flag, and that a ranked `alternatives` list comes back — which helps the agent interpret output.

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?

Dense but front-loaded: the core purpose leads, then a single sentence covers inputs and one covers output/resumption. It is slightly long with parenthetical examples, but no sentence is redundant.

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?

For a 4-param, output-schema-backed lookup tool, everything needed to call it correctly is present: required vs optional params, their interaction, and the downstream handoff to `fetch`. Return-value detail is a bonus rather than a necessity.

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 coverage is 100%, so the baseline is 3. The description earns above baseline by giving concrete examples ('Mercury', `context`: "planet orbit") and by clarifying that `type` uses the same topic id that `fetch` names as `topic:…`, cross-linking the two params' 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?

States a specific verb and resource — resolving a name to an Edgepedia article — and immediately differentiates itself from siblings by framing the task as disambiguation (best match, confidence, ambiguity, alternatives). An agent can tell this apart from `search`, `fetch`, `connect`, or `related` without opening any schema.

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?

Gives clear usage context: pass a name from a text, optionally with surrounding words or a topic id, and it routes downstream by saying 'pass an id to `fetch`'. It does not explicitly contrast with the sibling `search`, so the when-not-to-use case is left implicit.

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

searchSearch EdgepediaA

Read-onlyIdempotent

Inspect

Search an encyclopedia for facts about a person, place, thing, event, or concept: Edgepedia, over 300k articles with citations. Pass the subject's name ("Mount Fuji", "photosynthesis"), not a question; other names and misspellings match, and when no title matches, articles whose text does follow, marked match: fulltext. Returns results with id, title, url, and preview text, plus a topic: result when the query names a topic ("painters"); pass an id to fetch. limit and page reach further results.

ParametersJSON Schema

Name	Required	Description
`page`	No	Which page of results, from 1.
`sort`	No	central = the most-linked subjects first.
`first`	No	true = only the best match.
`limit`	No	Results a page, 1 to 30 (default 10).
`query`	Yes	The name of a subject, or words from an article title.
`topic`	No	Only articles under this topic id (as `fetch` topic:… names it, without "topic:").

Output Schema

ParametersJSON Schema

Name	Required	Description
`page`	No
`pages`	No	Pages of results at this limit; pass `page` for the next.
`results`	Yes
`did_you_mean`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the description's value is in extra behavior: fuzzy/misspelling matching, the fulltext fallback explicitly marked `match: fulltext`, and the special `topic:` result. It adds real operational context beyond the annotations without contradicting them.

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?

Purpose and the critical 'name, not a question' rule are front-loaded, and every clause carries information (matching behavior, result fields, fallback, next step, pagination). The long em-dash-chained sentences are dense but slightly harder to scan than they need to be.

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?

For a 6-param search tool with a full schema, complete annotations, and an existing output schema, the description covers what an agent needs: what to pass, how matching behaves, what comes back, and how to continue. Nothing material is missing.

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 coverage is 100%, so the baseline is 3, but the description genuinely adds semantics the schema lacks: what `query` should contain (a subject name, not a question), that alternate names and misspellings still match, and that `limit`/`page` reach further results. It does not explain `sort` or `first`, leaving a couple of gaps.

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?

States a specific verb and resource ('Search an encyclopedia for facts about a person, place, thing, event, or concept'), names the corpus (Edgepedia, 300k+ articles with citations), and implicitly separates itself from the sibling `fetch` by saying 'pass an id to `fetch`'. An agent can distinguish it from fetch/related/resolve without opening a schema.

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?

Gives concrete when-to-use guidance: 'Pass the subject's name ("Mount Fuji", "photosynthesis"), not a question', and routes the follow-up step to `fetch` with a returned id. It does not explicitly say when to prefer `resolve`, `related`, or `connect` over search, so it falls short of full when/when-not/alternatives coverage.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesOct 7, 2026

Changedconnect3 fields changed

changedInput schema / properties / from / description

Previous value: -"The starting article's id (such as \"koala\")."New value: +"The starting article's id (such as \"koala\"), its ep… id, or its title."

changedInput schema / properties / to / description

Previous value: -"The target article's id."New value: +"The target article, named the same ways."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "found": {
+      "type": "boolean"
+    },
+    "from": {
+      "type": "string"
+    },
+    "hops": {
+      "type": "integer"
+    },
+    "path": {
+      "items": {
+        "properties": {
+          "id": {
+            "type": "string"
+          },
+          "title": {
+            "type": "string"
+          },
+          "url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "reason": {
+      "type": "string"
+    },
+    "steps": {
+      "items": {
+        "properties": {
+          "anchor": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "from": {
+            "type": "string"
+          },
+          "sentence": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "to": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "text": {
+      "type": "string"
+    },
+    "to": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "from",
+    "to",
+    "found",
+    "text"
+  ],
+  "type": "object"
+}

Changedfetch4 fields changed

addedInput schema / properties / links_page

Added value: +{
+  "description": "With links \"in\" or \"both\": which 30 articles linking here, from 1.",
+  "minimum": 1,
+  "type": "integer"
+}

addedOutput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "id",
+      "title",
+      "text",
+      "url"
+    ]
+  },
+  {
+    "required": [
+      "results"
+    ]
+  }
+]

addedOutput schema / properties / results

Added value: +{
+  "description": "With `ids`: one entry per id, in order: that fetch's answer, or { id, error: { code, message } }.",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / required

Removed value: -[
-  "id",
-  "title",
-  "text",
-  "url"
-]

Changedrelated5 fields changed

addedOutput schema / anyOf

Added value: +[
+  {
+    "required": [
+      "id",
+      "title",
+      "url",
+      "siblings",
+      "cousins",
+      "geo"
+    ]
+  },
+  {
+    "required": [
+      "id",
+      "title",
+      "url",
+      "by",
+      "cocited",
+      "coupled"
+    ]
+  }
+]

addedOutput schema / properties / by

Added value: +{
+  "enum": [
+    "links"
+  ],
+  "type": "string"
+}

addedOutput schema / properties / cocited

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / coupled

Added value: +{
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}

removedOutput schema / required

Removed value: -[
-  "id",
-  "title",
-  "url",
-  "siblings",
-  "cousins",
-  "geo"
-]

Addedresolve

4 tool updatesOct 7, 2026

Addedconnect

Changedfetch16 fields changed

addedInput schema / properties / chunks

Added value: +{
+  "description": "true = the text as paragraphs with stable ids, in `chunks`.",
+  "type": "boolean"
+}

addedInput schema / properties / cite

Added value: +{
+  "description": "Add a reference in this format (csl, bibtex, ris, apa, mla, chicago, harvard).",
+  "enum": [
+    "csl",
+    "bibtex",
+    "ris",
+    "apa",
+    "mla",
+    "chicago",
+    "harvard"
+  ],
+  "type": "string"
+}

addedInput schema / properties / cursor

Added value: +{
+  "description": "Where to continue, from a cut text's `next_cursor`.",
+  "type": "string"
+}

addedInput schema / properties / format

Added value: +{
+  "description": "The text as plain text, HTML, JSON-LD, or Turtle instead of Markdown.",
+  "enum": [
+    "text",
+    "html",
+    "jsonld",
+    "turtle"
+  ],
+  "type": "string"
+}

addedInput schema / properties / ids

Added value: +{
+  "description": "More ids to fetch with `id` in one call, up to 10 in all.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedInput schema / properties / length

Added value: +{
+  "description": "snippet or lead for a short text; full (default) for the whole article.",
+  "enum": [
+    "snippet",
+    "lead",
+    "full"
+  ],
+  "type": "string"
+}

addedInput schema / properties / links

Added value: +{
+  "description": "Add the articles linking here (in), the links it makes (out), or both.",
+  "enum": [
+    "in",
+    "out",
+    "both"
+  ],
+  "type": "string"
+}

addedInput schema / properties / max_tokens

Added value: +{
+  "description": "Cut the text at a section boundary to about this many tokens; pass `next_cursor` as `cursor` for the rest.",
+  "type": "integer"
+}

addedInput schema / properties / outline

Added value: +{
+  "description": "true = add the list of the article's headings.",
+  "type": "boolean"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "A topic only: which page of its articles, from 1.",
+  "type": "integer"
+}

addedInput schema / properties / query

Added value: +{
+  "description": "Only the 3 passages that best match these words, each with a `cite_url`.",
+  "type": "string"
+}

addedInput schema / properties / quote

Added value: +{
+  "description": "A sentence from the article, or a chunk id: adds a `cite_url` that opens the page at it.",
+  "type": "string"
+}

addedInput schema / properties / section

Added value: +{
+  "description": "Only this section, by its heading (\"Etymology\", \"History\").",
+  "type": "string"
+}

addedInput schema / properties / tables

Added value: +{
+  "description": "true = add the article's tables as JSON and CSV.",
+  "type": "boolean"
+}

addedOutput schema / properties / canonical_id

Added value: +{
+  "description": "The article's permanent id (ep…); `fetch` takes it, and it outlives an address change.",
+  "type": "string"
+}

addedOutput schema / properties / moved_from

Added value: +{
+  "description": "The id asked for, when the article has since moved; store `id` or `canonical_id` instead.",
+  "type": "string"
+}

Addedrelated

Changedsearch8 fields changed

addedInput schema / properties / first

Added value: +{
+  "description": "true = only the best match.",
+  "type": "boolean"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Results a page, 1 to 30 (default 10).",
+  "maximum": 30,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / page

Added value: +{
+  "description": "Which page of results, from 1.",
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / sort

Added value: +{
+  "description": "central = the most-linked subjects first.",
+  "enum": [
+    "relevance",
+    "central"
+  ],
+  "type": "string"
+}

addedInput schema / properties / topic

Added value: +{
+  "description": "Only articles under this topic id (as `fetch` topic:… names it, without \"topic:\").",
+  "type": "string"
+}

addedOutput schema / properties / page
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / pages

Added value: +{
+  "description": "Pages of results at this limit; pass `page` for the next.",
+  "type": "integer"
+}

addedOutput schema / properties / results / items / properties / canonical_id

Added value: +{
+  "description": "The article's permanent id (ep…); `fetch` takes it, and it outlives an address change.",
+  "type": "string"
+}

1 tool updateOct 4, 2026

Changedsearch1 field changed

changedOutput schema / properties / results / items / properties / text / description

Previous value: -"The article's opening sentences, or for a topic its article count and place in the tree."New value: +"The corpus snippet when available, otherwise the article opening; for a topic its article count and place in the tree."

2 tool updatesSep 29, 2026

Changedfetch1 field changed

changedInput schema / properties / id / description

Previous value: -"The id of a search result (the last part of the article's address, such as \"mount-fuji\")."New value: +"The id of a search result (the last part of the article's address, such as \"mount-fuji\", or a topic's \"topic:…\" id)."

Changedsearch2 fields changed

addedOutput schema / properties / results / items / properties / articles

Added value: +{
+  "description": "A topic only: the articles under it.",
+  "type": "integer"
+}

changedOutput schema / properties / results / items / properties / text / description

Previous value: -"The article's opening sentences."New value: +"The article's opening sentences, or for a topic its article count and place in the tree."

2 tool updatesSep 20, 2026
- First observedfetch
- First observedsearch

Related MCP Connectors

Cyber Library
com.cyberlibrary
Search and read Cyber Library, a free structured cybersecurity knowledge base. Read-only, no auth.
Documentation Access Search Security
61
wikipedia-mcp-server A
io.github.cyanheads
Search Wikipedia, read summaries and full text, target sections, find nearby pages, list languages.
Search Open Data
614
Diffusion Love Knowledge
io.github.AnastasiyaW
Public knowledge and news search. Unmatched public queries may be retained for research.
Search Open Data Research & Data
41
ScrapeMole Wiki
dev.pages.scrapemole
Pay-per-call x402 Wikipedia summaries/search and Wikidata facts, with CC BY-SA attribution.
Search Open Data Payments & Billing
31

Related MCP Servers

smartipedia-mcp
Search Content Management Systems Education & Learning Tools
sksareen
A
license
A
quality
B
maintenance
Enables MCP clients to search, read, create, preview, and edit Smartipedia encyclopedia articles with no API key or signup.
Updated a month ago (2026-09-04 20:48 UTC)
7
29 npm
MIT
wikipedia-mcp
Search RAG Systems
Rumblingb
A
license
Not graded
quality
F
maintenance
Enables AI agents to search, read, and explore Wikipedia articles via tools like summaries, categories, and random articles, with no API keys required.
Updated 3 months ago (2026-07-13 10:54 UTC)
1
MIT
@openindex/openindexwikiofficial
Knowledge & Memory Note Taking
openindex-ai
A
license
Not graded
quality
B
maintenance
Enables AI agents to read, search, and write to a public wiki knowledge base via MCP.
Updated 5 days ago (2026-10-10 20:16 UTC)
MIT
Grokipedia MCP Server
Search Research & Data Open Data
TheOneTrueNiz
A
license
A
quality
D
maintenance
Enables searching and retrieving articles, citations, and structured content from Grokipedia for research and information retrieval. It provides specialized tools for section extraction, related page discovery, and filtered search results.
Updated 7 months ago (2026-03-27 04:21 UTC)
7
MIT