TOOL4LM is a versatile MCP server that enhances local or remote Large Language Models with a comprehensive suite of utility tools:
Mathematical Computing: Evaluate mathematical expressions with adjustable precision using calc.eval
Multi-Engine Web Search: Conduct searches across multiple engines like SearXNG and DuckDuckGo with web.search
Web Content Access: Fetch web pages securely with size/time limits (web.fetch) and extract readable content from HTML (web.read)
Local Document Management: Search within sandboxed directories (doc.find), read various file formats including text, markdown, HTML, and PDF (doc.read), and build/manage search indexes (index.build)
Academic Research: Search scholarly papers on platforms like arXiv and Crossref (sch.search), retrieve detailed metadata using DOIs or arXiv IDs (sch.get)
Wikipedia Integration: Search Wikipedia titles (wiki.search) and retrieve article summaries (wiki.get)
All tools support both dot notation and underscore aliases (e.g., calc.eval or calc_eval) for flexible integration.
Enables searching and retrieving academic papers and metadata from arXiv preprint repository
Provides access to academic paper metadata and information through DOI (Digital Object Identifier) lookups via Crossref
Enables web search functionality through DuckDuckGo's search engine with support for deduplication and result filtering
Provides web search capabilities through SearXNG metasearch engine instances with configurable endpoints
Allows searching Wikipedia articles and retrieving article summaries with multi-language support
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@TOOL4LM search for recent developments in quantum computing and summarize the top 3 results"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
All-in-one tools to supercharge your local or remote LLMs.
Search smarter. Calculate faster. Summarize better.
TOOL4LM là một MCP (Model Context Protocol) server viết bằng Node.js/TypeScript giúp bổ sung công cụ cho các mô hình ngôn ngữ chạy cục bộ (LM Studio/Ollama/…): web search, đọc & tóm tắt trang, tìm & đọc tài liệu nội bộ, tra cứu học thuật, và máy tính. Không cần API key mặc định.
🔎 Web Search: tìm nhiều nguồn (SearXNG + DuckDuckGo HTML), khử trùng lặp, trả về tiêu đề + URL + snippet.
🌐 Web Fetch/Read: tải trang có giới hạn kích thước/thời gian (chống SSRF) và trích văn bản “đọc được” để tóm tắt.
📂 Doc Search/Read: tìm & đọc tài liệu trong thư mục sandbox (txt/md/html/pdf). PDF dùng pdf-parse (lazy-load).
📚 Scholar Search/Get: tra cứu học thuật (arXiv + Crossref + Wikipedia) và lấy metadata theo DOI/arXivId.
🧮 Calculator: đánh giá biểu thức với mathjs, hỗ trợ precision (làm tròn).
Related MCP server: free-search-mcp
Tool | Khi nào dùng | Tham số (shape) |
| Tính toán cục bộ |
|
| Tìm web đa engine |
|
| Tải 1 URL (HTML/binary) |
|
| Trích văn bản “đọc được” |
|
| Tìm trong thư mục sandbox |
|
| Đọc 1 file trong sandbox |
|
| Build chỉ mục tài liệu |
|
| Tìm bài/paper/DOI |
|
| Lấy metadata paper |
|
| Tìm tiêu đề Wikipedia |
|
| Lấy summary Wikipedia |
|
Đã bật
openWorldHintnên nếu model lỡ thêm field lạ host vẫn chấp nhận; nhưng khuyến nghị dùng đúng tham số như bảng để ổn định.
npm install
npm run build
npm startKhi chạy thành công sẽ in:[TOOL4LM] started. Sandbox: <đường_dẫn_sandbox>
Thêm vào mcp.json của LM Studio:
{
"mcpServers": {
"TOOL4LM": {
"command": "node",
"args": ["--enable-source-maps", "C:/path/to/tool4lm/dist/server.js"],
"type": "mcp",
"env": {
"SANDBOX_DIR": "C:/path/to/your_docs",
"SEARXNG_ENDPOINTS": "https://searx.be/search,https://searx.tiekoetter.com/search",
"ENGINE_ORDER": "searxng,duckduckgo",
"LANG_DEFAULT": "vi",
"REGION_DEFAULT": "vn",
"MAX_FETCH_BYTES": "1048576",
"FETCH_TIMEOUT_MS": "8000"
}
}
}
}Trên Windows, nên dùng
/trong JSON để tránh escape\.
Tra cứu web có trích dẫn → web.search → web.fetch → web.read → tóm tắt + đính kèm URL.
Tài liệu nội bộ → doc.find → doc.read → tóm tắt + trích đoạn (ghi kèm path).
Học thuật → sch.search → sch.get theo DOI/arXivId.
Tính toán → calc.eval với ^/pow(a,b) (hoặc đã normalize **).
SANDBOX_DIR — thư mục tài liệu (mặc định: ./sandbox).
SEARXNG_ENDPOINTS — danh sách endpoint /search của SearXNG, cách nhau dấu phẩy.
ENGINE_ORDER — ví dụ searxng,duckduckgo.
LANG_DEFAULT, REGION_DEFAULT — gợi ý ngôn ngữ/khu vực khi tìm web.
MAX_FETCH_BYTES — giới hạn dung lượng tải trang.
FETCH_TIMEOUT_MS — timeout tải trang (ms).
Issues/PRs rất hoan nghênh! Nếu thấy bug/đề xuất, mở issue giúp mình nhé.
Nếu bạn thấy dự án hữu ích, có thể ủng hộ mình qua PayPal:
hoặc bấm nút bên dưới:
Evaluate math expression (no external calls).
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes | ||
| precision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the constraint 'no external calls', but does not expand on behavior beyond what annotations (openWorldHint) hint at. Additional context like return format or error handling is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded, and every word is useful. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain return values and error behavior, but it does not. The tool's completeness is insufficient given its complexity (2 params, no output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters, but it does not mention 'expr' or 'precision'. The description adds no value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Evaluate math expression (no external calls)' clearly states the action and resource, and distinguishes from sibling tools like web.fetch, doc.find, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like calc_eval or other calculation tools. The description lacks any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of calc.eval
| Name | Required | Description | Default |
|---|---|---|---|
| expr | Yes | ||
| precision | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond being an alias. The annotation 'openWorldHint: true' suggests unknown side effects, but the description does not clarify what those might be. For a tool with no annotation coverage on safety or behavior, the description should compensate but fails to do so.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, consisting of a single phrase. While concise, it is under-specified and does not convey enough information to be useful. It sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, two parameters with zero coverage, and no descriptive text, the definition is severely incomplete. The agent lacks critical context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters but does not. It mentions neither 'expr' nor 'precision', leaving the agent without context on their meaning, format, or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Alias of calc.eval', which indicates a relationship but fails to explain what the tool does. The name 'calc_eval' hints at evaluating a calculation, but without further context, the agent cannot discern its specific purpose. It does not distinguish itself from the sibling 'calc.eval'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided about when to use this tool versus alternatives. The description only states it is an alias, offering no context for usage scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search local documents within sandbox directory. Builds index if missing.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| top | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint: true, and description adds the behavioral trait 'Builds index if missing.' No further details on permissions, rate limits, or other side effects beyond index building.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description omits critical details about parameter semantics, return format, and use case boundaries. Output schema is absent, so description should compensate but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for parameters q, top, limit. The agent receives no help understanding what the query string expects or how top and limit control results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search local documents within sandbox directory' with a specific verb and resource, and distinguishes from siblings like doc.read (which reads a particular document) and index.build (which explicitly builds index).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like index.build for manual indexing, or doc.read for reading a known document. Also lacks query format or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of doc.find
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| top | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral details disclosed; annotation openWorldHint provides minimal context, but description adds nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short but lacks substantive content; under-specification is not good conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a tool with 3 parameters and no output schema; fails to provide needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter descriptions; schema coverage is 0% and description does not explain any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it is an alias of doc.find, but does not describe what doc.find does, leaving purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives; merely indicates it is an alias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a file from sandbox directory (text or pdf).
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only says 'Read' and does not add behavioral details beyond annotations. No mention of error handling, return format, or access restrictions. Annotations provide openWorldHint but no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Ultra-concise single sentence with all key elements: action, resource, location, file types. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool, but lacks differentiation from sibling doc_read (likely same tool) and does not specify output format or failure behavior. No output schema, so more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context: the 'path' parameter should be within sandbox directory and supports text/pdf files. This compensates for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read a file' with specific resource 'from sandbox directory' and file types 'text or pdf', which distinguishes it from sibling tools like doc.find (search) and others.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a read tool, but no explicit guidance on when to use vs alternatives like doc.find or doc_read. No when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of doc.read
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the openWorldHint annotation. It does not disclose read-only nature, side effects, or scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the expense of being informative. It is under-specified and fails to convey essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and parameter descriptions, the description should provide a self-contained explanation. It does not, leaving the agent without sufficient context to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain what the 'path' parameter represents. The agent has no semantic guidance for providing this argument.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states 'Alias of doc.read' without defining what the tool actually does. It fails to provide a verb-resource pair, and the agent gains no understanding of the tool's functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is given. The description implies interchangeability with doc.read but does not clarify when to use this alias over the original.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build MiniSearch index for documents in sandbox directory.
| Name | Required | Description | Default |
|---|---|---|---|
| root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only mentions building an index but does not disclose important behaviors such as whether it overwrites existing indexes, requires specific permissions, or has side effects beyond the 'openWorldHint' annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary details. It lacks structure such as parameter explanation or usage notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should indicate what the tool returns (e.g., success message, index path). It also fails to describe the parameter, making the tool incomplete for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'root' is not described in the schema (0% coverage) and the description does not explain its meaning or usage. The agent cannot infer what value to provide for 'root'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (build) and resource (MiniSearch index) with context (documents in sandbox directory). However, it does not differentiate from sibling tools like 'index_build' which likely perform similar indexing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling tools, explicit usage context is missing, leaving the agent to guess appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of index.build
| Name | Required | Description | Default |
|---|---|---|---|
| root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation includes openWorldHint but description adds no behavioral detail. No mention of side effects, permissions, or output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of informativeness. It is under-specified, not concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description still fails to explain the tool's purpose or parameter meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'root' is undocumented. With 0% schema description coverage, the description should add meaning but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Alias of index.build' but does not state what the tool does. It relies on the user knowing index.build, so purpose is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this alias versus index.build or other sibling tools. No context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get scholarly metadata by DOI/arXivId/URL.
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | ||
| arxivId | No | ||
| url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the bare action. Given the openWorldHint annotation, the agent knows effects are unknown, but the description could add context such as whether this tool is read-only, whether it makes external network calls, or any rate limiting. The annotation carries the burden, but the description adds no value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core purpose efficiently. It is appropriately sized and front-loaded. While minimalist, it avoids verbosity. However, it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should at least hint at what the returned metadata contains (e.g., title, authors, publication date). It also lacks any note about error handling or required authentication. Combined with minimal parameter info, the agent is poorly equipped to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters lack descriptions in the input schema (0% coverage). The description lists the parameter names but provides no format, constraints, or examples. For instance, it does not clarify whether the URL must be a direct metadata link or if DOI requires the prefix '10.' This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves scholarly metadata using identifiers like DOI, arXivId, or URL. It distinguishes itself from sibling tools that perform calculations (calc.eval), document access (doc.read), or web fetching (web.fetch). However, it could be more specific about the metadata scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as sch.search or web.fetch. It does not mention prerequisites, typical use cases, or when not to invoke this tool. This leaves the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of sch.get
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | ||
| arxivId | No | ||
| url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotation 'openWorldHint: true'. It does not disclose any aspects such as whether the tool is read-only, destructive, or has authentication needs. The description carries the full burden but fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but this is due to under-specification rather than conciseness. It is a single sentence that provides no useful information. While not verbose, it fails to earn its place by being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three parameters, no output schema, many siblings), the description is completely inadequate. It does not explain what the tool returns, how it differs from its alias sch.get, or any behavioral details needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for three parameters (doi, arxivId, url), the description should compensate but adds nothing. It does not explain what each parameter represents or how they are used, leaving the agent without meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Alias of sch.get' does not state what the tool does; it merely indicates it is an alias, providing no verb or resource information. This is a tautology as it only references another tool name without explaining its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description gives no context on when to use this tool versus alternatives like sch.get or other siblings. There is no mention of when-not-to-use or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Academic-first search (arXiv + Crossref + Wikipedia).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| top | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation openWorldHint: true is present, and the description adds value by specifying academic sources. However, it does not disclose other behavioral traits like pagination, rate limits, or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. It efficiently conveys the key purpose and source coverage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters with no descriptions and no output schema, the description is insufficient. It should explain expected input format for q and the effect of top and limit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of any of the three parameters (q, top, limit). It fails to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it performs 'academic-first search' and lists three specific sources (arXiv, Crossref, Wikipedia), clearly differentiating it from sibling search tools like web.search and wiki.search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'academic-first' implies it should be used for academic queries rather than general web or wiki searches, but it does not explicitly state when not to use it or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of sch.search
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| top | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the annotation openWorldHint=true. It fails to disclose any traits like return format, side effects, or relationships.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While concise, the description is too vague to be useful. It sacrifices substance for brevity, failing to provide actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 3 parameters and no output schema, the description is completely inadequate. It does not help the agent invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to parameters q, top, or limit. The agent must guess their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Alias of sch.search' does not explain what the tool does; it is a tautology that relies on the agent knowing sch.search's purpose. Without that, the agent cannot understand the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like sch.search, web.search, or wiki.search. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL with size/time limits and anti-SSRF.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No | ||
| max_bytes | No | ||
| headers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by stating size/time limits and anti-SSRF protection. However, it omits details on error handling, timeouts, or what happens when limits are exceeded. Annotations provide openWorldHint, which aligns with network fetch behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the core action, no redundant words. Efficiently communicates the tool's essence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, return format, or error behavior description. For a fetch tool with 4 parameters, the description is too brief to fully inform an agent about expected behavior and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by hinting at 'size/time limits' (mapping to max_bytes and timeout) but does not mention the headers parameter. Parameter names are somewhat self-explanatory, but the description should explicitly list or explain all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses 'Fetch a URL' as a specific verb+resource and mentions size/time limits and anti-SSRF, clearly distinguishing it from sibling tools like web.read or web.search. However, it could be more explicit about what 'fetch' returns (e.g., page content).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like web.read or web.search. The description does not mention use cases, prerequisites, or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of web.fetch
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| timeout | No | ||
| max_bytes | No | ||
| headers | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed. The description does not mention read-only, destructiveness, permissions, or side effects. The annotation openWorldHint: true is present but the description adds no context beyond it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but lacks essential information. This is under-specification, not conciseness. A single sentence that merely references another tool is insufficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters including a nested object and no output schema, the description is completely inadequate. It fails to provide necessary context for the agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain any parameter (url, timeout, max_bytes, headers). The description adds no meaning beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Alias of web.fetch' is a tautology that does not state what the tool does. It relies entirely on the agent knowing 'web.fetch', which is a separate sibling tool. The name 'web_fetch' suggests fetching web content but the description adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like web.fetch or web.read. The description provides no context on the tool's role or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract readable content from given HTML (or pass html from web.fetch).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| html | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the 'openWorldHint' annotation. It does not mention side effects, but the tool likely has no destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence), but could be slightly restructured for clarity (e.g., separating the two modes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description does not specify return format or error conditions. Given the tool's simplicity, it is moderately complete but leaves gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions the 'html' parameter but does not explain the required 'url' parameter or the relationship between them. With 0% schema coverage, the description fails to clarify parameter roles, leading to confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool extracts readable content from HTML, with two modes: direct HTML or from web.fetch. It distinguishes from sibling tools like web.fetch (fetches raw HTML) and web.search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after web.fetch or with direct HTML, providing clear context. However, it does not explicitly exclude inappropriate scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of web.read
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| html | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no behavioral details beyond being an alias. The annotation 'openWorldHint' is not explained, and the tool's read-only or mutation nature is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is short, it is under-specified and fails to earn its place. A tool alias without purpose definition is not concise but rather incomplete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no parameter descriptions, and a minimal description that only points to another tool, the context is severely lacking for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool description adds no meaning to the 'url' or 'html' parameters. The agent receives no guidance on valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Alias of web.read' fails to specify what the tool actually does. It references another tool but does not explain the functionality, leaving the purpose vague and unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like web.read, web.fetch, or others. The description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multi-engine web search (SearXNG + DuckDuckGo HTML).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| max | No | ||
| lang | No | ||
| site | No | ||
| engines | No | ||
| k | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint=true, informing the agent of potential side effects. The description adds the detail that it uses two specific engines, providing some transparency but lacking info on rate limits, result format, or response behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose. It is concise but omits important details about parameters and usage, which slightly detracts from its value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (7) with no schema descriptions, no output schema, and no explanation of return values or pagination, the description is incomplete. It only covers the tool's basic function without sufficient operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 7 parameters (q, max, lang, site, engines, k, limit). With 0% schema description coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a multi-engine web search tool, naming specific engines (SearXNG and DuckDuckGo HTML), which distinguishes it from sibling tools like web.read or web.fetch. The verb 'search' and resource 'web' are explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like sch.search or wiki.search. There is no mention of when not to use or any context for choosing this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of web.search
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| max | No | ||
| lang | No | ||
| site | No | ||
| engines | No | ||
| k | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (openWorldHint), the description adds no behavioral context. It does not disclose any traits such as authentication needs, rate limits, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but under-specified. It lacks sufficient information to be useful, thus it is not concise in a meaningful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and zero schema coverage, the description is completely inadequate. It provides no context for usage, parameters, or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any parameters. It fails to add meaning beyond the input schema, leaving all parameters unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Alias of web.search', which indicates it is an alias but does not state what the tool does. It is vague and fails to specify the verb and resource clearly. The purpose is implied but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It merely states it is an alias, without any context on use cases or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wikipedia summary by title.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| lang | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint: true, indicating external access, but the description adds no behavioral context beyond the annotation. It fails to mention read-only nature, error behavior (e.g., missing title), or any constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but still conveys the core function. It front-loads the purpose, but the brevity leaves out important details, making it borderline under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and low parameter documentation, the description should provide more context. It covers basic function but lacks details on 'lang', error handling, return format, or how it differs from very similar sibling tools like wiki_get and wiki.search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description's phrase 'by title' gives some meaning to the 'title' parameter, but it ignores the 'lang' parameter entirely. This is insufficient to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wikipedia summary by title' clearly indicates the tool retrieves a summary from Wikipedia based on a title. It distinguishes from sibling tools like wiki.search which suggests search functionality, though it doesn't explicitly contrast with wiki_get which may be an alias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not specify when to use this tool over alternatives, such as wiki.search for finding articles, nor does it clarify the role of the 'lang' parameter or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of wiki.get
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| lang | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotation 'openWorldHint: true'. It does not disclose side effects, authentication needs, or other traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specification rather than conciseness. It lacks essential information, making it insufficient for effective tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema or any details about return values, the description is completely inadequate. The tool's behavior is undocumented, leaving the agent blind.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters (title and lang) have no descriptions in the schema, and the description offers no explanation of their meaning or usage. The agent cannot infer their purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Alias of wiki.get', which only indicates it is an alias without defining the tool's actual function. It does not specify what action is performed or what resource is involved, making it vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like wiki.get or wiki.search. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wikipedia title search (public API).
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| lang | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint: true, and the description adds that it's a 'public API', confirming it makes external calls. No other behaviors (rate limits, error responses) are disclosed, so the agent lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (6 words), but at the cost of omitting necessary details like parameter semantics. It is front-loaded but insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 0% schema description coverage, and no parameter explanations, the description is incomplete. The agent lacks critical context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 2 parameters with 0% description coverage, and the description does not explain 'q' (search query) or 'lang' (language). The agent must guess parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool does a 'Wikipedia title search' using a 'public API', which differentiates it from sibling tools like wiki.get (which likely retrieves a page). However, it could be more explicit about the scope (e.g., only title matches, not full text).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use search versus get, nor any mention of limitations or prerequisites. The agent must infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Alias of wiki.search
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | ||
| lang | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral information provided beyond annotations. openWorldHint indicates schema flexibility but description says nothing about effects, side effects, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but under-specified. A single phrase that lacks substance; not concise in a helpful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the minimal schema and lack of output schema, the description should compensate but fails entirely. No context about search functionality, results, or usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and description adds no meaning to parameters 'q' or 'lang'. No explanation of what they represent or their format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description says 'Alias of wiki.search', which is a tautology and provides no specific verb or resource. It doesn't clarify what the tool does beyond being an alias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the sibling wiki.search. The description does not mention any context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
calc_evalcalc.evaldoc_finddoc_readdoc.finddoc.readindex_buildindex.buildsch_getsch_searchsch.getsch.searchweb_fetchweb_readweb_searchweb.fetchweb.readweb.searchwiki_getwiki_searchwiki.getwiki.searchEach unique operation has a distinct prefix and action (e.g., calc.eval, sch.search, web.fetch). Aliases are exact duplicates and do not create functional ambiguity. An agent can easily distinguish between different domains and operations.
The original tools consistently use a domain.action pattern (e.g., calc.eval). However, the aliases switch to domain_action (e.g., calc_eval), introducing a minor inconsistency. The core pattern is clear, but the presence of both slightly reduces consistency.
22 tools nominally, but effectively 11 unique operations due to aliases. This is reasonable for a server covering multiple domains (math, docs, search, web, wiki). The alias redundancy is minor and does not overwhelm the surface.
The tool set covers key operations for each domain: calculation, document indexing/reading, scholarly and web search, Wikipedia retrieval. Missing write/update operations (e.g., doc.write, wiki.edit) but these are likely out of scope for a LM-assistance tool server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
An MCP server that gives your AI access to the source code and docs of all public github repos
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/khanhs-234/tool4lm'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
