Search your saved web highlights and notes from MarklyKit, a Chrome extension for highlighting and annotating web pages. Your AI assistant can search your research, get recent highlights, get highlights for a URL, list folders and read a folder's research, each with source links. Requires MarklyKit Pro (OAuth sign-in).
Scored across 5 tools
Each tool targets a distinct retrieval axis: folder contents, per-URL highlights, recency, free-text search, and folder listing. The only mild overlap is between get_recent_research and search_research, but the descriptions make their boundaries clear.
All names are snake_case verb_noun (get_*, list_*, search_*) with predictable object suffixes. The pattern is uniform throughout the five tools.
Five tightly scoped tools, each covering a distinct retrieval need for a highlight/research memory server. Nothing feels redundant or padded.
The retrieval surface is coherent but read-only: there is no way to save a highlight or note, create/manage folders, or fetch a single item by ID. Agents can recall data but cannot write back, leaving an obvious lifecycle gap.
Retrieve highlights and notes saved inside a specific folder. Use this when the user asks about research in a named collection.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (1–30, default 20) | |
| folder_id | Yes | The folder ID (from list_folders) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only retrieval of saved highlights and notes, but it does not disclose permissions, empty-folder behavior, or other operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with the core purpose front-loaded and no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with full schema coverage and no output schema, the description sufficiently explains what is returned and when to use it. It could add a little more about edge cases or expected result shape, but the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both folder_id and limit. The description reinforces the folder scope but adds no parameter-specific meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: retrieving highlights and notes from a specific folder. It is clearly distinct from a URL-based or recent-research lookup due to the folder scope, though it does not explicitly name sibling alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage condition: use when the user asks about research in a named collection. It does not explicitly say when not to use it or name alternative tools like search_research or get_recent_research.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all saved highlights and notes from a specific web page. Use this when the user asks what they saved from a particular URL.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The page URL to fetch highlights from | |
| limit | No | Max results (1–30, default 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Retrieve' implies a safe read, but it discloses nothing about URL matching semantics (trailing slash, query params, redirects), result ordering, or behavior when the URL has no highlights — meaningful gaps for a zero-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, purpose first, usage trigger second, with no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter read tool with no output schema, the description covers what it returns at a high level and when to call it. Missing only edge-case behavior (no highlights found, URL normalization), which keeps it short of a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both the url and limit parameters are already documented in-schema. The description adds only the notion of 'a specific web page' and no extra detail on URL format or result-limit interaction, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Retrieve') and resource ('saved highlights and notes') with a clear scope ('from a specific web page'). It doesn't explicitly name a sibling to distinguish from, but none of the sibling research/folder tools overlap in domain, so confusion risk is low.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use trigger: 'when the user asks what they saved from a particular URL.' No when-not conditions or alternatives are stated, though the sibling list offers no genuine alternative for this capability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the most recently saved highlights and notes, newest first. Use this to get a summary of what the user has been reading lately.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Restrict to a specific page URL | |
| limit | No | Max results (1–20, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; it discloses the sort order and the read-only nature implied by 'retrieve', plus the data source (saved highlights/notes). It says nothing about permissions, whether lifecycle/archived items are excluded, or what the results contain beyond highlights and notes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no redundancy, and the behavioral fact (newest first) is front-loaded before the usage hint. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-required-param read tool with fully documented schema and no output schema, the description covers what it returns, ordering, and the intended intent. A brief note on how it differs from sibling retrieval tools would close the remaining gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% – both url and limit are documented with types, ranges and defaults in the schema itself. The description adds no syntax or behavioral detail (e.g., whether url requires exact match) beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Retrieve ... highlights and notes') and states ordering ('newest first'), which lets an agent predict the output shape. It does not explicitly differentiate itself from siblings like search_research or get_highlights_for_url, leaving that inference to the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one use case ('summary of what the user has been reading lately'), which implies when to reach for it. But there are no exclusions and no routing guidance versus search_research or get_highlights_for_url, so an agent must guess which tool wins for a filtered or search-style request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all the user's research folders.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden, yet it says nothing about ordering, pagination, whether nested folders or empty results are possible, or the permission scope required. 'List' implies a read-only operation, but that is an inference the agent has to make.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, front-loaded sentence with no filler or redundancy. It is efficient, though its brevity contributes to the gaps in behavior and return-value disclosure rather than being a virtue in itself.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should convey the shape of what comes back, such as what fields a folder has or whether counts are included, and it does not. For a zero-parameter read tool this is a modest but real gap, since the agent cannot anticipate the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters and the schema confirms an empty properties object, so there is nothing parameter-wise to document. The baseline of 4 applies; the description neither helps nor hurts here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs the specific verb 'List' with the resource 'the user's research folders', making the operation unambiguous. It does not distinguish itself from siblings such as search_research or get_recent_research, so an agent must infer that this is the unfiltered enumeration rather than a search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to use this tool versus get_folder_research, search_research, or get_recent_research, and no prerequisites or exclusions. The 'all' wording hints at unfiltered enumeration, but the agent must derive the routing decision from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search saved highlights and notes using hybrid semantic + full-text search. Use this when you need to recall what the user has researched about a topic.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Search query | |
| url | No | Filter results to a specific page URL | |
| tags | No | Filter results to only these tags | |
| limit | No | Max results to return (1–20, default 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden alone; it does disclose the meaningful trait that results come from a blended semantic + full-text ranking. It says nothing about pagination limits (beyond schema), ordering, or what a result record contains, and does not explicitly affirm this is a non-mutating read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, with the capability statement front-loaded ahead of the usage trigger. Nothing redundant with the title or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description could reasonably say something about result shape or ranking, but it does not. For a four-parameter search tool with no annotations, the definition covers what it does and roughly when, but leaves the return contract and filtering semantics implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters are already documented, setting the baseline at 3. The description adds no parameter guidance at all — it never mentions that url or tags act as filters or that limit caps the result count — so it does not exceed the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Search saved highlights and notes") plus the retrieval mechanism (hybrid semantic + full-text), which distinguishes it from the listing-type siblings like get_recent_research and list_folders. It does not explicitly name which sibling to use for a single-URL or folder-scoped lookup, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use this when you need to recall what the user has researched about a topic" gives a clear triggering condition. It stops short of exclusions or naming an alternative (e.g., use get_highlights_for_url when the page is known), so an agent must infer the boundary from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Highlight anything you read. Then ask your AI about it: search, read and edit your highlights.
Search, read, and write highlights, notes, screenshots, collections, projects, and tags in Gleanit.
Search and organize your reading library of highlights, saved articles, notes and tags.
Highlight anything you read. Then ask your AI about it. Highlyt puts your PDFs, EPUBs, web articles and supported Kindle highlights in one library. Students ask Claude or ChatGPT what they highlighted across their papers; researchers turn colour-coded highlights into a Markdown brief with BibTeX/RIS/CSL-JSON references; readers turn book highlights into notes. Your AI can search, read, create and link highlights. 7-day free trial (3 documents), no card needed, then Pro $4.99/mo or $39/yr.
Add one secure layer between your agents and this server.
