sophotron

by rookslog

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool has a clearly distinct purpose: multiple search tools are differentiated by backend (Semantic Scholar, PhilArchive, OpenAlex) and use case, while citation, reference, related, PDF retrieval, library management, and taxonomy browsing are all separate actions. No two tools appear to do the same thing.
Naming Consistency4/5
Tool names mostly follow a verb_noun pattern (get_, search_, browse_, download_, read_), with only a few deviations like 'category_papers' and 'library_add' where the noun comes first, and 'recommend' as a bare verb. Overall the convention is predictable and readable.
Tool Count4/5
With 18 tools, the server is slightly on the heavy side but the breadth of functionality (multi-source search, citation graph, taxonomy, library, full-text reading, recommendations) justifies each tool. No tool feels redundant, though the count approaches the upper bound of what is ideal.
Completeness4/5
The tool surface covers the full research workflow: discovery (search, browse, related), retrieval (metadata, PDFs, full text), library management (add/remove/list), reading, and recommendation. Minor gaps exist (no bulk operations, no citation export) but none would prevent core use cases.
Average 4/5 across 18 of 18 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It implies a read-only operation ('get') but does not explicitly state side effects, permissions, rate limits, or what specific statistics are included. The description adds some context by naming 'local PhilArchive cache' and 'cross-reference mappings,' but fails to disclose important behavioral details.
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?
The description is a single, front-loaded sentence that clearly states the purpose. There is no wasted text, and every word contributes to the meaning. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain what the returned statistics contain. It only says 'statistics about the local PhilArchive cache and cross-reference mappings' without specifying what those statistics are (counts, sizes, timestamps, mapping details). Given its simplicity, it is missing needed details for the agent to correctly interpret the results.
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?
The tool has no parameters, so the schema coverage is trivially 100%. The description does not need to explain parameter semantics. Per the rubric, a zero-parameter tool only needs a baseline of 4, which is met.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get statistics about the local PhilArchive cache and cross-reference mappings. The verb 'get' and resource are specific, and it distinguishes from sibling tools which focus on papers, citations, and searches rather than cache internals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or when not to use it (e.g., when needing paper data). The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately states the core behavior but adds no detail about pagination, default limit, ordering, or return format. The description essentially restates the title without additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and object. Every word contributes meaning, and there is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple, read-only lookup with a clear schema. The description adequately explains the main purpose, but lacks context about reply structure, pagination behavior, or how it relates to sibling tools. Given the absence of annotations and output schema, a complete description would need to cover these aspects.
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 both parameters (paper_id, limit) are already documented. The description itself adds nothing beyond the schema, which is the baseline for full coverage. It neither enhances nor compensates further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns papers cited by a given paper (its bibliography). The verb 'get' and resource 'papers' are specific, and the phrase 'cites (its bibliography)' distinguishes it from the sibling get_citations. However, it does not explicitly name an alternative or contrast with get_citations, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as get_citations or get_related. It implies usage for fetching a paper's bibliography but provides no explicit context, exclusions, or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. It only states the basic operation without revealing any behavioral traits such as pagination, default limit, sorting, response format, or potential limitations. This falls short of what is needed for a tool with no annotation support.
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?
The description is a single concise sentence that directly conveys the tool's purpose with no filler or redundancy. It is well-structured and front-loaded, achieving maximum clarity in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), but the description lacks any mention of return value structure, default behavior, or distinctions from sibling tools. It is sufficient for basic understanding but incomplete for an agent that needs to anticipate outputs or edge cases.
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 coverage is 100%, with both paper_id (S2 ID or DOI) and limit (max results, default 50) clearly described. The description adds no additional meaning beyond what the schema already provides, so baseline 3 applies.
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?
Description clearly states the tool retrieves papers that cite a given paper, using a specific verb ('Get') and resource ('papers that cite'). This distinguishes it from sibling tools like get_references (which gets papers cited by a paper), get_paper (single paper), and get_related (related papers).
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?
The intended usage is implied by the name and title — use when you need citing papers for a specific paper. However, there is no explicit guidance on when to use this tool versus alternatives like get_references, nor any mention of prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It does not mention that the operation is read-only (though 'Get' implies it), nor does it explain error behavior, authentication requirements, or what 'detailed metadata' encompasses. It lacks any additional behavioral context beyond the basic function.
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?
The description is two concise sentences. The first sentence states the purpose clearly, and the second adds necessary detail about accepted ID types. No fluff or redundancy.
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?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description is mostly complete: it explains what the tool does and what inputs it accepts. However, it could be more specific about the return value (e.g., that it returns a single object with fields like title, authors, year) to fully compensate for the lack of an output schema.
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%; the schema already thoroughly explains 'paper_id' with examples of accepted formats. The description's mention of accepted ID types largely duplicates the schema without adding new meaning. Thus, a baseline of 3 is appropriate.
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?
The description clearly states the tool's function: 'Get detailed metadata for a paper by ID.' It names a specific resource (paper) and the action (get metadata), and the list of accepted ID types (S2 ID, DOI, arXiv, PhilArchive) further distinguishes it from sibling tools like get_citations or search_papers.
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?
The description implies when to use the tool (when you have a paper ID and want metadata) but does not explicitly mention alternatives or exclusions. It does not say 'For searching, use search_papers' or 'For full text, use get_pdf.' The context is clear but not prescriptive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the rate limit (2 req/sec) and the side effect of updating the local cache, but it omits details about return format, error handling, or idempotency, which are important for an agent to safely invoke this tool.
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?
The description is a concise three sentences, front-loaded with the core action, and each sentence adds value: purpose, rate limit, and usage context. There is no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description is responsible for explaining return values. It does not state what the agent can expect in response (e.g., harvested records, status, or count), nor does it discuss error conditions. While it covers purpose and rate limit, the lack of behavioral details makes it incomplete for reliable invocation.
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?
The input schema provides full descriptions for both parameters (from_date, max_records) including defaults and bounds. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate given the high schema coverage.
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?
The description clearly states the specific verb 'harvest' and resource 'papers from PhilArchive OAI-PMH', with 'incrementally' indicating scope. This distinguishes it from sibling search/get tools, which focus on individual paper retrieval rather than batch cache updates.
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?
The phrase 'Run periodically to update local cache' gives clear context for when to use this tool. However, it does not explicitly name alternatives or state when not to use it, so it falls short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states the basic action ('remove') without addressing permanence, side effects, or idempotency. It does clarify the scope ('personal library') but omits behavioral nuances expected of a destructive operation.
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?
Single sentence, front-loaded with the verb, no filler. Direct and efficient.
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?
For a simple single-parameter removal tool with no output schema, the description is sufficient to understand the operation. It could mention reversibility but is otherwise adequate for the low complexity.
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?
The schema fully documents the single parameter (paper_id) including acceptable identifier types, so parameter semantics are fully covered by the schema. The description adds no new information beyond the schema, hence 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?
The description uses the specific verb 'Remove' and clearly identifies the resource ('a saved paper from your personal library') and the accepted identifier formats. This distinguishes it from sibling tools like library_add (adds) and library_list (lists).
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?
The description conveys a clear use case: when the user wants to delete a paper from their personal library. It doesn't explicitly mention alternatives or exclusions, but the context is unmistakable, warranting a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the fallback order (Semantic Scholar first, then PhilArchive), which is a useful behavioral trait. However, it does not mention what happens when no PDF is found, access restrictions, or rate limits, leaving important behavioral gaps.
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?
The description is a single sentence, front-loaded with the primary action and no filler. It earns its place by adding the fallback detail without unnecessary length.
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?
For a simple one-parameter tool with no output schema, the description adequately conveys what it does and the fallback behavior. It could be more complete by explicitly distinguishing from download_paper or stating failure behavior, but the tool's simplicity keeps it largely sufficient.
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?
The schema covers 100% of parameter details, describing paper_id as an 'S2 ID, DOI, or PhilArchive ID'. The description does not add any additional semantics beyond the schema, so the baseline score of 3 is appropriate.
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?
The description clearly states 'Get PDF URL for a paper' with a specific verb (get) and resource (PDF URL). It distinguishes itself from siblings like get_paper (metadata) and download_paper (actual download) by focusing on URL retrieval, and adds precision with the fallback logic between Semantic Scholar and PhilArchive.
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?
The description implies usage when a PDF URL is needed and provides clear context about the fallback order. It does not explicitly mention when not to use it or name alternative tools, but the primary use case is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains metadata resolution from Semantic Scholar/CrossRef and the side effect on reviews. However, it doesn't mention idempotency, duplicate handling, authentication, or return behavior, which are relevant for an add/write operation.
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?
The description is three sentences long, front-loaded with the core action, and contains no filler. Each sentence carries useful information: what it does, how it stores metadata, its connection to recommendations, and accepted input formats.
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?
For a simple write tool with 3 parameters and no output schema/annotations, the description covers the main aspects: action, input types, metadata resolution, and downstream use. It doesn't describe return values or error handling, but these are minor gaps given the tool's simplicity.
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 coverage is 100% with all parameters described, so the baseline is 3. The description repeats the accepted ID types and adds context about metadata resolution, but doesn't provide new syntax, examples, or constraints beyond the schema.
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?
The description states a specific verb ('Save') and resource ('a paper to your personal library'). It also distinguishes the tool from siblings like library_remove and library_list by referencing the 'arxiv-sanity library primitive' and its role in feeding `recommend`.
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?
The description gives clear context for when to use the tool (saving a paper to a personal library) and lists the accepted identifier formats. It doesn't explicitly name alternatives or exclusions, but the sibling list makes the distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry transparency. It reveals that this is a local cache search, which is useful. However, it does not specify read-only safety, pagination, or potential response behavior. For a simple search tool, the disclosure is adequate but not rich.
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?
Two concise sentences, front-loaded with the action and resource. No filler or redundancy; every word contributes to clarity.
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?
For a simple search tool with two well-documented parameters and no output schema, the description covers the essential purpose and a key use case. It could mention return ordering or default behavior, but it is sufficiently complete for the tool's complexity.
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 the baseline is 3. The description adds no extra parameter detail beyond what's already in the schema, such as 'matches title and abstract' or limit defaults.
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?
The description uses a specific verb ('Search') and clearly identifies the resource ('local PhilArchive cache'), which immediately distinguishes it from siblings like search_papers and search_openalex. The contrast with Semantic Scholar further clarifies its scope.
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?
It explains when to use the tool ('for finding philosophy papers that may not be in Semantic Scholar'), giving a clear context relative to alternatives. It doesn't explicitly name sibling tools, but the Semantically Scholarly context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses ordering (newest first), optional tag filtering, and an extra output (the set of tags in use). It does not mention pagination or empty state, but for a simple list tool this is adequate.
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?
Two sentences, front-loaded with the main verb and resource. Every word earns its place, and there is no 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?
For a one-parameter list tool with no output schema, the description covers the essential behaviors: ordering, filtering, and supplementary tag reporting. The only minor gap is ambiguity about what 'newest' refers to (date added vs. publication date), but otherwise it is sufficient.
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?
The input schema already fully describes the tag parameter ('Only list papers carrying this tag'), and the description merely rephrases this concept. No additional examples, edge cases, or parameter nuances are added.
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?
The description clearly states the action (list) and resource (papers in your personal library), with specific behavioral details like newest-first ordering and optional tag filtering. It distinguishes itself from siblings such as search_papers and library_add.
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?
The context is unambiguous: this is for listing the user's own library, which contrasts with sibling search/retrieval tools. However, it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does disclose a key operational trait: OpenAlex and its OA PDFs are reachable by automated clients, unlike Cloudflare-walled PhilArchive. It doesn't mention rate limits or auth requirements, but for a read-only search API the accessibility note is valuable and beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main purpose, then context, then specific flag guidance. No redundant words; every sentence earns its place.
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?
The description covers purpose, differentiation, and key flags, and hints at output through 'OA PDFs it points to.' With no output schema, a bit more detail about the return shape would help, but the tool is a search and the description is sufficient for an agent to select and invoke it correctly.
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 coverage is 100% with each parameter described, so the baseline applies. The description repeats the meaning of philosophy_only and open_access_only but adds no additional syntax, defaults, or parameter interrelationships beyond the schema.
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?
The description opens with a specific verb+resource: 'Search papers via OpenAlex with open-access full-text discovery.' It clearly distinguishes from siblings by contrasting with Semantic Scholar and PhilArchive, making its unique role obvious.
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?
The description gives clear context for when to choose OpenAlex: it complements Semantic Scholar and is reachable by automated clients unlike PhilArchive. It also directs the agent to use philosophy_only and open_access_only, though it stops short of explicitly naming which sibling tool to use instead in which scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavior. It does so well by explaining the SPECTER-based similarity, the re-ranking behavior with category_id, that results remain under 'related' with proximity tiers, and that the ordering is not an authoritative classification. This adds meaningful context beyond a simple 'get similar papers' phrasing.
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?
The description is two sentences, front-loaded with the core purpose in the first sentence and the optional category_id behavior in the second. Every clause earns its place, with no redundant text or filler.
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?
Given the tool's moderate complexity (3 params, no output schema, no annotations), the description is quite complete. It covers the core functionality, explains how the optional parameter modifies the behavior, and warns about the non-authoritative nature of the re-ranking. The detailed schema descriptions for parameters fill any remaining gaps about defaults and tiers.
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 the baseline is 3. The description adds some semantic context for category_id ('semantic lens') but the schema already thoroughly documents each parameter, including the effect of category_id and limit defaults. Therefore, the description provides marginal added value beyond the schema.
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?
The description clearly states the tool's purpose: 'Get papers similar to a given paper (recommendations based on SPECTER embeddings).' This uses a specific verb ('get') and a specific resource (related papers), and distinguishes it from citation-based sibling tools like get_citations and get_references by explicitly mentioning SPECTER embeddings.
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?
The description provides clear context for when to use the tool (for similar-paper recommendations) and explains the conditional usage of category_id to re-rank results. However, it does not explicitly exclude alternatives or mention when not to use it versus sibling tools, stopping 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return format at a high level ('metadata, abstracts, and PDF URLs where available') and significantly discloses the non-obvious category_id behavior, including that it is a 'semantic lens' with relative proximity tiers and 'NOT an authoritative classification.' This goes beyond typical search tool descriptions, though it does not mention potential fallbacks or failure modes, which would have pushed it higher.
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?
The description is two sentences, front-loaded with the primary purpose. The second sentence, while long, is essential for explaining the complex category_id re-ranking mechanism and its caveats. Every sentence earns its place, and there is no filler or redundancy.
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?
The description is complete for a search tool of this complexity: it covers the main behavior, outputs, and the one complex parameter (category_id). It lacks an explicit mention of the OpenAlex fallback behavior (which appears only in the schema's category_id description), and there is no output schema so return details are only high-level. However, given the rich schema and the tool's purpose, the description covers the essential context well.
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?
The schema already provides 100% parameter coverage, so the baseline is 3. The description adds substantial meaning beyond the schema by explaining the category_id parameter's semantic-lens behavior, tagging tiers, and non-authoritative nature — details not present in the parameter description. This raises the score above baseline, though it does not address other parameters since the schema already covers them adequately.
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?
The description opens with 'Search for philosophy papers using Semantic Scholar,' which clearly states the verb (search) and resource (philosophy papers) plus the specific data source (Semantic Scholar), distinguishing it from siblings like search_philarchive and search_openalex. It further specifies outputs ('metadata, abstracts, and PDF URLs') and explains the optional category_id re-ranking behavior, making the tool's purpose unambiguous.
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?
The description provides clear context for when to use the tool ('Search for philosophy papers using Semantic Scholar') and gives detailed guidance for the optional category_id parameter, including how to obtain it ('from browse_taxonomy') and what it does. However, it does not explicitly exclude alternatives or state 'use this instead of search_openalex when...' — the differentiation is implicit rather than explicit, so it stops 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes full responsibility for behavioral disclosure. It clearly reveals that the mapping is inferred rather than authoritative, notes varying confidence levels across category types, and describes the ranking and tagging of results. This provides essential context about the tool's limitations and behavior.
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?
The description is compact yet comprehensive, covering purpose, input source, reliability caveats, and output characteristics in a well-organized manner. Each sentence adds meaningful information without redundancy.
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 tool with no output schema, the description adequately explains what is returned (papers ranked by citation count, tagged with proximity). It also provides the necessary context about the inference limitations and input requirements, making it complete for an agent to decide when and how to use it.
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 coverage is 100%, with both limit and category_id fully described in the schema. The description adds some context by referencing browse_taxonomy as the source for category_id, but this is already in the schema. No additional parameter semantics beyond what the schema provides.
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?
The description clearly identifies the tool as listing influential papers near an inferred semantic region for a PhilPapers category, using specific language ('inferred semantic region', 'SPECTER2 centroid') that distinguishes it from sibling tools like search_papers or get_related. It also explicitly states what it is NOT, reinforcing its purpose.
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?
It instructs to pass a category_id from browse_taxonomy, establishing the required input source. It also warns about reliability based on category granularity, implying appropriate use cases. However, it does not explicitly name alternative tools for different scenarios (e.g., search_papers for keyword search).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the storage path and environment variable override, the multi-step behavior, the returned paper_id for read_paper, and the significant limitation that PhilArchive PDFs are not fetched due to Cloudflare. This exceeds typical descriptions and provides actionable transparency.
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?
Two sentences, front-loaded with the core action, and each clause earns its place: the storage path, return value for read_paper, and PhilArchive exception all add critical context. No wasted words.
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 tool with no output schema and no annotations, the description is complete enough: it explains what it does, side effects (storage), return value (paper_id), and a key edge case (PhilArchive). It also hints at integration with read_paper. Given the complexity, this is a well-rounded description.
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?
The input schema already provides 100% description coverage for both parameters (paper_id and title). The description adds no additional parameter semantics beyond what the schema states, so the baseline of 3 applies.
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?
The description clearly states a specific multi-step action: resolve an open-access PDF, fetch it, extract text, store as markdown, and return a paper_id slug. It distinguishes itself from siblings like get_pdf (just PDF retrieval) and read_paper (reads stored markdown) by describing the local storage and integration with read_paper.
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?
The description implies when to use this tool: when you want a paper downloaded, processed, and stored for later reading via read_paper. It explicitly covers the PhilArchive exception (browser-only, return URL instead of fetching), providing alternative handling. It does not fully contrast with sibling tools like get_pdf, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses pagination, the storage path, shared access with arxiv-mcp-server, and error behavior when the paper is missing. It does not cover return format beyond 'markdown text', which is acceptable for a read operation.
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?
Three tightly worded sentences lead with the core purpose, then pagination, then storage/error context. No redundant information; every sentence earns its place.
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?
The description fully covers the tool's purpose, prerequisite (download_paper), pagination mechanism, storage location, and error handling. Given no output schema and no annotations, this is complete for a simple read operation.
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?
Although schema coverage is 100% with per-parameter descriptions, the tool description adds meaning by explaining paper_id as a slug returned by download_paper and that start/max_chars control pagination. This enriches the schema's basic descriptions.
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?
The description states the tool reads back the markdown text of a paper previously stored by download_paper. This is a specific verb (read) and resource (stored paper markdown), and it clearly differentiates from siblings like get_paper or get_pdf by requiring prior storage.
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?
It explicitly states the tool operates on papers previously stored by download_paper and that an error is returned asking to download_paper first if not stored. This gives clear context for when to use it, though it does not explicitly compare to alternatives like get_paper.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behavioral traits: the hierarchy is a cached snapshot from a Cloudflare-blocked API, query overrides category_id, and category_id is optional. It also notes the semantic lens is inferred, not authoritative. It could add more detail about output structure, but the core behavior is clearly communicated.
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?
The description is well-structured and front-loaded, with the most important information in the first sentence. Every sentence adds value: the cache caveat, parameter usage, sibling tool integration, and a clarifying note about authority. No waste or redundancy.
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?
Given there is no output schema or annotations, the description does a solid job explaining the tool's operation and limitations. It covers the two browsing modes (top-level and subcategories) and search behavior. It doesn't explicitly describe the return format, but for a simple category listing tool, the description is sufficiently complete for an agent to select and invoke it correctly.
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 adds meaning beyond the schema by explaining the interplay of parameters: omitting category_id yields top-level areas, passing it lists subcategories, and query overrides category_id. This provides practical usage context not present in the raw schema properties.
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?
The description clearly states the tool's function: 'Browse the expert-curated PhilPapers category hierarchy.' It specifies the resource (categories) and the action (browse), and differentiates from siblings like category_papers, search_papers, and get_related by explicitly showing how category_id can be used with those tools, but this tool itself is for listing categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Omit category_id for the top-level areas; pass category_id to list its subcategories; pass query to find categories by name.' It also explains how to leverage the result with sibling tools ('call category_papers... or pass it as the category_id param to search_papers / get_related'), including a caveat about the inferred semantic lens. This clearly distinguishes when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it reveals the default behavior (whole library), the role of SPECTER2 embeddings, that library papers are excluded, and the risk of HTTP 429 rate limiting without an API key. This goes well beyond a basic statement of function.
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?
The description is three focused sentences: purpose, configuration paths, and a caveat. It is efficiently front-loaded with the primary purpose and uses minimal words to convey multiple behaviors. No filler.
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?
Given the tool has no output schema and no annotations, the description covers all essential aspects: default operation, parameter-driven alternatives, algorithmic basis, exclusion logic, and a practical rate-limit warning. For a recommendation tool with three optional parameters, this is complete.
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 baseline is 3. The description adds semantic meaning by framing 'tag' as selecting 'one reading-list bucket' and 'paper_ids' as 'ad hoc from specific papers', which clarifies their intent beyond the schema's property descriptions. It also mentions the default limit indirectly, reinforcing the schema's default.
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?
The description starts with a specific verb 'Recommend' and a clear resource 'papers to read next, seeded by your library'. It explicitly identifies the arxiv-sanity 'more like these' feature, distinguishing it from sibling tools like get_related which likely operate on a single paper. The purpose is unambiguous.
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?
The description explains when to use the default whole-library seeding versus passing 'tag' or 'paper_ids', providing clear usage context. It does not explicitly name alternative tools or exclusion criteria, but the seeding-from-library vs. ad-hoc distinction effectively guides tool selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![sophotron MCP server](https://glama.ai/mcp/servers/rookslog/sophotron/badges/card.svg)](https://glama.ai/mcp/servers/rookslog/sophotron)

Score Badge

Copy to your README.md:

[![sophotron MCP server](https://glama.ai/mcp/servers/rookslog/sophotron/badges/score.svg)](https://glama.ai/mcp/servers/rookslog/sophotron)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rookslog/sophotron'

If you have feedback or need assistance with the MCP directory API, please join our Discord server