terminal_kb

by xuj1nfan

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
get_passage, get_document, get_page_image, and index_status are clearly distinct, but search_library and find_evidence overlap heavily since both search the same evidence set for relevant passages. The descriptions add some differentiation, but an agent could still easily pick the wrong one for a general search.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern: search_library, get_passage, get_document, get_page_image, find_evidence. The exception is index_status, which is a noun phrase instead of something like get_index_status, but this is only a minor consistency break.
Tool Count5/5
Six tools form a tight, well-scoped set for an evidence-retrieval knowledge base. Each tool maps to a specific step in the workflow of searching, retrieving, and verifying evidence, with no unnecessary bloat.
Completeness4/5
The core research workflow is covered: search, retrieve passages, inspect page images, check metadata, and monitor index status. Notable gaps are full-document text retrieval and index/database management, but agents can still complete the primary evidence-checking task with the provided tools.
Average 3/5 across 6 of 6 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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 the full burden, but it only says 'indexed PDF and Markdown evidence.' It adds the context that only indexed files are searched and scopes the file types, but it does not explain ranking, snippet behavior, or any effects on state.
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 a single, very short sentence with no filler words, so it is concise. However, it is arguably too short for a tool with three parameters and a potentially ambiguous search behavior, making it under-specified rather than appropriately complete.
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?
With no annotations, no output schema, and an inadequate parameter description, the description fails to explain essential invocation details such as how to form queries, what the returned evidence looks like, or how 'limit' and 'citekey' affect results. For a simple search tool, the minimal context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about 'query', 'limit', or 'citekey'. The agent is left to guess what each parameter means and which are required beyond the schema's structural hints.
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 performs a search over indexed PDF and Markdown content, giving the agent a specific verb and resource. Though it does not name sibling tools, the 'search' operation is distinct from the get_* retrieval tools and find_evidence appears to be a broader alternative.
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 about when to use this tool versus alternatives like find_evidence or get_document. There are no exclusions, prerequisites, or hints about what makes this the right choice.
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 behavioral burden. 'Retrieve' implies a read-only action, but the description does not disclose response contents, error behavior if the citekey is unknown, authentication requirements, or exactly what 'index status' means.
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 a single short sentence with no filler or redundancy. It is concise, though it could be more informative without becoming bloated.
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?
With no output schema and no annotations, the description is too thin to give an agent enough context: it lacks return details, failure modes, citekey semantics, and any contrast with deeply related sibling tools like index_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description never mentions citekey or what it represents. The only signal is the property name itself, which is insufficient for an agent to know what a valid citekey looks like or where to obtain it.
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 states a specific action ('Retrieve') and resource ('document metadata and index status'), which clearly separates it from tools like get_passage or get_page_image. It does not, however, explicitly contrast it with sibling index_status or note that this is per-document status.
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?
There is no guidance on when to use get_document versus siblings like search_library, get_passage, or index_status. The description only states what it does, not when it should be chosen over alternatives.
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, the description must carry the behavioral disclosure burden, but it is ambiguous whether 'verify passages before citing' is a tool behavior or an instruction to the agent. It does not disclose what the tool returns, whether it validates passages, mutual performance, or side effects, leaving behavioral understanding uncertain.
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 fits in one short sentence with two clauses, both contributing: the first states the primary purpose, the second the critical usage warning. It is front-loaded and free of fluff.
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, no annotations, and the description does not explain what the returned passages look like, how to interpret them, or what effects 'limit' influences. Given the claim-relevance domain, an expert agent needs more guidance about the result format and ratio with sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It indirectly covers 'claim' by referencing a claim, but it never mentions the 'limit' parameter or its role, relying entirely on the parameter name and default value. This is insufficient for full compensation.
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 states a specific action ('Find passages') with a clear scope ('relevant to a claim'), which distinguishes it from siblings like get_document or get_passage. However, it does not explicitly contrast with search_library, so the differentiation is implicit rather than named.
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 phrase 'relevant to a claim' implies the tool is for claim-driven evidence retrieval, and 'verify passages before citing' suggests a downstream verification step. But the description provides no explicit when-to-use vs. alternatives, nor any exclusions among the listed sibling tools.
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, the description carries the full behavioral disclosure burden. It signals a read-only operation through 'Retrieve' and indicates exactness, but it does not describe what happens when a passage is not found, whether page or chunk_id is the lookup key, or what the response structure will be. These gaps limit an agent's ability to anticipate the tool's 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 a single, front-loaded, unambiguous sentence with no padding. Every word contributes meaning and the key information is placed at the start.
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?
Given there are 3 params, no annotations, no output schema, and no sibling disambiguation, the description is too sparse for an agent to invoke this tool confidently. It does not explain which combination of page, citekey, and chunk_id forms a valid call, nor what the passage retrieval semantics are. The missing guidance matters because the schema marks all params as optional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the three undocumented parameters. It mentions 'citekey' and 'page metadata,' but it does not clearly map these to the page, citekey, or chunk_id schema fields, and it never addresses chunk_id. The agent still has to guess how parameters act together.
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 states a specific verb ('Retrieve') and resource ('exact indexed passage') with the metadata that is included ('citekey and page'), so an agent can tell it is a deterministic lookup rather than a general search. It doesn't explicitly differentiate it from siblings like get_document or get_page_image, but the focus on an indexed passage is enough to distinguish it broadly.
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 words 'exact' and 'indexed' imply it should be used when a specific known identifier exists, suggesting a use case: retrieve an already-indexed passage rather than searching. However, it does not explicitly say when this tool should be chosen over search_library, get_document, or get_page_image, nor does it name any alternative.
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 behavioral disclosure. It explains the intent but does not disclose what the output looks like (image format, inline vs. URL), whether the page is rendered at the given DPI without modification, how out-of-range pages are handled, or any performance implications of rendering.
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 that is immediately informative and free of filler. It front-loads the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and cryptic parameters, the description is far from sufficient for an agent to call and interpret results correctly. Missing key details include the meaning of citekey, acceptable page ranges, output format, and error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter-level explanation. Citekey is not mentioned at all, page format and indexing are unspecified, and dpi is left to be inferred from its default value. The description does not compensate for the empty schema 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 clearly states the action ('Render'), the resource ('a PDF page'), and the use case ('visual verification of formulas, tables, and figures'). This strongly differentiates it from sibling tools like get_passage or get_document, which retrieve text or documents.
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 'for visual verification' implies this tool is intended when visual inspection of rendered content is needed, distinguishing it from text-based retrieval tools. However, it does not explicitly state when not to use it or mention alternative tools.
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?
The verb 'Show' implies a read-only, non-mutating operation, and the phrase 'status' reinforces that no data is changed. However, with no annotations and no additional context, the description does not disclose whether the tool refreshes the catalog, could return stale data, or has any side effects; this is minimal but not fully transparent.
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 one short, front-loaded sentence with no filler, redundant phrasing, or unnecessary details. Every word contributes to the meaning, and it is appropriately sized for a zero-parameter status tool.
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?
For a simple zero-input status tool, the description is adequate to initiate invocation. However, there is no output schema, and the description does not clarify what values or detail are returned (e.g., index state, last update time, catalog names), leaving some uncertainty about how to interpret the result.
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?
There are zero parameters, so the schema is trivially complete at 100% coverage. The description does not need to explain parameter meaning, and the absence of parameters is itself a useful signal that invocation requires no arguments.
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 ('Show') with a clear resource ('local catalog and index status'). It is semantically distinct from the sibling tools, which are all retrieval-oriented operations, and it immediately signals this is a status/inspection tool rather than a document/evidence lookup.
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?
There is no explicit guidance about when to call this tool vs. the identified siblings. The absence of an alternative status tool makes the intended use inferable, but the description never states prerequisites or conditions (e.g., 'use after indexing' or 'use to diagnose search issues').
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:

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

Score Badge

Copy to your README.md:

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

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/xuj1nfan/knowledge_base'

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