Search the devrel.directory unified index of documentation guides, blog posts, directory listings, jobs, and events (including which have an open call for papers). Returns matching results with absolute devrel.directory URLs; event results deep-link to the specific event on the events page.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The search query. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It states that results include absolute URLs and that event results deep-link to specific events, which goes beyond the schema. It implies a read-only operation by describing a search, but does not mention auth, rate limits, or failure modes, though these are less critical for a simple search.
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 two sentences long, front-loaded with the core purpose and followed by return-value details. Every clause adds information; no filler or repetition of schema fields.
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?
The tool has a single parameter and no output schema, so the description must cover both semantics and returns. It explains the search scope and the nature of results (URLs, event deep-links), making it reasonably complete for the tool's simplicity. It stops short of describing result fields or limits, but this is acceptable given the low complexity.
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 schema already defines 'query' as the search query, and the description adds that the query searches across the unified index including specific content types. This clarifies what the query targets, adding value beyond the schema's minimal description. However, it doesn't provide query syntax or filter options.
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 searches a unified index of multiple content types (docs, blog posts, directory listings, jobs, events). The verb 'Search' and specific resource make it distinct from sibling tools like search_directory, which likely focuses on directories only.
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 clear context: this is a unified search across all content categories. It implies use when you need cross-type search results, but does not explicitly state when not to use it or name alternatives. The coverage of multiple content types is a strong contextual signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct concern: aggregate stats, single listing detail, events listing, jobs listing, directory search, and cross-document search. No overlapping purposes.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., list_events, search_directory). No mixing of conventions.
6 tools is well-scoped for a directory MCP, covering stats, entity details, lists, and searches without bloat.
The tool set covers all core read operations for a directory: retrieving stats, individual listings, filtered lists of events and jobs, and two search scopes (directory only and unified). No obvious gaps given the read-only nature.