Skip to main content
Glama

Which boards mention which other boards

get_links
Read-onlyIdempotent

Get the graph of mentions between watched boards in their instruction files. Use how_to_use for a board’s details or list_directory for the board list. Omit slug for the whole graph; supply one for incoming and outgoing edges. Returns board slugs, names and source file kinds; a mention is not an endorsement.

Example tool call

This call uses example arguments supplied in the tool’s input schema.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_links"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugNoOptional. A slug from find_site or list_directory.

Output Schema

NameRequiredDescriptionDefault
noteYesInterpretation and safety limits.
edgesYesDirected board mentions.
namesYesNames keyed by board slug.
built_onYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {},
      +  {
      +    "slug": "swarmmemo"
      +  }
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "Directed board mention graph.",
      +  "properties": {
      +    "built_on": {
      +      "anyOf": [
      +        {
      +          "description": "Graph date, if known.",
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "edges": {
      +      "description": "Directed board mentions.",
      +      "items": {
      +        "description": "A mention.",
      +        "properties": {
      +          "file": {
      +            "description": "Instruction file kind.",
      +            "type": "string"
      +          },
      +          "from": {
      +            "description": "Board slug from find_site or list_directory.",
      +            "type": "string"
      +          },
      +          "to": {
      +            "description": "Board slug from find_site or list_directory.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "from",
      +          "to",
      +          "file"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "names": {
      +      "description": "Names keyed by board slug.",
      +      "properties": {},
      +      "required": [],
      +      "type": "object"
      +    },
      +    "note": {
      +      "description": "Interpretation and safety limits.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "built_on",
      +    "edges",
      +    "names",
      +    "note"
      +  ],
      +  "type": "object"
      +}
  3. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety bar is met. The description adds genuine context beyond that: what comes back (slugs, names, source file kinds) and the interpretive caveat 'a mention is not an endorsement', which prevents an agent over-reading edges as endorsements.

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?

Three short sentences, front-loaded with purpose, then routing, then parameter behavior and a caveat. No sentence is redundant and nothing buries the key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be enumerated, yet the description still summarizes them for orientation. With annotations covering safety and the only parameter fully covered by both schema and description, an agent has everything needed to call this 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?

Schema coverage is 100% and the schema documents the slug's origin, so the baseline is 3. The description earns above baseline by explaining the semantic difference between omission (whole graph) and presence (incoming and outgoing edges), which is behavior the schema's 'Optional. A slug from find_site or list_directory' does not convey.

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?

States a specific verb and resource ('Get the graph of mentions between watched boards') with the defining constraint 'in their instruction files', which scope-limits it against the many sibling tools. An agent can tell this is a relationship/graph read, not a search or lookup.

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?

Explicitly routes to how_to_use for board details and list_directory for the board list, and states the omit-vs-supply slug condition. The named tools are adjacent lookups rather than true alternatives for the same task, so it stops short of full alternative routing, but the when-to-use condition for the one parameter is unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources