search-docs

by otolab

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.9.4
Disambiguation4/5
Tools are mostly distinct, but get_system_status and index_status overlap by both reporting index information, and get_system_status also overlaps with list_related_projects. Descriptions help clarify the level of detail, so most tools are clearly separable.
Naming Consistency3/5
Naming follows a loose pattern with get_ prefix for retrieval and list_/add_ for project management, but init and search are bare verbs, and names like index_status and maintenance_repair deviate from the dominant convention. The style is mixed but still readable.
Tool Count5/5
Nine tools cover setup, search, retrieval, status, project management, and repair without being excessive. The count is well-scoped for a document search server.
Completeness2/5
The set lacks a tool to trigger indexing or re-indexing, yet the maintenance_repair tool explicitly states a rebuild is required after repair, creating a dead end. There is also no remove_related_project or document management tool, leaving significant lifecycle gaps.
Average 3.8/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on May 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only lists return values (document count, section count, dirty count, worker status) and does not mention side effects, read-only guarantees, permissions, or any operational considerations. The verb '確認' hints at a possibly safe read operation, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence: it states the purpose first, then lists the returned information. It is not repetitive and contains no filler, earning the maximum score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status tool with one optional parameter and no output schema, the description adequately covers the purpose and the returned fields. It does not explicitly state that it is read-only or describe edge cases, but these are less critical here. The completeness is good but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter descriptions (the 'project' parameter has a clear description). The tool description itself adds no additional parameter semantics, so the baseline of 3 applies.
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 uses a specific verb ('確認します') and resource ('インデックスの詳細な状態'), making it clear this checks index status. It mentions distinct return values (document count, section count, dirty count, worker status), but does not explicitly contrast with sibling tools like get_system_status, so it falls short of a 5.
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 usage: you call this when you need detailed index status. However, it provides no explicit guidance about when to use this versus get_system_status or other siblings, and offers no exclusions or 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 carries the full burden of behavioral disclosure. It discloses that results are returned in relevance order, which is a useful behavioral detail, but it does not mention any side effects, permissions, rate limits, or other operational characteristics. The bare description is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the primary action ('Vector search documents') and states the output format. Every word earns its place, and there is no redundant or filler content.
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?
While the schema richly describes parameters, there is no output schema, and the description only states that 'related sections are returned in order of relevance.' It lacks details about the structure of returned sections (e.g., whether they include paths, text, scores) or any additional behavioral context. For a tool with several parameters and no output schema, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with all 8 parameters documented in the input schema. The description adds no additional parameter information, but since the schema fully covers semantics, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool performs vector search on documents and returns relevant sections in order of relevance. The verb 'search' and resource 'documents' are specific, and it distinguishes itself from siblings like get_document and get_outline by focusing on search rather than retrieval of a single document or outline.
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 usage for searching documents but does not explicitly state when to use this tool versus alternatives. No when-not-to-use or alternative tool references are provided. The context is clear enough for a simple search tool, but exclusions or comparisons with siblings are missing.
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 the full burden. It discloses the information categories returned, which adds some transparency, but it does not explicitly state that this is a read-only operation, mention any permissions or rate limits, or describe how data is aggregated. The tool name and nature imply safety, but the description alone lacks explicit behavioral guarantees.
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 front-loaded with the action and resource, followed by the key output categories. Every word earns its place, with no unnecessary filler 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?
For a zero-parameter status tool with no output schema, the description provides sufficient context by listing the main returned components. It could be improved by explicitly noting this aggregates information available via siblings like index_status and list_related_projects, but it does not require further detail for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is vacuously 100%. The description does not need to explain parameter semantics, and it correctly focuses on the output categories. Baseline for 0 params is 4, which fits.
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 checks the overall state of search-docs and specifies the returned categories (configuration status, index info, related projects). This is a specific verb+resource description, but it does not explicitly differentiate from sibling tools like index_status or list_related_projects, though the broader scope is implied.
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 this tool versus more specific alternatives such as index_status or list_related_projects. The description only lists what it returns, leaving usage context entirely implicit without exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the temporary, session-only nature of the addition, which is a key behavioral trait. However, it does not mention success/failure behavior, side effects, or error conditions, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and a clear instruction. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description covers purpose, temporary validity, and required input format. Yet it omits return behavior and potential errors, which is moderate for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters with descriptions, and the description adds context by clarifying that the URL should be for the started search-docs server. This reinforces the URL parameter's meaning but adds limited extra detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it temporarily adds a related project, valid only during the session, and instructs to specify the target project's started search-docs server URL. This distinguishes it from sibling list_related_projects and other tools with the explicit 'add' verb.
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 usage by instructing the user to provide the URL of a running search-docs server, but it does not explicitly state when to choose this tool over alternatives like list_related_projects. The session-only scope and need for a started server are mentioned, but no explicit comparison is given.
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 must carry the full behavioral burden. It states the tool initializes a configuration file, but omits critical side effects such as whether it creates/overwrites files, requires permissions, or affects existing configurations. The force parameter's overwrite behavior is only documented in the schema, not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and followed by a clear use case. It contains zero wasteful words and is well-structured for quick parsing.
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?
This is a simple tool with 2 optional parameters fully described in the schema. The description covers purpose and usage context sufficiently for an init operation, but lacks behavioral details (e.g., what happens to existing config, server implications) that would make it fully self-contained. Given the schema richness, a score of 3 reflects 'minimum viable but with clear gaps'.
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% (both port and force have descriptions), so the tool description adds no additional parameter semantics. Per the rubric, the baseline score is 3 when schema fully covers parameters, and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb '初期化します' (initializes) with a concrete resource ('search-docsの設定ファイル' – search-docs configuration file), clearly stating its function. It also distinguishes from siblings like search and get_document by indicating it is a setup action for local project document search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'ローカルプロジェクトの文書を検索対象にする場合に実行してください' (run when you want to include local project documents as search targets). This provides clear contextual guidance, even though it does not name alternatives explicitly.
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 the full burden. It discloses the two retrieval behaviors (section vs whole document) but does not mention any permissions, side effects, or output format. The read-only nature is implied by 'get' but not explicitly stated.
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 short sentences with no fluff. It front-loads the core purpose and then provides parameter guidance efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description adequately covers the main usage and parameter roles. It lacks details on edge cases (e.g., both path and sectionId provided) and return format, but those are not critical for a basic getter 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 description coverage is 100%, so the schema already documents all three parameters. The description adds a small amount of semantic clarity by explaining what each parameter returns (section full text vs whole document), but this is largely redundant with schema property 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?
Description clearly states the tool retrieves document content (文書の内容を取得します) and specifies two modes: section full text via sectionId, whole document via path. This distinguishes it from siblings like search and get_outline.
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?
Provides clear guidance on when to use sectionId versus path, which is practical parameter selection. However, it does not explicitly discuss tool-level alternatives or when not to use this tool, though the name and context make its purpose obvious.
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 the full burden of behavioral disclosure. It describes the core functionality (returning outline with token counts) but does not go into return format, pagination, error behavior, or side effects. This is minimal but sufficient for a read-only-style tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and contains no filler. Every sentence earns its place: the first states the action, the second gives typical use cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple tool with 3 optional parameters and no output schema, the description gives a clear high-level picture. However, it does not describe the returned structure in any detail or mention the behavior when no parameters are provided. Since schema covers parameters, this is adequate but leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description does not add parameter-level details beyond the schema; for example, it does not explain the interaction between path and sectionId, but the schema already states that path is required if sectionId is not given. Thus no extra value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: '文書の目次構造をトークン数付きで一覧表示します' (lists the document's outline structure with token counts). It uses a specific verb and resource, and it is distinct from siblings like get_document and search, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use cases: '文書の全体像把握や記述量バランスの確認に使えます' (can be used for grasping the overall picture and checking the balance of writing amount). It does not explicitly mention when not to use or list alternatives, but the context is clear enough for an agent to select it appropriately.
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 the full burden. It discloses that the list includes both config-defined and add_related_project-added projects, which is useful behavioral context. However, it does not explicitly state that this is a read-only operation or mention any side effects, errors, or return format. For a simple list tool, 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 a single concise sentence that immediately states the action and includes the key detail about the two sources. It is front-loaded with the verb and resource, and every word adds value. No redundancy or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description provides sufficient context: it names the tool's output (list of related projects) and the two categories it covers. It omits details like return format or prerequisites, but these are not critical for a simple read operation. The description is complete enough for an agent to select and invoke 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?
The input schema has zero parameters, so there are no parameter semantics to explain. Baseline 4 is appropriate since the description does not need to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving a list of related projects. It specifies the two sources (configuration file and add_related_project), which distinguishes it from the sibling tool add_related_project that writes rather than reads. The verb '取得' (retrieve) and resource '関連プロジェクト' (related projects) are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to view all related projects) but does not explicitly state usage scenarios or alternatives. There is no exclusion like 'use add_related_project to add, not list,' though this is inferable from the sibling tool names. Guidance is present but implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It explicitly reveals the destructive nature of the repair (corrupted tables are dropped and recreated) and the need for subsequent re-indexing. However, it omits details such as whether data is preserved or if user confirmation is required, but the drop/recreate statement is a strong disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, each adding essential information: the core action, the specific repair method (drop/recreate), and a required follow-up (index rebuild). There is no redundancy or filler, and the most important verb appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the essential context: what it does, how it does it, and what to do after. It could be more explicit about preconditions (e.g., 'use when corruption is suspected') but the stated behavior makes this clear enough. The mention of re-indexing connects to sibling tools like index_status implicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no information. Per the rubric, a baseline of 4 applies when there are no parameters, and the description does not need to elaborate further. The absence of parameters is consistent with a simple trigger-style maintenance tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: detecting corruption in LanceDB tables and automatically repairing them. It specifies the resource (LanceDB tables) and the verbs (detect, repair), and the mention of 'drop→再作成' makes the operation distinct from sibling tools like search or index_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when corruption is detected, and it provides a clear post-condition by stating that re-indexing is required after repair. It does not explicitly name alternatives or exclusions, but the context is unambiguous enough for a maintenance tool.
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:

[![search-docs MCP server](https://glama.ai/mcp/servers/otolab/search-docs/badges/card.svg)](https://glama.ai/mcp/servers/otolab/search-docs)

Score Badge

Copy to your README.md:

[![search-docs MCP server](https://glama.ai/mcp/servers/otolab/search-docs/badges/score.svg)](https://glama.ai/mcp/servers/otolab/search-docs)

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/otolab/search-docs'

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