Skip to main content
Glama

Devdocs Io

by io.github.pipeworx-io

Search Index

search_index
Read-onlyIdempotent

Search WITHIN a documentation set for a specific entry (method/function/API/property) by substring — THIS is the content lookup. E.g. slug="javascript", query="Array.map"; slug="python", query="os.path". Get valid slugs from docs/search_docs.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
slugYesThe documentation set, e.g. "javascript", "python", "react".
limitNo
queryYesThe entry/term to find, e.g. "Array.map", "fetch".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
countYesNumber of matching entries returned
entriesYesFiltered entries matching the query

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedInput schema / properties / query / description
      Added value: +"The entry/term to find, e.g. \"Array.map\", \"fetch\"."
    • addedInput schema / properties / slug / description
      Added value: +"The documentation set, e.g. \"javascript\", \"python\", \"react\"."
  2. Changed2 schema fields changed
    • addedInput schema / examples
      Added value: +[
+  {
+    "query": "array methods",
+    "slug": "javascript"
+  },
+  {
+    "limit": 5,
+    "query": "useState",
+    "slug": "react"
+  }
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "properties": {
+    "count": {
+      "description": "Number of matching entries returned",
+      "type": "number"
+    },
+    "entries": {
+      "description": "Filtered entries matching the query",
+      "items": {
+        "properties": {
+          "name": {
+            "description": "Entry name",
+            "type": "string"
+          },
+          "path": {
+            "description": "Entry path identifier",
+            "type": "string"
+          },
+          "type": {
+            "description": "Entry type category",
+            "type": "string"
+          }
+        },
+        "required": [
+          "name",
+          "path",
+          "type"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "count",
+    "entries"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already confirm read-only/idempotent behavior; description adds that the search is by substring and returns specific entries, not full documents. It also warns that valid slugs come from docs/search_docs, adding practical behavioral context. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences plus examples convey purpose, usage, and key parameter semantics without fluff. Every clause earns its place and the structure front-loads the core verb+object.

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 annotations and output schema, the description covers purpose, key parameters, and how to obtain valid slugs. Minor gap is the undefined 'limit' parameter and lack of specifics about result limits or ordering, but overall sufficient for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes slug and query; description adds that query is a substring and shows example values for both. However, the 'limit' parameter is never mentioned in the description and has no schema description, leaving its purpose ambiguous despite the schema examples.

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 it searches within a documentation set for specific entries (methods/functions/APIs/properties) by substring, distinguishing it from general search. The phrase 'THIS is the content lookup' and the instruction to get valid slugs from docs/search_docs specifically differentiate it from sibling tools that list docs or perform broader searches.

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 context for when to use (content lookup within a known doc set) and points to docs/search_docs for valid slugs, but doesn't explicitly mention alternatives like search_within or when not to use. The examples help clarify the intended use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Devdocs Io toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.1/5.0
Disambiguation3/5

There are many tools with overlapping purposes (e.g., multiple ways to ask questions, multiple Polymarket analysis tools, multiple company lookup tools). The detailed descriptions help distinguish them, but an agent could still easily select the wrong one.

Naming Consistency2/5

Tool names are inconsistent, mixing verb_noun patterns (ask_pipeworx, search_docs) with single words (db, docs) and compound names (polymarket_arbitrage, ai_visibility_check). No clear convention across the set.

Tool Count2/5

37 tools is excessive for a DevDocs documentation server; most tools are unrelated to documentation (Pipeworx data, memory, subscriptions). The core documentation functionality only requires about 7-8 tools, making the rest feel extraneous.

Completeness3/5

For the core DevDocs functionality, the tools cover listing, searching, and fetching documentation. However, the server includes many unrelated tools that are incomplete on their own (e.g., only some data lookups, no CRUD for prediction markets). Thus overall completeness is mediocre.

Resources