Skip to main content
Glama
Sign In
secondbrain-mcp

secondbrain-mcp

by jesusr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Pages by tag

pages_by_tag
Read-only

Find pages by tag, including sub-tags such as project/website, and optionally include SilverBullet system pages. Accepts tag names with or without # for tagged content retrieval.

Instructions

Find pages tagged with a given tag (with or without #). Matches sub-tags too, e.g. 'project' matches 'project/website'.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "tag": "<tag>"
    },
    "name": "pages_by_tag"
  }
}

Input Schema

NameRequiredDescriptionDefault
tagYes
include_systemNoInclude SilverBullet system pages (Library/, Repositories/, SETTINGS, CONFIG)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

readOnlyHint=true already tells the agent this is a safe read. Beyond that, the description discloses non-obvious matching semantics — prefix/sub-tag matching ('project' matches 'project/website') — which materially affects how results should be interpreted. It omits result ordering/truncation details, but the core behavioral trait is surfaced.

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 short sentences, zero filler, with the core purpose stated first and the non-obvious matching rule immediately after. Every clause carries information the agent needs.

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 simple read-only lookup with annotations covering safety and only two parameters, this is nearly sufficient. The remaining gap is what the results actually contain (page names vs. paths, order, limits) — a minor omission given no output schema exists to cover it.

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 coverage is 50%: include_system is documented in the schema, but the required 'tag' parameter has no schema description. The description compensates by explaining the '#' optionality and the sub-tag matching behavior for that parameter, which is real added meaning, though it doesn't clarify whether matching is case-sensitive or exact-prefix only.

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+resource ('Find pages tagged with a given tag'), which is clearly distinct from list_tags (enumerating tags) and search (full-text). It doesn't explicitly name which sibling to prefer for adjacent tasks, but the resource is specific enough to differentiate.

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 implied by the tag-lookup framing and the '(with or without #)' note gives a practical input hint, but there is no explicit when-to-use versus search/list_pages, and no exclusion guidance (e.g., when a tag query is better served by search).

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