Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

developer_sources

Discover indexed developer sources. Returns the registered developer source catalog and each source's exact supported operations, filters, artifact types, and index state.

Instructions

Discover indexed developer sources. Returns the registered developer source catalog and each source's exact supported operations, filters, artifact types, and index state. The current catalog contains only go:docs, a selected set of 18 parser-verified Go documentation/specification pages. A source is not_indexed until a complete generation is promoted. The catalog does not accept a cursor; limit may be 1–100.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum sources to return (1–100; defaults to 100)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.12

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations the description carries the full burden and does well: it discloses the catalog contents (only go:docs, 18 parser-verified pages), the meaning of the not_indexed state, that promotion requires a complete generation, and that no cursor is accepted. That's substantive behavioral context beyond the schema, though it doesn't explicitly frame the operation as read-only.

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

Conciseness4/5

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

Four front-loaded sentences with no filler; the return shape, catalog scope, and state semantics are all stated compactly. Slightly verbose but every sentence contributes useful information.

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 single-parameter, no-output-schema tool, the description compensates by describing the return contents and index-state semantics in prose. It's nearly complete, though it lacks any routing tie-in to the sibling discovery/search tools an agent would pair it with.

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% on the single limit parameter, so the schema already documents the 1–100 range and default. The description's restatement of the limit range and the 'no cursor' note adds only marginal value over the structured field.

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?

States a concrete verb (Discover) and resource (indexed developer sources) and details exactly what the response contains: registered catalog plus per-source operations, filters, artifact types, and index state. However, it never distinguishes itself from near-siblings like developer_search or research_sources, so an agent can't fully route on the description alone.

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?

Usage is only implied: the notion of a catalog and index state suggests this is a discovery/bootstrap step, but the description never says when to call it versus developer_search, nor any prerequisite ordering. The go:docs-only note gives domain context but no explicit when/when-not guidance.

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

Deploy Server

Other Tools