Skip to main content
Glama

open_notebook_source_get

Read-only

Retrieve a single source's title, topics, extracted text (up to max_chars), and the notebooks it belongs to for source-cited research.

Instructions

Read one source: its title, topics, extracted text (cut at max_chars, up to 50000) and the notebooks it belongs to.

Input Schema

NameRequiredDescriptionDefault
max_charsNo
source_idYes

Output Schema

NameRequiredDescriptionDefault
idYes
titleNo
statusNo
topicsNo
createdNo
updatedNo
embeddedNo
full_textNo
notebooksNo
truncatedNo
content_charsNo
embedded_chunksNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds genuinely new behavior by disclosing that extracted text is truncated at max_chars with a hard ceiling of 50000. It does not say what happens if the source is missing or whether truncation is signaled.

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?

A single well-formed sentence with the return contents front-loaded and zero filler; the truncation detail is attached directly to the field it governs.

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?

An output schema exists, so the description needn't restate return shape, and it still previews the key returned fields plus truncation semantics. Minor gap: no mention of not-found behavior for a closed-world lookup.

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 0%, so the description must carry parameter meaning: it explains max_chars well (text is cut at that length, capped at 50000) but leaves source_id — the required parameter — entirely uncharacterized beyond its name.

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 specific verb+resource ('Read one source') and enumerates what comes back: title, topics, extracted text, and parent notebooks. It is clearly a single-item read, distinct from the sibling open_notebook_search or open_notebook_note_get, though it never names those alternatives.

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 by 'Read one source' — an agent can infer this is the lookup-by-id path versus search, but no explicit when/when-not guidance or prerequisite (e.g. source must exist, id obtained from search) is given.

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