Lore Agent

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes (query, save, ingest, validate, fetch, list, lint, scan, build, import). However, save_research, capture_answer, and ingest_source all persist knowledge cards with different input formats, which could cause confusion despite detailed descriptions.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case (e.g., query_knowledge, save_research, fetch_url). Verbs are descriptive and the pattern is predictable across all 12 tools.
Tool Count5/5
12 tools is well-scoped for a knowledge management server. The set covers querying, saving, ingesting, validating, listing, linting, scanning dead links, building graphs, and importing notes—no bloat or deficiency.
Completeness3/5
The tool surface covers create (save, capture, ingest), read (query, list), and checking tools, but lacks update and delete operations for knowledge cards. This is a notable gap that could hinder full life cycle management.
Average 4.3/5 across 12 of 12 tools scored. Lowest: 3.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 123 commits in the last 12 weeks
- Last stable release on June 1, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the action but does not disclose side effects (e.g., overwriting existing notes), authentication requirements beyond the optional token, or validation 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?
A single, grammatically correct sentence that conveys the core purpose without any unnecessary words or fluff.
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?
While an output schema exists, the description lacks context about the PaperPulse integration, prerequisites, and how it differs from ingest_source. This is adequate but not fully complete for a tool with specific external dependency.
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%, so the schema already documents both parameters adequately. The description adds no additional meaning 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 a specific verb ('Import') and resource ('distilled paper note from PaperPulse SaaS into local Scholar Agent knowledge base'), which distinguishes it from siblings like ingest_source or save_research that are more generic.
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 the tool is for importing from PaperPulse but provides no explicit guidance on when to use it vs alternatives, nor any prerequisites or exclusions.
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?
No annotations are provided, so the description carries full burden. It describes a read-only listing operation with no side effects, but does not disclose any potential limitations like pagination or performance considerations.
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 that front-load the core purpose and list return fields. No wasted words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema existing, the description adequately covers the tool's purpose and basic parameter. It could mention it's a local knowledge base listing, but overall it is complete for simple browsing.
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% for the single optional parameter. The description adds minimal extra meaning beyond the schema, stating it's optional and returns all if omitted. Baseline 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 uses specific verbs and resources: 'List all knowledge cards' and returns specific metadata fields. It clearly distinguishes from siblings like 'query_knowledge' which likely searches or filters.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The context of sibling tools implies it's for browsing all cards or filtering by topic, but no alternatives are mentioned.
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 fully discloses behavioral traits: it creates knowledge cards, enforces quality requirements, and best-effort snapshots source URLs. It explains side effects like background snapshots and the persistence of cards, which is sufficient for a non-destructive 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy and includes many details that could be separated or placed in schema annotations. While it is well-organized with headings (IMPORTANT, When to include, etc.), it is not concise and may overwhelm agents scanning for quick purpose.
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 complexity (5 parameters, no annotations, output schema exists), the description is exceptionally complete. It covers output format, quality constraints, visual aid placement, source handling, and language rules, leaving no ambiguity about what the tool does and expects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 dramatically adds value by elaborating on the answer_json structure, quality rules, language expectations, visual_aids inclusion logic, and source referencing. This far exceeds the brief schema descriptions, making parameter usage clear and correct.
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 clear verb+resource: 'Save structured research results as a knowledge card in the local knowledge base.' This explicitly states the tool's function and distinguishes it from read-only or ingestion tools like query_knowledge or ingest_source.
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 warns against using the tool for 'trivial facts or one-sentence answers,' but it provides no explicit guidance on when to choose this tool over siblings like capture_answer or validate_knowledge. The absence of alternatives or when-not-to-use scenarios limits its usefulness for tool selection.
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 full burden. It discloses that for URLs it fetches page content and extracts text, and for text it saves directly. However, it does not cover potential errors, idempotency, or what 'draft card' entails (e.g., whether it's editable). This is adequate but not comprehensive.
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 concise, front-loaded with the core action, and uses clear bullet-like statements for URL vs text behavior. Every sentence adds value with no 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 complexity (4 parameters, simple types, output schema exists), the description covers the main use cases and key behaviors. It could mention error handling or the draft card concept more explicitly, but overall it is sufficient for an 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 4 parameters described). The description adds value by explaining the behavioral difference between URL and text input, and emphasizing the language constraint for Chinese text ('MUST be in Chinese'). This goes beyond the schema descriptions for 'source' and 'language', making parameter semantics clearer.
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 ingests a URL or raw text into the knowledge base as a draft card, with specific behaviors for each type. It distinguishes from sibling tools like fetch_url (which only fetches) and save_research (which likely expects structured JSON) by emphasizing 'without requiring structured JSON'.
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 explicitly says 'Use this when you want to add external documents, articles, or notes to the knowledge base without requiring structured JSON,' providing clear context. It implies not to use for structured data but does not name specific 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses that the tool generates a self-contained HTML file and returns its path. Potential side effects like processing time for large knowledge bases are not mentioned, which prevents a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with four sentences. The first sentence clearly states the purpose, and subsequent sentences add details. However, the phrase 'self-contained HTML file' could be merged with the next sentence to reduce redundancy. Still, it 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?
Given the lack of annotations, no parameters, and the presence of an output schema (which likely describes the return path), the description is complete enough to guide an agent. It covers what the tool does, the output format, and even compatibility. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description fully compensates by explaining what the tool does without needing to describe parameter semantics. The description adds value beyond the schema by detailing the output and compatibility with Obsidian vaults.
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 verb 'build' and the resource 'knowledge graph visualization.' It distinguishes itself from sibling tools by specifying it generates an interactive HTML graph, unlike query_knowledge or list_knowledge. The purpose is specific and 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?
While there is no explicit when-to-use or when-not-to-use guidance, the description implies use when wanting to visualize knowledge cards as nodes and wiki-links as edges. None of the sibling tools serve a similar purpose, so differentiation is naturally clear. A slight improvement would be to explicitly mention not to use for non-graph queries.
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 fully carries the behavioral burden. It explicitly states the tool is read-only and never edits files, and enumerates the exact checks performed, providing complete 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?
The description is two concise sentences, front-loading the purpose and listing actions without any filler. Every sentence contributes value.
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 one parameter, no annotations, and an output schema (inferred), the description covers the tool's scope well. It mentions all performed checks and the parameter.
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 single parameter 'stale_days' is fully described in the input schema. The tool description already mentions stale_days in context, so the description adds minimal extra meaning 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: 'Run read-only content health checks' on the 'local knowledge base.' It lists the specific checks (orphan cards, broken wiki-links, stale cards, overlapping titles) and states it never edits files, making the purpose distinct from siblings.
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 for health checks but does not explicitly state when to use this tool versus alternatives like scan_dead_links or scan_stale_knowledge. However, it is clear that this is a composite check tool.
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?
No annotations exist, so description must disclose behavior. It describes return format (top-k, scores, content), implying read-only. Could add more detail on response structure, but sufficient for a search 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?
Two concise sentences with a clear usage directive. Zero fluff, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, description doesn't need to detail return values. It covers purpose, usage, and basic input semantics. Complete enough for a simple search tool.
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%, so parameters are already well-documented in the schema. The description adds no further semantic meaning beyond the schema's own descriptions, meeting baseline expectations.
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 searches the local knowledge base, returns top-k cards with scores and content, and distinguishes it from sibling tools like fetch_url or save_research.
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?
Explicit guidance to 'use this to find existing knowledge before doing web research' tells the agent when to invoke this tool and implies alternatives (web research 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?
No annotations, but description clearly states 'without modifying files' and lists validation types (frontmatter, body-density, source-freshness). No behavioral surprises.
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: purpose, scope, usage. No fluff. Front-loaded with key action and resource.
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 simple tool (1 optional param, output schema exists), description covers purpose, behavior, and usage. Adequate for AI agent decision-making.
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 description coverage is 100%, and description adds context for the verbose parameter: 'include warning-only cards in the per-card report.' Adds value beyond 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 explicitly states 'Validate local knowledge cards' with a specific verb and resource. It distinguishes from siblings like lint_knowledge by mentioning body-density/source-freshness checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context: 'Use this before relying on a knowledge base or after bulk imports.' Does not explicitly contrast with alternatives, but the guidance is helpful.
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?
The description discloses key behaviors: it saves a local snapshot with captured_at to prevent link rot, and the returned content_md is truncated by max_chars while full content is in the snapshot. Since no annotations are provided, the description fully carries the burden of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but somewhat verbose, mixing English and Chinese. It includes a typical usage flow that adds value, but could be streamlined. It is structured with clear sections but overall slightly long for a tool description.
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 complexity (external fetch, snapshot, truncation) and the presence of an output schema (so no need to detail return values), the description is complete. It covers purpose, behavior, usage flow, and parameter implications adequately.
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% with descriptions for both params (url and max_chars). The description adds context: max_chars controls returned content length and that full content is in the snapshot, which is beyond the schema's default value and description. Baseline 3 plus extra value justifies 4.
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 action: 'Fetch a web URL and return its main content as markdown.' It emphasizes first-hand retrieval (G5) and distinguishes itself from siblings like save_research, which saves knowledge cards, and query_knowledge, which retrieves stored knowledge.
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 a typical usage flow: 'fetch_url to fetch primary source → write deep answer with specific numbers/mechanisms → save_research to save card.' It explicitly connects to the sibling tool save_research and implies when to use (before saving). However, it doesn't 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: probing strategy (HEAD then GET), result fan-out, handling of paywalled (blocked) and offline (skipped), and explicitly states read-only. No contradictions.
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 concise sentences, front-loaded with purpose, no fluff. Each sentence adds distinct information (purpose, method, constraints).
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 output schema exists, no need to explain return values. Parameters are fully covered in schema and description. Complexity is moderate; description handles all aspects clearly.
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%, but description adds value: offline=skip network probes, timeout=per-request, concurrency=maximum concurrent probes. Only minor gap: no format details beyond 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?
Description starts with 'Diagnose dead source URLs' (specific verb+resource) and clarifies scope 'across knowledge cards.' Distinguishes from siblings like fetch_url (single URL fetch) and scan_stale_knowledge (stale content).
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?
Implies usage for diagnosing dead links, but lacks explicit when-to-use or when-not-to-use vs. alternatives. Could mention not for single URL checking (fetch_url) or content validation (validate_knowledge).
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?
No annotations provided, so the description carries the full burden. It discloses the 150-character minimum, content expectations, and the type of answer suitable. However, it does not mention any side effects or authorization requirements, though the tool is likely non-destructive. Overall, good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and then provides clear usage guidelines in a bullet-like structure. While slightly verbose, every sentence adds value, and the structure is logical and easy to parse.
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?
With output schema present and full schema coverage, the description covers purpose, usage guidelines, parameter semantics, and context relative to siblings. It is complete enough for an AI agent to correctly select and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value: clarifies tags as optional, language defaults, and importantly the 150-character minimum for answer. It also explains the expected content quality, which goes beyond the schema's description.
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 captures a Q&A answer as a draft knowledge card, specifying it is for substantive answers from conversations. The verb 'capture' and resource are distinct and well-defined, and it differentiates from sibling tools like 'save_research'.
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?
Explicitly states when to use (substantive answers worth persisting) and when not to use (single-sentence, standard references, etc.), and provides a clear alternative: 'save_research' for structured evidence. This gives excellent guidance to an AI agent.
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?
Explicitly declares read-only behavior, which is critical since no annotations are provided. Describes the evaluation basis (source_date/captured year and domain policy), but doesn't mention other behaviors like performance or error handling.
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: purpose, sibling differentiation, read-only statement. Every sentence is necessary and front-loaded with purpose. No redundant information.
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 no parameters and an output schema exists, the description covers input (none), criteria (source freshness vs threshold), behavior (read-only), and sibling context. No gaps for a simple reporting tool.
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?
No parameters in schema, so baseline is 4. Description does not need to add parameter info. The description adds no param-specific details, which 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 'Report knowledge cards whose source freshness exceeds domain thresholds' – specific verb and resource with exact criterion. Contrasts with lint_knowledge to differentiate purpose.
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?
Explicitly tells when to use (check source freshness with domain-specific policy) and distinguishes from lint_knowledge by specifying different date field and policy, providing alternative context.
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:

[![scholar-agent MCP server](https://glama.ai/mcp/servers/zfy465914233/scholar-agent/badges/card.svg)](https://glama.ai/mcp/servers/zfy465914233/scholar-agent)

Score Badge

Copy to your README.md:

[![scholar-agent MCP server](https://glama.ai/mcp/servers/zfy465914233/scholar-agent/badges/score.svg)](https://glama.ai/mcp/servers/zfy465914233/scholar-agent)

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/zfy465914233/scholar-agent'

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