Skip to main content
Glama

Source Library

by io.github.Embassy-of-the-Free-Mind

Share Findings

share_findings

Share a research dossier back to the Source Library team — a title, an optional summary, and an ordered list of citations (the passages your thesis rests on). Each citation is a reference { book_id, page, note }, NOT copied text: the library re-renders the canonical quote from the reference, so links stay authoritative. Use this when the user has assembled a thesis backed by passages across one or more books and wants to contribute it back. Like submit_feedback, this goes to the team for review (not an instant public page).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
emailNo
titleYesTitle of the dossier / thesis (2-300 chars)
summaryNoOptional prose summarizing the argument (max 5000 chars)
citationsYesOrdered list of supporting passages (1-50). Get book_id + page from get_quote / search_translations.

TDQS

A4.6/5.0
Behavior5/5

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

The description reveals key behavioral details beyond the annotations: citations are references, not copied text, and the library re-renders canonical quotes to maintain authority. It also discloses that the submission goes to the team for review, which is important for setting expectations. No contradiction with annotations.

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?

The description is three sentences long but information-dense, with every sentence contributing to understanding the tool's purpose, citation semantics, and review process. It is front-loaded with the main action, making it easy to scan.

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?

Given the tool's moderate complexity and lack of an output schema, the description covers the essential behavior, key content structure, and the review outcome. However, it does not mention the optional name/email fields, which may be relevant for user identity, and leaves some ambiguity about what happens after submission beyond the review step.

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 description coverage is 60% (3 of 5 params described). The description adds valuable context for the citations parameter (structure, reference-based, ordered list) and mentions the source for book_id/page, but it does not address the name and email parameters, which lack schema descriptions and are absent from the tool description.

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?

The description clearly states the tool shares a research dossier to the Source Library team, specifying the main components (title, optional summary, citations). It distinguishes the tool from sibling submit_feedback by describing it as a dossier-sharing action, not general feedback.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use this when' clause defines the exact scenario: when the user has assembled a thesis backed by passages across one or more books and wants to contribute it back. It also references submit_feedback as a similar mechanism and notes that submissions go to team review, not instant public pages.

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

All Source Library toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.5/5.0
Disambiguation4/5

Tools are organized around distinct actions—discover, read, cite, search, contribute—and the descriptions cross-reference each other heavily. The only mild ambiguities are the get_quote/get_quotes pair and the multiple passage-search variants, which overlap in result type but are scoped differently.

Naming Consistency5/5

All tools use snake_case verb_noun names with predictable prefixes: get_* for retrieval, list_* for catalog enumeration, search_* for discovery, and plain verb_noun for contribution actions. Pluralization and compound nouns like get_book_text are minor variations that do not break the pattern.

Tool Count5/5

Fifteen tools is at the upper end of the ideal range, but every tool maps to a distinct step in the library workflow: discovery, reading, citation, search, editions, images, and community contributions. None feels redundant or decorative.

Completeness5/5

The surface covers the full research lifecycle: discovering books, reading them, locating canonical references, citing exact pages, searching by keyword/meaning/within a book, comparing editions, finding images, and contributing findings back. The pipeline from get_book to get_book_text to get_quote provides clear forward paths with no dead ends.

Resources