# get_listing

Get the full detail for one directory listing by its slug, including longer details when present, the source repository URL and its maintenance signals where the listing has one (bucketed star count, last commit and last release month, whether GitHub reports the repository archived, and the date all of those were checked), the slugs of similar listings, curated alternatives and complements (hand-picked substitutes and stack pairings, as slug + name), and any open DevRel jobs or upcoming events cross-linked to the same company. Returns an error for an unknown slug.

Agent View of the PolicyLayer registry record for `get_listing`. HTML page: https://policylayer.com/tools/directory-devrel-devrel-directory/get-listing

## Facts

- Tool: `get_listing`
- Server: DevRel Directory (`https://devrel.directory/mcp`) — https://policylayer.com/tools/directory-devrel-devrel-directory.md
- Homepage: https://github.com/https://devrel.directory/mcp
- Risk category: Read (Low risk)
- Registry record: grade C, identity unverified
- Server auth posture: open
- Server rate-limited: no
- Parameters: 1 (1 required)
- Recommended policy verdict: Allowed

## Parameters

| Parameter | Type | Required | Description |
| --- | --- | --- | --- |
| `slug` | string | yes | The listing slug, as returned by search_directory (e.g. 'answer-overflow'). |

Parameters from the server's own tool schema.

## Example call (MCP tools/call, JSON-RPC 2.0)

```json
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "get_listing",
    "arguments": {
      "slug": "<slug>"
    }
  }
}
```

## Why get_listing is rated Low

Even though get_listing only reads data, uncontrolled read access leaks sensitive information and racks up API costs: an agent caught in a retry loop can make thousands of calls a minute without anyone noticing.

## Use case

AI agents call get_listing to retrieve information from DevRel Directory without modifying anything. It is typically the context-gathering step in research, monitoring, and reporting workflows, before the agent takes action elsewhere.

## Recommended policy (PolicyLayer)

Verdict: **Allowed**. Enforced by the PolicyLayer MCP gateway (https://policylayer.com/mcp-gateway) before a call reaches DevRel Directory:

```json
{
  "version": "1",
  "default": "deny",
  "tools": {
    "get_listing": {}
  }
}
```

## Other tools on DevRel Directory (5)

- `directory_stats` — Read — https://policylayer.com/tools/directory-devrel-devrel-directory/directory-stats.md
- `list_events` — Read — https://policylayer.com/tools/directory-devrel-devrel-directory/list-events.md
- `list_jobs` — Read — https://policylayer.com/tools/directory-devrel-devrel-directory/list-jobs.md
- `search_directory` — Read — https://policylayer.com/tools/directory-devrel-devrel-directory/search-directory.md
- `search_docs` — Read — https://policylayer.com/tools/directory-devrel-devrel-directory/search-docs.md

## For agents

This record is a snapshot. Live verdicts and the full registry:

- Check every server in your MCP config at once: `npx -y policylayer stack`
- Vet a server before you add it: install the mcp-precheck skill — `npx skills add https://policylayer.com` (skill text: https://policylayer.com/skill.md)
- Query the registry over MCP: endpoint `https://api.policylayer.com/mcp` — tools `check_mcp_server`, `check_mcp_stack`, `check_tool`, `search_registry`, `get_change_events`

---

Source: the PolicyLayer MCP registry — one continuously verified record per MCP server. Full record: https://policylayer.com/registry?q=directory-devrel-devrel-directory · API: https://policylayer.com/registry/api · Policy library: https://policylayer.com/policies/directory-devrel-devrel-directory