The philosophy-mcp server provides keyless access to a vast collection of philosophy texts, enabling you to search, read, and extract information from academic papers, classic books, reference works, and local documents.
Philosophy Scholarship (PhilPapers / PhilArchive)
search_papers — Keyword search across PhilPapers/PhilArchive, returning metadata, abstracts, and open-access PDF links.
research — One-shot topic scan: search and fetch full abstracts + subjects for each hit in a single call.
get_paper — Fetch canonical metadata and full abstract for a single PhilArchive record by ID or URL.
list_recent — List recently added/updated PhilArchive records within a specified date window.
fetch_pdf — Download an open-access PDF from PhilArchive to disk and return the local file path.
get_fulltext — Download a PhilArchive PDF and return its extracted full text directly.
Books, Classics & Reference
search_gutenberg / get_gutenberg_text — Search and read public-domain philosophy classics from Project Gutenberg.
search_internet_archive / get_archive_text — Search and read OCR text of scanned, out-of-print works from the Internet Archive.
search_wikisource / get_wikisource_text — Search and read primary texts and translations from Wikisource in multiple languages.
search_openlibrary — Search Open Library for modern editions and translations, with read/borrow links.
search_doab — Search the Directory of Open Access Books for peer-reviewed, open-access academic philosophy monographs.
search_sep / get_sep_entry — Search the Stanford Encyclopedia of Philosophy and read full entries.
fetch_text — Fetch readable plain text from any URL as a catch-all tool.
Local Documents
local_doc_info — Get an overview (pages, character count, token estimate, outline) of a large local PDF or text file.
local_doc_search — Search a local document by keyword or regex, returning matching snippets with page numbers.
local_doc_read — Read a bounded page range/chunk of a local document with pagination support.
General
All text-returning tools support paginated reading via max_chars and offset for incrementally handling long works.
No API key required — all tools use keyless public endpoints.
Responses are cached to avoid re-downloading or re-parsing on subsequent reads.
Search for scanned, out-of-print works and retrieve their OCR text from the Internet Archive.
Click on "Install 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., "@philosophy-mcp Search for recent papers on philosophy of mind"
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.
An MCP server for philosophy texts — both current scholarship and the canon. It folds these into one keyless server:
PhilPapers / PhilArchive — the philosophy preprint archive (the field's closest analog to arXiv): search papers, read abstracts, browse recent submissions, pull full text.
Books, classics & reference — public-domain originals and translations (Project
Gutenberg, Internet Archive, Wikisource), open-access academic books (DOAB), modern
editions (Open Library), and the Stanford Encyclopedia of Philosophy — plus a generic
fetch_text for any other source (Zeno.org, marxists.org, Standard Ebooks, …).
Local documents — open a large local PDF or text file and work it without loading the whole thing into context: outline, in-file search, and paged reading.
No API key required. Everything runs against keyless public endpoints.
Renamed and expanded from philpapers-mcp (which covered only the PhilPapers tools). The
philpapers-mcpbinary name still works as an alias.
Tool | What it does | Backend |
| Keyword search (title/abstract/full text), returns metadata + PhilArchive links + PDF URL | OpenAlex, filtered to the PhilPapers Foundation source |
| One-shot scan: search and pull each hit's verbatim full abstract + subjects in a single call | OpenAlex + OAI-PMH |
| Canonical metadata + full abstract for one record id | PhilArchive OAI-PMH |
| Records added/updated in a date window | PhilArchive OAI-PMH |
| Download a record's open-access PDF to disk, return the path |
|
| Download the open-access PDF and return its extracted full text | PDF + |
PhilArchive is the open-access archive built on the PhilPapers database, so a record id
such as BROTNO-9 resolves on both philarchive.org and philpapers.org.
Tool | What it does | Source |
| Find and read public-domain classics + out-of-copyright translations | Project Gutenberg (Gutendex, with a gutenberg.org fallback) |
| Find scanned, out-of-print works and read their OCR text | Internet Archive |
| Find and read primary texts/translations in any language (en, de, ko, …) | Wikisource |
| Modern editions & translations as metadata, with read/borrow links | Open Library |
| Peer-reviewed, fully open-access academic books (readable in full) | DOAB |
| Search and read the standard scholarly reference | Stanford Encyclopedia of Philosophy |
| Readable plain text from any URL — the catch-all for sources without a dedicated tool | any site |
All text-returning tools (get_fulltext, the get_*_text readers, get_sep_entry,
fetch_text) return one window — max_chars characters (default 15000) starting at
offset (default 0). When the body is longer, the footer reports the next offset to
continue from, so you page through a long work a window at a time instead of dumping it whole
(and re-dumping from the start to read further). Each fetched/extracted body is cached, so
paging doesn't re-download or re-parse the source.
Tool | What it does |
| Overview of a local PDF/text file — pages, characters, ~tokens, and a heuristic outline — without loading the whole file |
| Find passages by keyword/regex and return just the matching snippets with page numbers |
| Read a bounded page range / chunk, capped at |
These read a large local file the way you'd skim a thick book — get an outline, jump to the
relevant pages by searching, then read a chunk at a time — so only the parts that matter reach
the context. Only files under $HOME are readable by default; add more roots via
PHILOSOPHY_DOC_ROOTS.
Related MCP server: mcp-scholaris
search_papers with { "query": "phenomenal consciousness higher-order", "open_access_only": true, "limit": 2 }:
Found 1,806 match(es) in PhilPapers/PhilArchive; showing 2 (open-access only).
1. The HOROR theory of phenomenal consciousness (2014)
id: BROTNO-9
authors: Richard Brown
philarchive: https://philarchive.org/rec/BROTNO-9
pdf: https://philpapers.org/archive/BROTNO-9.pdfThen get_fulltext with { "id": "BROTNO-9" } returns the paper's extracted full text.
For the canon: search_gutenberg with { "query": "kant critique", "languages": "en" } returns book
ids, and get_gutenberg_text with { "book_id": 4280 } reads The Critique of Pure Reason directly;
search_sep → get_sep_entry reads an encyclopedia entry; fetch_text pulls readable text from
German originals on Zeno.org or translations on marxists.org.
20th-century authors still in copyright (Heidegger, Adorno, Gadamer, Habermas) won't have free full texts here — you'll get metadata, SEP coverage, and read/borrow links.
Run straight with npx (no clone, once published):
npx -y philosophy-mcpOr from source:
git clone https://github.com/sea9401/philosophy-mcp
cd philosophy-mcp
npm install # the `prepare` hook builds dist/ automaticallydist/ is committed, so an existing source checkout updates with a plain pull — no build step:
cd philosophy-mcp
git pullThen restart the MCP server (reconnect in Claude Code, or restart Claude Desktop) so it
loads the new build. Maintainers: rebuild and commit dist/ whenever you change src/ — CI
fails if the two drift.
# via npx (no clone)
claude mcp add philosophy -- npx -y philosophy-mcp
# from a local build
claude mcp add philosophy -- node /absolute/path/to/dist/index.js
# optional: identify yourself to OpenAlex's "polite pool" for better rate limits
claude mcp add philosophy -e OPENALEX_MAILTO=you@example.com -- npx -y philosophy-mcpThen /mcp inside Claude Code lists philosophy with its tools.
Add to claude_desktop_config.json:
{
"mcpServers": {
"philosophy": {
"command": "node",
"args": ["/home/sea9401/philpapers-mcp/dist/index.js"],
"env": { "OPENALEX_MAILTO": "you@example.com" }
}
}
}Var | Default | Purpose |
|
| Your email — joins OpenAlex's polite pool (recommended). |
|
| Where |
|
| Extra roots the |
npm test # builds, then runs smoke-test.mjssmoke-test.mjs spawns the server over stdio, performs the MCP handshake, and verifies every
expected tool is registered — no network calls, so it's the regression guard CI runs. (The
older node test-client.mjs additionally exercises a couple of live PhilPapers calls.)
The book/reference tools are keyless and read-only. Search tools return compact lists; the
get_* / fetch_text tools return one max_chars window from offset and report the next
offset to continue — page through long works instead of pulling them whole.
Gutendex (the Project Gutenberg API host) is frequently overloaded; search_gutenberg
probes it briefly and falls back to gutenberg.org's OPDS feed. get_gutenberg_text reads the
text directly from gutenberg.org, so it works even when Gutendex is down.
SEP has no keyword API (its on-site search is JavaScript-driven), so search_sep matches
against the published entry index (contents.html) — i.e. title/topic matching.
list_recent filters on the OAI datestamp, returns only the first OAI page, and not every
record has an open-access PDF — get_paper reports availability; fetch_pdf fails clearly.
CI (.github/workflows/ci.yml) builds on Node 18/20/22 for every push and PR.
To publish a new version to npm:
Add a repo secret NPM_TOKEN (an npm Automation access token) under
Settings → Secrets and variables → Actions.
Bump the version and tag: npm version patch && git push --follow-tags.
Cut a GitHub Release — .github/workflows/publish.yml runs npm publish automatically.
Or publish manually: npm login then npm publish --access public.
MIT
Download the open-access PDF of a PhilArchive record and save it locally, returning the file path so it can be read. Accepts a record id or URL. Fails clearly if the paper has no open-access PDF. To get the text directly instead of a file, use get_fulltext.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | PhilArchive record id or URL, e.g. 'BROTNO-9'. | |
| dest_dir | No | Directory to save into. Default: <tmp>/philpapers-mcp |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains failure behavior (fails clearly if no PDF), that it saves locally and returns the file path. It could mention overwriting behavior or permission issues, but overall it is fairly transparent for a simple download tool.
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 no extraneous information. It front-loads the main action and provides necessary context in a few sentences.
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's simplicity (2 parameters, no output schema, no nested objects), the description covers all key aspects: what it does, how it behaves on failure, what it returns, and how it differs from alternatives. It is complete enough for an agent to use 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 coverage is 100% (both parameters have descriptions in the schema). The description adds little beyond the schema: it restates that id accepts a URL, and for dest_dir it mentions a default directory, which is already in the schema. Therefore, it meets the baseline of 3.
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 clearly states it downloads an open-access PDF from PhilArchive, saves it locally, and returns the file path. It distinguishes itself from sibling tools like get_fulltext, which provides text directly.
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 explicitly tells when to use this tool (to download a PDF) and when not to (to get text directly, use get_fulltext). It also warns that it fails if no open-access PDF available, helping agents avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch any URL and return its readable text — the catch-all for sources without a dedicated tool: Zeno.org and projekt-gutenberg.org (German originals), marxists.org (German Idealism to Frankfurt School translations), Standard Ebooks, a specific page, etc.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page or text-file URL. | |
| max_chars | No | Characters to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates the output is 'readable text' but does not detail behavior for inaccessible URLs, redirects, or dynamic content. The catch-all nature is clear, but more transparency on limitations or processing is needed.
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 sentence that efficiently conveys the purpose and context. It is front-loaded with the core action and provides examples, but it could be slightly more structured or split for readability.
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 has two simple parameters and no output schema, the description is reasonably complete. It explains the tool's role as a catch-all and provides usage context. It could mention the return format more explicitly but is sufficient.
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 coverage is 100%, with both parameters described adequately. The description adds context about returning readable text but does not enhance parameter details beyond the schema. Baseline 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 clearly states the tool fetches any URL and returns readable text, positioning it as a catch-all for sources without dedicated tools. It lists specific examples like Zeno.org and marxists.org, distinguishing it from sibling tools.
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 explicitly frames the tool as a catch-all for URLs lacking a dedicated tool, providing good context on when to use it. It does not explicitly state when not to use, but the sibling tools cover specific sources, so the guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the OCR full text of an Internet Archive item by identifier (from search_internet_archive). Truncated to max_chars.
| Name | Required | Description | Default |
|---|---|---|---|
| identifier | Yes | IA item identifier. | |
| max_chars | No | Characters to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It mentions truncation via max_chars but lacks details on error handling, authentication, or rate limits. The mutation-like 'Fetch' is ambiguous regarding side effects.
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, front-loaded with key purpose and usage hint. Every sentence adds value without redundancy.
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?
Adequate for a simple two-parameter tool, but lacks output schema and any description of return format or error handling. Behavioral transparency gaps lower completeness.
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 coverage is 100%. Description adds minimal context: identifier from search result and max_chars truncation. Baseline 3 as parameter semantics are clear but not enriched beyond 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?
Description clearly states the verb ('Fetch') and resource ('OCR full text of an Internet Archive item'). It specifies the identifier comes from search_internet_archive, distinguishing it from similar tools like fetch_text or get_fulltext.
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?
Implicitly suggests use after search_internet_archive, but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools like fetch_text or get_fulltext.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a PhilArchive record's open-access PDF and extract its full text, returned directly (no file needed). Accepts a record id or URL. Long papers are truncated to max_chars. Fails clearly if the paper has no open-access PDF.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | PhilArchive record id or URL, e.g. 'BROTNO-9'. | |
| max_chars | No | Max characters of extracted text to return (default 50000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses truncation behavior, failure mode, and that no file is saved. This is sufficient for a tool that downloads and extracts text.
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?
Three concise sentences, front-loaded with action, no wasted words. Every sentence adds value.
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?
Despite no output schema, description explains that full text is returned directly, covers truncation, failure, and input formats. Complete for a simple extract tool.
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 coverage is 100%, baseline 3. Description adds meaning: 'Accepts a record id or URL' clarifies id, and 'Long papers are truncated to max_chars' adds context for max_chars beyond 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?
Description clearly states it downloads and extracts full text from a PhilArchive open-access PDF, returns directly, accepts id or URL, truncates, and fails clearly. This distinguishes it from sibling tools like fetch_pdf or get_text.
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?
Description explains when to use (get full text from open-access PDF) and failure condition (no open-access PDF). It implies context but doesn't explicitly state when not to use or name alternatives, but siblings are diverse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the plain-text body of a Project Gutenberg book by numeric id (from search_gutenberg). Truncated to max_chars.
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Gutenberg book id. | |
| max_chars | No | Characters to return (default 15000). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses truncation behavior via max_chars, which is useful. However, without annotations, it lacks details on error handling, rate limits, or what happens with invalid IDs. The description carries the full burden but fails to cover common behavioral aspects.
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 two sentences, concise, and front-loaded with the essential action. Every word adds value with no redundancy.
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 no output schema, the description mentions 'plain-text body' which is helpful. However, it lacks details on return format, error states, or pagination (if any). For a simple fetch tool, it is adequate but could be more comprehensive.
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 coverage is 100%, but the description adds value by clarifying that book_id is numeric and from search_gutenberg, and that max_chars controls truncation (default 15000). This provides more semantic context than the bare schema descriptions.
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 clearly states the tool fetches plain-text body of a Project Gutenberg book by numeric id, and mentions id from search_gutenberg. However, it does not explicitly distinguish from sibling tools like get_fulltext or get_archive_text, which may have overlapping functionality.
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 that the id should come from search_gutenberg and that output is truncated to max_chars. It provides clear context but does not specify when not to use this tool or mention alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch canonical metadata for one PhilArchive/PhilPapers record via OAI-PMH. Accepts a record id (e.g. 'BROTNO-9'), a philarchive.org/philpapers.org /rec/ URL, or an oai: identifier. Returns title, authors, date, subjects, language, full abstract, the landing-page URL, and whether an open-access PDF is available.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | PhilArchive record id or URL, e.g. 'BROTNO-9'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose all behavioral traits. It mentions tool uses OAI-PMH, accepts multiple ID formats, and returns specific fields. However, it does not disclose potential constraints such as rate limits, authentication requirements, or error behavior (e.g., what happens if the record does not exist).
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: first sentence states the main purpose and protocol, second sentence details input formats and output fields. No redundant 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?
Given the simplicity (one parameter, no output schema, no annotations), the description covers the essential aspects: input types, output fields, and protocol. It could mention error scenarios or fallback behavior, but overall it is sufficient for the agent to use the tool 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?
The input schema has one parameter 'id' with minimal description. The description adds significant value by explaining that the id can be a simple record id, a /rec/ URL, or an oai: identifier, and provides an example. This enriches the semantics beyond the 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?
Clearly states the tool fetches canonical metadata for PhilArchive/PhilPapers records via OAI-PMH. Specifies accepted identifier formats (record id, URL, OAI-PMH identifier) and lists returned fields (title, authors, date, subjects, language, abstract, landing-page URL, open-access PDF indicator). This distinctly differentiates it from sibling tools like fetch_pdf (full-text PDF) or search_papers (search).
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?
Describes when to use the tool (to fetch metadata for a specific record) and what inputs it accepts. Does not explicitly state when not to use it or provide alternatives, but the context of sibling tools (e.g., fetch_pdf, search_papers) implies this is for metadata-only retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the text of a SEP entry. Accepts a slug (e.g. 'hegel'), a /entries/.. path, or a full URL. Truncated to max_chars.
| Name | Required | Description | Default |
|---|---|---|---|
| entry | Yes | Entry slug, /entries/.. path, or full URL. | |
| max_chars | No | Characters to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions truncation but omits important details like error handling for missing entries, authentication needs, or whether it is read-only.
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 concise sentences, front-loaded with purpose, followed by input format details and truncation. No wasted words.
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?
Simple tool with 2 params, but missing behavioral context like return format or error handling. Adequate for minimal needs but incomplete without annotations.
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 coverage is 100% and description does not add meaning beyond the schema's parameter descriptions. 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 clearly states the tool fetches text of a SEP entry, using specific verbs and resource. It distinguishes from siblings like search_sep by focusing on retrieval, not search, and specifies acceptable input formats.
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?
No guidance on when to use this tool versus alternatives like fetch_text or get_fulltext. The description only lists input formats, not context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the plain text of a Wikisource page by title (from search_wikisource). Truncated to max_chars.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Exact page title. | |
| lang | No | Wikisource language subdomain. | en |
| max_chars | No | Characters to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Only mentions truncation via max_chars. No annotations present, and description omits details on error handling (e.g., missing page), request limits, or encoding, placing full burden on the description.
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 concise sentences that front-load purpose and key constraint (truncation). No wasted words.
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?
Adequate for a simple fetch tool with full schema coverage. Lacks mention of error states or handling of edge cases (e.g., non-existent titles), but sufficient given the narrow scope.
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 has 100% coverage with clear parameter descriptions. The description adds minimal extra value ('from search_wikisource' for title context) but does not deepen understanding of parameter behavior beyond schema defaults.
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?
Clearly states the verb 'Fetch', resource 'plain text of a Wikisource page', and specific context 'by title (from search_wikisource)', distinguishing it from siblings like search_wikisource and other fetch tools.
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?
Explicitly links to search_wikisource for obtaining the title, implying the intended workflow. However, lacks explicit when-not-to-use or comparisons with similar fetch tools from other sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recently added/updated PhilArchive records in a date window, via OAI-PMH (harvesting, not keyword search). Returns the first page of results (~up to limit). Dates are UTC YYYY-MM-DD; defaults to the last 7 days.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | Start date (YYYY-MM-DD, UTC). Default: 7 days ago. | |
| until | No | End date (YYYY-MM-DD, UTC). Default: now. | |
| limit | No | Max records from the first page (1–100, default 20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses OAI-PMH protocol, first page only, date format and defaults, limit range. With no annotations, provides key behavioral traits.
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, no redundancy, front-loaded with purpose and key details.
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 list tool with 3 optional parameters and no output schema, the description fully covers behavior, format, and defaults. No gaps.
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 already describes all parameters (100% coverage). Description adds pagination nuance ('returns first page of results ~up to limit') beyond schema, providing added clarity.
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?
Clearly states listing recently added/updated PhilArchive records via OAI-PMH harvesting, specifying date window and pagination. Distinct from sibling search tools.
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?
Explicitly says 'not keyword search' to differentiate from search tools, explains date defaults and pagination. Lacks explicit when-not-to-use but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-shot literature scan: runs a keyword search across PhilPapers/PhilArchive and, for each hit, fetches the archive's canonical metadata (verbatim full abstract, subjects, language) via OAI-PMH — so you get a ready-to-read digest in a single call instead of search_papers + get_paper per result. Returns fewer results than search_papers by default because it does more work per item.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic or search terms to research. | |
| limit | No | How many papers to include with full abstracts (1–20, default 5). | |
| year_from | No | Only papers published in or after this year. | |
| year_to | No | Only papers published in or before this year. | |
| open_access_only | No | Only include papers with a downloadable open-access PDF. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the process of searching and fetching metadata via OAI-PMH, and notes the trade-off of fewer results for more work. However, it does not mention rate limits or authentication needs, which are minor for this type of tool.
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 sentence that front-loads the key idea ('One-shot literature scan') and efficiently conveys the process, trade-offs, and differences from siblings without waste.
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 complexity (5 parameters, no output schema), the description is complete: it explains the workflow, output format (digest with abstracts), and how it differs from related tools. No output schema is needed as the description implies return values.
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 baseline is 3. The description adds marginal context beyond the schema (e.g., why limit is small), but does not significantly enhance understanding of individual parameters.
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 clearly states it performs a one-shot literature scan via keyword search across PhilPapers/PhilArchive and fetches full abstracts via OAI-PMH. It distinguishes from siblings by contrasting with search_papers and noting it returns fewer results because it does more work per item.
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 using this tool for a ready-to-read digest in a single call, contrasting with search_papers + get_paper per result. However, it does not explicitly state when not to use it or list alternatives, though the context of sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Directory of Open Access Books — peer-reviewed, fully open-access academic books, including many modern philosophy monographs readable in full.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms (title/author/keyword). | |
| limit | No | Max results (1–25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description must carry full burden. Describes content type but does not disclose response format, authentication needs, rate limits, or other operational behaviors. Lacks detail on what 'readable in full' means for tool interaction.
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?
Single well-formed sentence, front-loaded with purpose. No wasted words, but could be slightly more structured.
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 search tool with 2 parameters and no output schema, the description covers the essential: what resource is searched and the nature of content. Lacks result format details, but adequate given simplicity.
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 coverage is 100%, so baseline is 3. Description adds no parameter-specific context beyond what schema already provides. The mention of philosophy monographs is about content, not parameters.
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?
Clearly states it searches the Directory of Open Access Books (DOAB), with specific verb 'Search' and resource. Adds distinguishing context: peer-reviewed, open-access, philosophy monographs. Differentiates from sibling search tools.
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?
Implies use for finding open-access academic books, but no explicit guidance on when to use this over similar tools (e.g., search_openlibrary, search_papers) 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.
Search Project Gutenberg for public-domain classics and out-of-copyright translations (Kant, Hegel, Nietzsche, Schopenhauer, Marx, Fichte, ...). Returns title, author, languages, a Gutenberg page link, and download URLs. Use the numeric id with get_gutenberg_text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search over title + author. | |
| author | No | Author name to fold into the search. | |
| topic | No | Subject/bookshelf filter, e.g. 'philosophy'. | |
| languages | No | Comma-separated ISO codes, e.g. 'en,de'. | |
| limit | No | Max results (1–32). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It mentions return fields and usage hint but omits rate limits, error handling, or pagination behavior, leaving gaps.
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 efficiently cover purpose, examples, and return info. No superfluous words, well 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?
With no output schema and no annotations, description provides basic return info and usage hint but lacks details on combining parameters or default behavior, leaving some context incomplete.
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 description adds no extra meaning beyond schema. Baseline 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 clearly states the tool searches Project Gutenberg for public-domain classics, listing specific philosophers. It specifies the resource and type of content, distinguishing it from siblings.
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 hints at follow-up action (use numeric id with get_gutenberg_text) but lacks explicit when-to-use guidance or comparison to siblings like search_doab or search_internet_archive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Internet Archive for scanned, out-of-print monographs, journals, and translations. Use the returned identifier with get_archive_text.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms. | |
| limit | No | Max results (1–25). | |
| mediatype | No | Usually 'texts'; pass '' for all media. | texts |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only search operation and adds context about the content type, but does not disclose pagination, sorting, authorization needs, or other behavioral traits.
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, front-loaded with the core purpose in the first sentence and actionable next-step guidance in the second, with no wasted words.
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 description does not explain the return value format or structure, which is important since there is no output schema. It mentions 'returned identifier' but does not elaborate on the full response, leaving the agent with incomplete context.
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 coverage is 100% and parameters are well-described in the schema. The description adds no additional meaning beyond what the schema provides, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the Internet Archive' and specifies the scope as 'scanned, out-of-print monographs, journals, and translations', which distinguishes it from sibling search tools targeting other sources.
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 clear context for when to use (searching Internet Archive scanned materials) and mentions using the returned identifier with get_archive_text, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Open Library for books — strong for modern editions and translations as metadata, with read/borrow links wherever a scan exists.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Title or keywords, e.g. 'Being and Time Heidegger'. | |
| author | No | Optional author filter. | |
| limit | No | Max results (1–25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states that read/borrow links are included when a scan exists, but does not mention response format, pagination, or side effects. The read-only nature is not explicitly stated, though it is implied by 'search'. More detail on what is returned (e.g., full metadata) would improve transparency.
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 clear sentence that efficiently conveys the primary action and distinguishing features. No unnecessary words, and it is front-loaded with the core purpose.
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?
While the schema covers all required parameters and the description gives a good overview, there is no information about the structure of results, sorting, pagination, or error cases. Given the absence of an output schema, more detail on return format would enhance completeness. However, for a simple search tool it is minimally adequate.
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?
All three parameters have complete descriptions in the input schema (100% coverage), so the description adds minimal value beyond reinforcing that queries are for titles/keywords and author is optional. The description does not elaborate on parameter formatting or constraints beyond the 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?
The description clearly states the tool searches for books on Open Library, and mentions its strength for modern editions and translations, which helps distinguish it from sibling search tools like search_gutenberg or search_internet_archive. However, it could be more explicit about the specific scope (e.g., books only) and how it differs from similar tools.
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 usage for searching modern editions and translations, but does not provide explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, and there is no comparison with siblings such as search_gutenberg for public domain texts or search_internet_archive for archival materials.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Keyword search across PhilPapers / PhilArchive (philosophy preprints and published papers indexed by the PhilPapers Foundation), powered by OpenAlex full-text search. Returns title, authors, year, a short abstract, the PhilArchive record id + URL, and an open-access PDF URL when one exists. Use the returned id with get_paper, research, or fetch_pdf. For a richer one-shot digest with full abstracts, use research instead.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms, e.g. 'phenomenal consciousness higher-order'. | |
| limit | No | Max results to return (1–50, default 10). | |
| year_from | No | Only papers published in or after this year. | |
| year_to | No | Only papers published in or before this year. | |
| open_access_only | No | Only return papers that have a downloadable open-access PDF on PhilArchive. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It reveals the source (OpenAlex), output fields, and conditional inclusion of PDF URLs. No destructive side effects are implied, and the read-only nature is clear.
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: four sentences, each adding value. It is front-loaded with purpose, then details output, then references sibling tools. No wasted words.
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 no output schema, the description fully explains return values. It also mentions the underlying service (OpenAlex) and the broader tool ecosystem. No gaps remain for an agent to decide usage.
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 baseline is 3. The description adds context about output fields but does not enhance parameter understanding beyond the schema definitions.
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 clearly states the tool performs keyword search across PhilPapers/PhilArchive, returns specific fields (title, authors, year, abstract, id, URL, PDF URL), and distinguishes from the sibling tool 'research' for richer digests. Verb+resource is precise.
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 explicitly advises using 'research' for full abstracts, and mentions using the returned id with other tools. It lacks explicit when-not-to-use scenarios, but provides sufficient context for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search SEP (the standard scholarly reference) by matching its full entry index. Read an entry with get_sep_entry.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Topic or philosopher, e.g. 'Hegel', 'phenomenology'. | |
| limit | No | Max results (1–20). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'matching its full entry index.' It does not disclose behavior like case sensitivity, result behavior on no matches, or any side effects. This is minimal transparency.
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 concise sentences that front-load the purpose and immediately suggest the next tool. Zero wasted words.
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 no output schema and simple parameters, the description adequately explains the tool's function and hints at follow-up. It could mention result format or pagination, but it is sufficient for basic usage.
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 coverage is 100%, and the description adds examples for query (e.g., 'Hegel', 'phenomenology') and clarifies limit bounds (1–20), which closely mirrors the schema. No significant extra meaning beyond the 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?
The description clearly states the tool searches the Stanford Encyclopedia of Philosophy by matching its full entry index. It names a specific sibling (get_sep_entry) for reading, making the purpose distinct.
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?
It tells when to use this tool (searching SEP) and points to get_sep_entry for reading. However, it does not explicitly distinguish it from other search tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Wikisource for primary texts and translations (en, de, ko, ...). Use get_wikisource_text to read.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search terms. | |
| lang | No | Wikisource language subdomain (en, de, ko...). | en |
| limit | No | Max results (1–25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Search Wikisource' without detailing behavioral traits such as authentication, rate limits, or whether the operation is read-only (implied but not explicit).
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 two concise sentences with no redundant information. It front-loads the purpose and ends with a clear action recommendation.
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?
Without an output schema, the description should explain what the search results contain (e.g., titles, snippets, etc.). It does not, leaving the agent to infer the return format. The description also lacks context on result pagination or sorting.
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 input schema covers 100% of parameters with descriptions. The description adds minimal value beyond the schema, only providing example languages for the 'lang' parameter, which is helpful but not substantial enough to raise the score above baseline.
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 clearly states the tool searches Wikisource for primary texts and translations, and distinguishes itself from the sibling tool 'get_wikisource_text' by directing the agent to use that to read.
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 a referral to a related tool ('Use get_wikisource_text to read') but does not compare with other search tools in the sibling list, leaving the agent with minimal guidance on when to choose this over alternatives.
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. Dates show when Glama detected each change.
v0.3.0fetch_pdffetch_textget_archive_textget_fulltextget_gutenberg_textget_paperget_sep_entryget_wikisource_textlist_recentresearchsearch_doabsearch_gutenbergsearch_internet_archivesearch_openlibrarysearch_paperssearch_sepsearch_wikisourceMost tools have distinct purposes, but some overlap exists: fetch_pdf and get_fulltext both retrieve PhilArchive PDFs (file vs text), and fetch_text is a catch-all that could be confused with specific source tools. However, descriptions clarify differences.
Naming conventions are mixed: some use 'get_', some 'fetch_', some 'search_', plus 'list_recent' and 'research'. While readable, the inconsistency in verb choice could cause confusion.
With 17 tools, the count is slightly above the typical well-scoped range, but each tool serves a clear purpose for different text sources and operations. No tool feels redundant.
The tool set covers a wide range of philosophical text sources (PhilArchive, SEP, Gutenberg, Internet Archive, Wikisource, etc.) with search and retrieval capabilities. Minor gaps exist (e.g., no unified multi-source search), but overall coverage is strong for the domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Search 15K rare pre-modern texts translated to English: philosophy, religion, science, literature.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/sea9401/philosophy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
