Every match, not the top 10. Searches your documents and returns each relevant one, with quotes.
Scored across 4 tools
Each tool has a clearly distinct role: ask_documents returns a cited answer, search_documents returns every match, browse_documents lists by date without a query, and read_document fetches one full document. The ask/search boundary is explicitly addressed in the descriptions, reducing misselection risk.
All names follow a consistent verb_noun pattern: ask_documents, browse_documents, read_document, search_documents. The only minor deviation is singular 'document' in read_document versus plural elsewhere, but the pattern remains predictable.
Four tools is well-scoped for a document knowledge base: search, browse, read, and ask cover the core retrieval workflows without redundancy. Each tool earns its place and there is no obvious bloat.
The read-only retrieval surface is well covered: listing, searching, reading, and answering from documents. Minor gaps exist around lifecycle operations like adding or deleting documents, but those may be out of scope for this server.
Answer a question from your own documents (your knowledge base), citing its sources. Reads every matching document across all dates unless from/to narrow it. Returns a short written answer that cites its sources as [1], [2], and the evidence: each cited quote with its document id, metadata and score. Use search_documents instead when you want every match rather than an answer. Takes the same from, to, metadata, dry_run and read_limit_usd as search_documents; the limit includes the answer fee, and mode (fast reads only the best-matching results; complete reads every match; by default the question decides). coverage says how the answer read and how many documents.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only documents whose timestamp is before this: an ISO 8601 date-time, or a YYYY-MM-DD date (through its end, UTC). | |
| from | No | Only documents whose timestamp is at or after this: an ISO 8601 date-time, or a YYYY-MM-DD date (from its start, UTC). | |
| mode | No | fast = read only the best-matching results (a lookup: quicker and cheaper, may miss matches). complete = read every matching document, up to read_limit_usd (lists, counts, "every" questions). Default: chosen from the question. | |
| query | Yes | The question, in plain language. | |
| dry_run | No | true = return how many documents match and how many tokens this call would scan, and its price, without searching. Free; reads no text. | |
| metadata | No | Exact metadata matches, e.g. {"client": "acme"}. A list matches any of its values. | |
| read_limit_usd | No | The most this one call may spend from your balance, in US dollars. Over it, the best-matching documents are read first. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive, closed-world behavior, and the description adds materially: the return shape (short answer with [1], [2] citations plus each cited quote with document id, metadata and score), the cost model (read_limit_usd includes the answer fee, best matches read first), and what coverage reports. It stops short of stating failure modes or what dry_run returns beyond the schema, so not a full 5.
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?
Front-loaded with the core purpose and the sibling routing, and nearly every clause carries information (return shape, cost, mode, coverage). The final parenthetical about mode and the trailing clause about coverage are dense and slightly run-on, costing a point.
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?
With seven parameters, nested metadata, and no output schema, the description does the heavy lifting well: it describes the returned answer, the evidence array, cost accounting, and the coverage field. Minor gaps remain around error/empty-result behavior and exactly what coverage's values look like.
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 the baseline is 3; the description still adds value by declaring that from, to, metadata, dry_run and read_limit_usd are shared with search_documents and that the USD limit also covers the answer fee. The mode explanation largely restates the enum documentation, which caps this at 4.
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 ('answer a question from your own documents'), plus the distinguishing output (a cited written answer with evidence). It explicitly separates itself from search_documents, so an agent can pick between them without opening either schema.
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?
Names the alternative and the exact condition that selects it: 'Use search_documents instead when you want every match rather than an answer.' It also gives when-to-choose guidance for mode (fast = lookup, complete = lists/counts/'every' questions) and notes that from/to narrow an otherwise all-dates read.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List your own documents (your knowledge base) by date, newest first unless order=asc. No query needed. Each result has its document id, connection id, title, date, metadata and the start of its text. Narrow with from/to (the document's timestamp) and metadata (exact match; a list = any of). Returns results, total_results and next_cursor: pass it back as cursor for the next page. Free: browsing never spends your balance.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only documents whose timestamp is before this: an ISO 8601 date-time, or a YYYY-MM-DD date (through its end, UTC). | |
| from | No | Only documents whose timestamp is at or after this: an ISO 8601 date-time, or a YYYY-MM-DD date (from its start, UTC). | |
| limit | No | Results per page, default 50, up to 100. | |
| order | No | desc (default) = newest first; asc = oldest first. | |
| cursor | No | next_cursor from the previous page of this same call, to get the next page. | |
| metadata | No | Exact metadata matches, e.g. {"client": "acme"}. A list matches any of its values. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive=false and closed-world, so the safety profile is covered; the description adds the pieces that aren't in annotations: default result shape (id, connection id, title, date, metadata, text prefix), pagination contract (results, total_results, next_cursor), and the zero-cost guarantee. Missing only edge behavior such as what happens when no documents exist.
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?
Front-loaded with the core action and default sort, then ordering, filters, result shape, pagination and cost in that sequence. Every sentence carries a distinct fact; none restates the name or title.
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 6-parameter, no-required-args, nested-metadata list tool with no output schema, the description covers ordering, timestamp filtering, metadata matching semantics, result fields, pagination and cost. An agent has everything needed to call it and to handle the response without guessing.
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%, which sets the baseline at 3, but the description earns extra credit by tying the parameters together operationally: from/to filter on 'the document's timestamp', metadata is exact-match with list=any-of, and next_cursor must be fed back as cursor. It reinforces rather than repeats, and adds the cursor round-trip that a per-parameter schema cannot express.
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 ('List your own documents ... by date') with the default ordering baked into the first clause. The 'No query needed' + 'Free' framing implicitly separates it from search_documents, but no sibling is named, so the differentiation is inferred 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?
Gives a clear selecting condition ('No query needed') and a cost-based reason to prefer it ('browsing never spends your balance'), which lets an agent route here when it has no query and wants to avoid spend. It stops short of explicitly naming search_documents or ask_documents as the alternative for query-driven retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one whole document from your own documents (your knowledge base), by the document_id and connection_id of a search or browse result. Returns its full text, title, date and metadata. A long document comes in parts: when the result has next_content_offset, call again with content_offset set to it. Free: reading never spends your balance.
| Name | Required | Description | Default |
|---|---|---|---|
| document_id | Yes | document_id from a search or browse result (your own id from ingest). | |
| connection_id | Yes | connection_id from the same result. | |
| content_offset | No | Only for a long document: next_content_offset from the previous part. Omit to read from the start. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real value beyond them: what gets returned (full text, title, date, metadata), the paginated read pattern, and the cost fact that reading never spends the balance.
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?
Three compact sentences, front-loaded with what the tool does, followed by the pagination mechanic and the cost note. No filler or restatement of the title.
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, yet the description enumerates the returned fields and explains how to page through a long document, which is exactly what an agent needs to call and drive this tool correctly.
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 three parameters are already documented in the schema, including content_offset's 'next_content_offset from the previous part'. The description restates the pagination loop rather than adding new format or constraint detail, 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?
Specific verb (Read) plus resource (one whole document from your own knowledge base) and the exact identifiers required. It implicitly separates itself from search_documents/browse_documents by naming them as the source of the ids, and from ask_documents by returning raw full text rather than an answer.
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 states the precondition (ids come from a search or browse result) and gives clear guidance for the long-document case, including the follow-up call with content_offset. It does not explicitly say when to prefer ask_documents over reading raw text, so an exclusion is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search your own documents (your knowledge base) and get every match, not just the top few: a quote from each matching document, with its document id, connection id and date. Returns results, total_results (across all pages), tokens_scanned and next_cursor: pass it back as cursor, with the same query, for the next page. Next pages are free. Narrow with from/to (the document's timestamp) and metadata (exact match; a list = any of). dry_run=true returns documents_matched, tokens_to_scan and the price without searching, for free. read_limit_usd caps what one call may spend: over it, the best-matching documents are read first, and coverage says how many were read of all that match. When coverage.complete is false, pass continue_cursor back to read the next ones. A lookup (one fact or answer) reads only the best-matching results, quicker and cheaper; coverage.mode says fast. Set mode=complete to read every match, or mode=fast for a lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Only documents whose timestamp is before this: an ISO 8601 date-time, or a YYYY-MM-DD date (through its end, UTC). | |
| from | No | Only documents whose timestamp is at or after this: an ISO 8601 date-time, or a YYYY-MM-DD date (from its start, UTC). | |
| mode | No | fast = read only the best-matching results (a lookup: quicker and cheaper, may miss matches). complete = read every matching document, up to read_limit_usd (lists, counts, "every" questions). Default: chosen from the question. | |
| limit | No | Results per page, default 50, up to 100. | |
| query | Yes | What to find, in plain language. | |
| cursor | No | next_cursor from the previous page of this same call, to get the next page. | |
| dry_run | No | true = return how many documents match and how many tokens this call would scan, and its price, without searching. Free; reads no text. | |
| metadata | No | Exact metadata matches, e.g. {"client": "acme"}. A list matches any of its values. | |
| read_limit_usd | No | The most this one call may spend from your balance, in US dollars. Over it, the best-matching documents are read first. | |
| continue_cursor | No | From a response whose coverage is not complete: reads the next best-matching documents, up to read_limit_usd again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly, non-destructive), and the description adds substantial behavioral context beyond them: next pages are free, dry_run reads no text, read_limit_usd triggers priority reading with coverage reporting, and coverage.complete=false requires continue_cursor. This billing and pagination disclosure is exactly the context an agent needs.
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?
Front-loaded with the core purpose and return shape, then layers on pagination, cost, and mode details in a logical order. It is dense and slightly sprawling, with the mode fast/complete idea revisited at several points, but most sentences carry distinct, useful information.
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 10-parameter tool with no output schema, the description covers the important return fields (results, total_results, tokens_scanned, next_cursor, coverage) and cost mechanics thoroughly. It stops short of stating what falls outside its knowledge-base scope or how it relates to sibling tools, but is otherwise nearly complete.
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 baseline is 3, but the description adds interaction semantics the schema cannot express, such as how read_limit_usd and coverage jointly determine continued reads and how cursor must be paired with the same query. This meaningfully extends parameter understanding beyond the structured descriptions.
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 your own documents (your knowledge base)') and explicitly distinguishes its scope from a top-few/ranking tool by promising 'every match, not just the top few.' An agent can tell what it returns (quote + document id, connection id, date) without opening the schema.
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?
Provides clear in-tool guidance: dry_run for cost-free estimation, read_limit_usd to cap spend, continue_cursor when coverage is incomplete, and mode=fast for a quick lookup vs mode=complete for every match. It does not explicitly name when to prefer a sibling like ask_documents or browse_documents, leaving cross-tool routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ask_documents2 fields changedInput schema / properties / from / anyOfPrevious value: -[
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- }
-]New value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ }
+]Input schema / properties / to / anyOfPrevious value: -[
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- }
-]New value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ }
+]browse_documents2 fields changedInput schema / properties / from / anyOfPrevious value: -[
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- }
-]New value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ }
+]Input schema / properties / to / anyOfPrevious value: -[
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- }
-]New value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ }
+]search_documents2 fields changedInput schema / properties / from / anyOfPrevious value: -[
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- }
-]New value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ }
+]Input schema / properties / to / anyOfPrevious value: -[
- {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- }
-]New value: +[
+ {
+ "format": "date-time",
+ "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
+ "type": "string"
+ },
+ {
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+ }
+]ask_documents1 field changedInput schema / properties / modeAdded value: +{
+ "description": "fast = read only the best-matching results (a lookup: quicker and cheaper, may miss matches). complete = read every matching document, up to read_limit_usd (lists, counts, \"every\" questions). Default: chosen from the question.",
+ "enum": [
+ "fast",
+ "complete"
+ ],
+ "type": "string"
+}search_documents1 field changedInput schema / properties / modeAdded value: +{
+ "description": "fast = read only the best-matching results (a lookup: quicker and cheaper, may miss matches). complete = read every matching document, up to read_limit_usd (lists, counts, \"every\" questions). Default: chosen from the question.",
+ "enum": [
+ "fast",
+ "complete"
+ ],
+ "type": "string"
+}ask_documents4 fields changedInput schema / properties / dry_run / descriptionPrevious value: -"true = return how many documents match and the tokens and price this query would scan. Free; reads no text."New value: +"true = return how many documents match and how many tokens this call would scan, and its price, without searching. Free; reads no text."Input schema / properties / read_limit_usd / descriptionPrevious value: -"The most this call may cost, in US dollars. Default 1. Over it, the best-matching documents are read first."New value: +"The most this one call may spend from your balance, in US dollars. Over it, the best-matching documents are read first."Input schema / properties / sinceRemoved value: -{
- "anyOf": [
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Optional, older form of from. YYYY-MM-DD: only read documents dated on or after this day."
-}Input schema / properties / untilRemoved value: -{
- "anyOf": [
- {
- "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
- "type": "string"
- },
- {
- "type": "null"
- }
- ],
- "description": "Optional, older form of to. YYYY-MM-DD: only read documents dated on or before this day."
-}browse_documentsread_documentsearch_documents20 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / connection_idRemoved value: -{
- "description": "Required for read; use the source's exact connection.",
- "maxLength": 128,
- "type": "string"
-}Input schema / properties / content_offsetRemoved value: -{
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / cursor / descriptionAdded value: +"next_cursor from the previous page of this same call, to get the next page."Input schema / properties / cursor / minLengthAdded value: +1Input schema / properties / document_idRemoved value: -{
- "description": "Required for read.",
- "maxLength": 2048,
- "type": "string"
-}Input schema / properties / dry_run / descriptionPrevious value: -"true = return how many documents match and the tokens and price this query would scan. Free; reads no text."New value: +"true = return how many documents match and how many tokens this call would scan, and its price, without searching. Free; reads no text."Input schema / properties / operationRemoved value: -{
- "default": "search",
- "enum": [
- "search",
- "browse",
- "read"
- ],
- "type": "string"
-}Input schema / properties / orderRemoved value: -{
- "enum": [
- "asc",
- "desc"
- ],
- "type": "string"
-}Input schema / properties / page_offsetRemoved value: -{
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / participantRemoved value: -{
- "maxLength": 320,
- "type": "string"
-}Input schema / properties / query / descriptionPrevious value: -"Required for search."New value: +"What to find, in plain language."Input schema / properties / read_limit_usd / descriptionPrevious value: -"The most this call may cost, in US dollars. Default 1. Over it, the best-matching documents are read first."New value: +"The most this one call may spend from your balance, in US dollars. Over it, the best-matching documents are read first."Input schema / properties / scan_afterRemoved value: -{
- "additionalProperties": false,
- "properties": {
- "at": {
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
- },
- "id": {
- "maxLength": 2048,
- "minLength": 1,
- "type": "string"
- }
- },
- "required": [
- "at",
- "id"
- ],
- "type": "object"
-}Input schema / properties / sinceRemoved value: -{
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
-}Input schema / properties / source_versionRemoved value: -{
- "maxLength": 128,
- "type": "string"
-}Input schema / properties / sourcesRemoved value: -{
- "anyOf": [
- {
- "items": {
- "maxLength": 128,
- "minLength": 1,
- "type": "string"
- },
- "maxItems": 20,
- "type": "array"
- },
- {
- "type": "null"
- }
- ],
- "description": "Optional sources for this subquery, within the user's task boundaries."
-}Input schema / properties / time_fieldRemoved value: -{
- "enum": [
- "activity_at",
- "event_start",
- "source_updated_at",
- "indexed_at"
- ],
- "type": "string"
-}Input schema / properties / untilRemoved value: -{
- "format": "date-time",
- "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z|([+-](?:[01]\\d|2[0-3]):[0-5]\\d)))$",
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "query"
+]askask_documentscontextsearch_documentsaskcontextSearch a billion+ documents — papers, books, code, legal cases, forums, Wikipedia, and more.
Query-matched doc excerpts in one JSON response. $0.01 USDC on Base via x402, pay-per-success.
Search source collections your team vetted. Every passage cites its URL and fetch date.
Exact source text, not summaries: check citations and quotes in one call; read pages and PDFs.
Add one secure layer between your agents and this server.
