Read-only library, articles, and support data for Agent Paywire.
Scored across 13 tools
Each tool targets a mostly distinct resource or operation: articles, bots, datasets, source cards, protocols, categories, support, trust checklist, changes, and source search. The main potential confusion is between get_source/search_sources/list_changes and get_article, but the descriptions explicitly distinguish Agent Paywire articles from third-party library sources and explain cross-catalog sync. Boundaries are clear after reading the descriptions, though a few tools require that reading to separate correctly.
All tool names use a consistent snake_case verb_noun or verb_object pattern: get_article, get_bot, get_dataset, list_articles, list_bots, search_sources, etc. The single search_* tool fits the same predictable convention, and no mixed camelCase or vague standalone verbs appear.
The server exposes 13 tools, which is well within the appropriate 3-15 range for a content-library server with several entity types. Each tool appears to earn its place by covering a specific catalog entity or metadata operation without obvious redundancy.
The surface covers the library domain well: list/get for articles, bots, and datasets; search/get for third-party sources; protocol facts; categories; change sync; support and trust metadata. Minor gaps remain, such as no text search across articles/bots/datasets and no paged retrieval, but the core read-only lifecycle is covered and agents can work around these via unpaged lists.
Return one Agent Paywire article as Markdown with YAML front matter, by slug. Get slugs from list_articles, or from list_changes after removing the article: prefix. Use get_source for third-party library sources. An unknown slug returns an isError result (No article with slug ...). Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Article slug exactly as in list_articles articles[].slug, e.g. machine-native-economy. Do not include the article: prefix that list_changes uses. |
| Name | Required | Description |
|---|---|---|
| slug | Yes | |
| markdown | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/openWorld, and the description adds genuine context beyond them: error behavior for an unknown slug (isError with 'No article with slug ...'), plus 'Free, no auth.' These are operationally useful details not in the annotations.
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?
Four tight sentences, front-loaded with what it returns, then how to get the input, then the alternative tool, then error/cost/auth notes. No filler.
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?
An output schema exists, so return-shape detail isn't required, yet the description still notes the Markdown+front-matter format. With single required param, documented error path, auth notes, and sibling routing, nothing needed to call it correctly is missing.
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, but the description reinforces the cross-tool nuance of slug format (strip the article: prefix used by list_changes), which is the main misuse risk for this parameter. Adds modest but real value over 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 (Return), resource (one Agent Paywire article), and key detail (as Markdown with YAML front matter, by slug). It also differentiates from siblings by pointing to get_source for third-party library sources, so the agent can distinguish it from other get_* tools.
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?
Explicitly tells the agent where to obtain slugs (list_articles, or list_changes after stripping the article: prefix) and names the alternative tool (get_source) with its applicable condition. Routing is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one verified public agent or bot by id: name, maker, description, protocols, url, license, license_verified, license_url, verified_at, http_status, archive_url, funds_or_keys, and notes. funds_or_keys is true when the software can access a wallet or keys. Take the id from list_bots entries[].id, or from list_changes after removing the bot: prefix. An unknown id returns an isError result (No bot with id ...). Use list_bots to browse every entry. Listed, not endorsed, not investment advice. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Bot id exactly as in list_bots entries[].id, e.g. lnget. Do not include the bot: prefix that list_changes uses. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| name | Yes | |
| maker | Yes | |
| notes | Yes | |
| license | Yes | |
| protocols | Yes | |
| archive_url | Yes | |
| description | Yes | |
| http_status | Yes | |
| license_url | Yes | |
| verified_at | Yes | |
| funds_or_keys | Yes | |
| license_verified | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds real behavioral context: an unknown id yields an isError result with a specific message, no auth is required, and funds_or_keys carries a concrete semantic (software can access a wallet or keys). The 'listed, not endorsed' framing also sets expectations about data trustworthiness.
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?
Purpose and the id source are front-loaded, and the sentences are dense but purposeful. The 13-field enumeration duplicates what the output schema already provides, which is the main source of bloat, though the disclaimer sentence is short and earns its place for data-trust context.
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 an output schema present, return values need no prose, and the description still supplies the id-format rule, error handling, auth requirement, and the meaning of the one ambiguous field. For a single-parameter read tool nothing an agent needs is missing.
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% and the schema already documents the single id parameter with the 'no bot: prefix' rule and an example, so baseline 3 applies. The description restates id sourcing but adds no format or validation detail beyond 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 ('Return one verified public agent or bot by id') and enumerates the returned fields, immediately distinguishing it from sibling list tools like list_bots and get_article. An agent can tell exactly what this tool retrieves 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?
Gives explicit sourcing guidance ('Take the id from list_bots entries[].id, or from list_changes after removing the bot: prefix') and names list_bots as the browse alternative. It lacks an explicit exclusion (e.g., when not to use it versus a search tool), so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return one training or eval dataset card by id: name, publisher, url, access (open, login, or terms-acceptance), mirror_allowed, and notes. A card is metadata only and does not download dataset files, so follow url for the data. Take the id from list_datasets entries, or from list_changes after removing the dataset: prefix. An unknown id returns an isError result (the card file is 404). Use list_datasets to browse cards, and search_sources with category datasets-benchmarks for papers about datasets. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Dataset id exactly as in list_datasets entries[].id, e.g. agentpaywire-library. Do not include the dataset: prefix that list_changes uses. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| name | Yes | |
| notes | Yes | |
| access | Yes | |
| publisher | Yes | |
| mirror_allowed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, and the description adds meaningful behavior on top: metadata-only with no file download, an unknown id producing an isError/404, and a 'Free, no auth' note. That is exactly the extra context the structured fields cannot carry.
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?
Four dense sentences, each doing distinct work: purpose+fields, non-download caveat, id sourcing, and error/routing behavior. The core action is front-loaded and there is no filler.
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 single-parameter lookup with an output schema, this covers everything an agent needs: field inventory, that files are not fetched, where ids originate, error semantics, and no-auth status. Return-value detail is legitimately omitted since an output schema exists.
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 the single id parameter, its example, and the no-'dataset:' prefix rule. The description restates the same prefix guidance rather than adding new syntax or constraints, so baseline 3 is appropriate.
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?
Opens with a specific verb+resource pair ('Return one training or eval dataset card by id') and enumerates the fields the card carries, so the agent knows exactly what this returns. It is clearly distinguishable from siblings like get_source and list_datasets.
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?
Explicitly names the alternatives and the selection conditions: use list_datasets to browse, search_sources with category datasets-benchmarks for papers, and it tells where the id comes from (list_datasets entries, or list_changes minus the dataset: prefix). Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return source-cited facts for agent payment protocols: spec URL, HTTP status codes and headers, payment rail, networks, facilitators, client libraries, pay flow, and an example. Every fact carries its source URL and verified_at; null means the cited page does not state it. Omit id for all nine protocols in a protocols array (about 23 KB); pass id for that one protocol's object only. Use this for how a protocol works. Use search_sources for papers or docs about it, and get_support_info for this site's own paid L402 API. An id outside the enum is rejected as invalid input. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Lowercase protocol id from the enum, e.g. l402. Set it to get one protocol object (smaller response); omit it to get every protocol in a protocols array. |
| Name | Required | Description |
|---|---|---|
| id | No | |
| protocols | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnly, idempotent, openWorld), so the bar is lower, yet the description adds real operational context: citation provenance (source URL + verified_at), null-means-not-stated semantics, response size (~23 KB for the all-protocols array), invalid-input rejection for out-of-enum ids, and that access is free with no auth. These are facts an agent cannot infer from the annotations or schema alone.
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 purpose is front-loaded and every sentence carries information; the field enumeration is long but functional, telling the agent what to expect in the payload. The trailing note about out-of-enum ids is mildly redundant with the schema's enum, which keeps it short of a perfect score.
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 an output schema present the description needn't document return values, and it nonetheless supplies the response shape, size, provenance semantics, and error behavior. For a single-optional-parameter read tool, nothing an agent needs to select or invoke it correctly is missing.
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% and the schema already explains omit-vs-set behavior, so the baseline is 3. The description still adds value beyond the schema by quantifying the response-size difference (~23 KB array), clarifying the null-means-unspecified convention, and stating that out-of-enum ids are rejected as invalid input.
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?
It names a specific verb and resource ('Return source-cited facts for agent payment protocols') and enumerates the exact fact categories returned (spec URL, HTTP status codes, payment rail, networks, facilitators, pay flow, example), so an agent knows precisely what it gets. It also explicitly separates itself from siblings by naming search_sources and get_support_info as the tools for related-but-different needs.
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?
Usage is stated in both directions: 'Use this for how a protocol works' plus explicit alternatives for adjacent needs ('Use search_sources for papers or docs about it, and get_support_info for this site's own paid L402 API'). The call-shape guidance (omit id for all nine, pass id for one) is tied to the concrete scenario of wanting breadth vs. depth.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one third-party library source card by id: title, publisher, authors, date_published, url, type, category, summary, tags, verified_at and featured. Ids are sources[].id from search_sources, or list_changes entries of kind library (no prefix). Use search_sources when you have no id. Use get_article for Agent Paywire's own articles. An unknown id returns an isError result (No source with id ...). Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Source id exactly as returned in sources[].id, e.g. lightning-labs-l402-for-agents. Case and hyphens must match. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| tags | Yes | |
| type | Yes | |
| title | Yes | |
| authors | Yes | |
| summary | Yes | |
| category | Yes | |
| featured | No | |
| publisher | Yes | |
| verified_at | Yes | |
| date_published | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior, so the bar is lower. The description adds useful context beyond annotations: it says access is free with no auth and that an unknown id returns an isError result with a specific message, though it does not expand on openWorld implications or return shape 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 definition is compact and front-loaded: it begins with the core action and resource, then field list, id origin, alternatives, and error/auth behavior. Every sentence adds routing or behavioral value with no filler.
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 single-parameter read tool with rich annotations and an output schema, the description is complete enough: it tells the agent what the tool returns, where the required id comes from, sibling alternatives, error behavior, and auth/cost context. No material invocation detail is missing.
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 already 3. The description adds meaning beyond the schema by explaining where the id comes from: sources[].id from search_sources, or list_changes entries of kind library without a prefix. That helps an agent obtain a valid id, though the schema itself already warns about exact case and hyphens.
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: fetch one third-party library source card by id, and enumerates the fields returned. It explicitly distinguishes this from search_sources and get_article, so an agent can identify its role among siblings without opening schemas.
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 explicit routing rules: use this when you have an id from search_sources or list_changes entries of kind library, use search_sources when you have no id, and use get_article for Agent Paywire articles. This covers when to use, when not to use, and the alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the voluntary support descriptor: donation methods (Bitcoin on-chain, Lightning BOLT12, USDC on EVM networks and Solana) with addresses, suggested sat amounts, and the paid_api block (L402 over Lightning, 100 sats for 100 credits, valid 30 days). Calling it never sends money or creates an invoice, and the data stays free whether or not anyone pays. Use it when a user wants to tip or asks how to pay for the API. Use get_trust_checklist for error codes, rate limits, and stable URLs. Use get_protocol_facts for third-party payment protocols. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| methods | Yes | |
| voluntary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=true. The description adds non-redundant behavior: calling it never sends money or creates an invoice, the data is free regardless of payment, and it requires no auth. That is meaningful beyond the annotations, though return/pagination shape is left to the output schema.
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-loads the core purpose, then the behavioral guarantee, then the two sibling routes and auth note. Every sentence carries a distinct fact, though the parenthetical payment-method list is somewhat dense for a selection-focused description.
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?
An output schema exists, so return-value details need not be spelled out; the description still covers non-mutation, no-auth, and where adjacent needs live. Sufficient for an agent to select and invoke it correctly, with only minor room to note freshness or idempotency beyond annotations.
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, so the baseline is 4; schema description coverage is 100% and there is nothing for the description to compensate for. No parameter guidance is needed or missing.
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 ('Return the voluntary support descriptor') and enumerates exactly what it contains: donation methods (Bitcoin on-chain, Lightning BOLT12, USDC on EVM/Solana) with addresses and amounts, plus the paid_api block. An agent can distinguish it from the other get_* siblings without opening a 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?
Gives an explicit trigger ('when a user wants to tip or asks how to pay for the API') and routes two adjacent needs elsewhere: get_trust_checklist for error codes/rate limits/stable URLs, get_protocol_facts for third-party payment protocols. When-to-use and alternatives are both named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the agent trust checklist for agentpaywire.com: commitments on stable URLs, errors and limits, and naming, each with status met or partial and evidence URLs, plus the paid API's error codes, rate-limit policy, credit terms, and the list of MCP tools. Use it to judge whether the site and its paid API are dependable or to look up an error code. Use get_support_info for donation addresses and payment methods. Use get_protocol_facts for third-party protocols. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| items | Yes | |
| title | Yes | |
| tools | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish safe read-only, idempotent, open-world behavior. The description adds useful non-schema context such as 'Free, no auth' and enumerates the returned trust-checklist contents, though it does not add freshness or caching 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 dense but front-loaded: the main return value comes first, then use cases and alternatives, ending with access terms. Every clause adds useful routing or content 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?
Given zero parameters, rich annotations, and a present output schema, the description supplies all needed context: what is returned, when to use it, and which sibling tools handle adjacent needs. Nothing important is missing.
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, so parameter semantics are inherently simple. The description does not need to explain inputs, and a baseline of 4 is appropriate.
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: returns the agent trust checklist for agentpaywire.com, and summarizes the included commitments, evidence, API error codes, rate limits, credit terms, and MCP tool list. It clearly distinguishes itself from get_support_info and get_protocol_facts.
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?
Explicitly says to use it to judge site/API dependability or look up an error code, and directly routes donation/payment questions to get_support_info and third-party protocol questions to get_protocol_facts. Both when-to-use and alternatives are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all of Agent Paywire's own published articles with slug, title, summary, date, status, tags, and URLs, in one unpaged response. Use get_article with a slug to read the Markdown. Third-party papers, specs, and reports are library sources: use search_sources, not this tool. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, and the description adds useful operational context: one unpaged response and free/no-auth access. Those details materially help an agent understand invocation behavior beyond the annotations.
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 compact and front-loaded: it states what is listed and in what shape, then gives alternative-tool routing. Every sentence adds useful selection or invocation context.
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?
Given zero parameters, an output schema, and rich annotations, the description is complete for selecting and calling the tool. It even summarizes returned fields and access conditions without redundancy.
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?
There are zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and the schema is empty.
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: listing Agent Paywire's own published articles, with the exact fields returned. It also separates this tool from get_article and search_sources, so an agent can distinguish it from siblings without opening schemas.
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?
Explicitly routes the agent: use get_article with a slug to read Markdown, and use search_sources for third-party papers/specs/reports rather than this tool. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every verified public agent or bot that pays, gets paid, or connects a wallet, with maker, protocols, license status, url, verified_at, and funds_or_keys (true when the software can access a wallet or keys). Inclusion needs a public repo or demo, a known maker, and a push in the 12 months before verification. Use get_bot with an entries[].id value for one record. Use search_sources for papers and docs about agents, and get_protocol_facts for how a payment protocol works. list_changes lists recent edits as kind bot; remove the bot: prefix before calling get_bot. Listed, not endorsed, not investment advice. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| entries | Yes | |
| disclaimer | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: inclusion criteria (public repo/demo, known maker, recent push), the 'listed, not endorsed, not investment advice' caveat, and 'free, no auth'.
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?
Dense but front-loaded: purpose first, then alternatives, then caveats. Every sentence carries information, though the list_changes/bot: prefix detail is a minor tangent that could be trimmed.
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?
An output schema exists so return values needn't be spelled out, and with no parameters there is little else to cover. The description still supplies inclusion criteria, auth posture, and routing, leaving only pagination/ordering unaddressed.
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?
Zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. It goes further by naming the returned fields (maker, protocols, license status, url, verified_at, funds_or_keys), though those are a describe-return concern rather than a parameter concern.
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 verified public agents/bots) with a scoping qualifier ('that pays, gets paid, or connects a wallet'), which cleanly separates it from list_articles, list_datasets, and list_categories.
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?
Explicitly routes to alternatives with conditions: get_bot for a single record, search_sources for papers/docs, get_protocol_facts for protocol mechanics, and list_changes for recent edits, including the bot: prefix caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the eight library categories with id, label, featured flag, source count, and links to each category JSON, Markdown, and HTML page. Bitcoin and Lightning is first. Use a category id with search_sources. This tool does not return the sources themselves. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| categories | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive. The description adds genuinely useful context beyond them: 'Free, no auth', the exact return shape, and the negative scope (no sources returned). Does not cover pagination/limits, but a static eight-item list needs little of that.
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?
Five short sentences, front-loaded with what the tool returns, followed by the ordering note, the sibling routing, the exclusion, and the auth note. 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-param, read-only list tool with an output schema and full annotations, the description covers purpose, return fields, ordering, and the hand-off to search_sources. Nothing an agent needs to call it correctly is missing.
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?
Zero parameters, so the baseline is 4. There is nothing to disambiguate, and the description correctly notes the category id is consumed by search_sources rather than being an input 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?
States a specific verb (List) and resource (library categories), and enumerates exactly what each entry contains (id, label, featured flag, source count, links). It also distinguishes itself from sibling search_sources by declaring it does not return the sources themselves.
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?
Explicitly routes the agent: 'Use a category id with search_sources' and clarifies the boundary ('does not return the sources themselves'). Clear usage context is present, though it doesn't enumerate when *not* to call it beyond the sources caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync records whose verified_at is later than cursor (exclusive) across library sources, articles, datasets, bots, and support notes. Each row has kind, id, title, url, and verified_at. There is no text filter and no paging, so an old cursor can return the whole catalog (over 100 entries, about 43 KB). This does not return source cards: use search_sources to browse or filter the library, including newest-first and updated_since. Strip article:, dataset:, bot:, or support: before get_article, get_dataset, or get_bot. Library ids have no prefix; use get_source. A cursor that is not YYYY-MM-DD returns an isError result. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | Yes | Date as YYYY-MM-DD, e.g. 2026-10-19. Records with verified_at strictly later are returned; today's date usually returns 0 rows. Other formats are rejected. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| cursor | Yes | |
| entries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld/non-destructive, so the bar is lower, yet the description adds substantive context beyond them: no text filter, no paging, an old cursor can return the entire catalog (~100 entries, ~43 KB), a malformed cursor yields an isError result, and the call is free with no auth. These are the operational facts an agent needs before invoking.
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?
Dense but front-loaded: scope first, then result shape, then limitations, then sibling routing. A mild redundancy exists in that the cursor format/rejection rule is stated in both the description and the schema, which is the only sentence that does not fully earn 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?
An output schema exists, so return values need not be explained, yet the description helpfully previews row fields (kind, id, title, url, verified_at). Error behavior, payload-size risk, and sibling hand-offs are all covered, leaving nothing an agent needs before calling.
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 already 100% and restates the YYYY-MM-DD format and strict-later comparison, so the description adds little that is new. It does usefully reinforce the exclusive boundary and the practical consequence that today's date usually returns zero rows, which helps the agent choose a cursor value.
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 ("Sync records whose verified_at is later than cursor") and enumerates the entity kinds covered (library sources, articles, datasets, bots, support notes). It explicitly distinguishes itself from search_sources, which the agent can act on 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 alternatives with the condition that selects them: search_sources for browsing/filtering the library (newest-first, updated_since), and the prefix-stripping rule that routes results to get_article, get_dataset, get_bot, or get_source. Explicitly rules out what this tool is not for (source cards).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every training and evaluation dataset card in the catalog (payments, Lightning, fraud, agent tool use) in one unpaged response. Agent Paywire's own library dataset is first. Each entry has id, name, and url; count is the number of cards. Cards are metadata: nothing is downloaded. Use get_dataset with an entry id for access terms and mirror rights. Use search_sources with category datasets-benchmarks for papers and benchmark sources. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| entries | Yes | |
| model_note | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description still adds real context beyond them: single unpaged response, deterministic ordering with the library dataset first, and that cards are metadata with nothing downloaded. That last point is the kind of behavioral clarification the annotations cannot express.
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?
Five short sentences, all front-loaded with the scope and contents before the routing guidance. Every sentence carries distinct information with no repetition of the title or annotations.
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?
Even though an output schema exists, the description covers scope, ordering, metadata-only semantics, auth cost and alternatives — everything an agent needs to call this correctly and decide against it. Nothing material is missing.
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?
Zero parameters, so the baseline is 4. The description does not need to explain any inputs, and the response shape it mentions (id, name, url, count) is return-value detail rather than parameter semantics.
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 every training and evaluation dataset card in the catalog'), plus the exact scope (unpaged, all categories) and that Agent Paywire's own dataset comes first. This is clearly distinguishable from get_dataset and search_sources.
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?
Explicitly routes the agent: use get_dataset with an entry id for access terms and mirror rights, and search_sources with category datasets-benchmarks for papers and benchmarks. Both the alternative and the condition selecting it are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find third-party library source cards. This is the only library lookup: text, exact filters, and newest-first browsing. query words must all match as case-insensitive substrings of id, title, summary, publisher, type, authors, or tags. category, tag, type, featured, and updated_since are AND filters. Omit query to list the newest sources, optionally in one category. get_source fetches one known id. list_changes is the unpaged cross-catalog sync and does not return source cards. Results are newest date_published first, undated last. limit is 1-50 (default 10) with no offset, and count is the rows returned. No matches returns count 0. A non-calendar updated_since, or an unknown category, returns an isError result. Free, no auth.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | One tag, exact match, e.g. l402. Combined with the other filters (AND). | |
| type | No | Source type from the enum, e.g. spec. Combined with the other filters (AND). | |
| limit | No | Maximum rows, 1-50, default 10. Values above 50 are rejected. There is no offset; narrow the filters to see other matches. | |
| query | No | Space-separated words; every word must match (AND), case-insensitive substring of id, title, summary, publisher, type, authors, or tags. Example: lightning l402. Omit or use an empty string to skip the text filter. | |
| category | No | Category id from list_categories, e.g. bitcoin-lightning. Combined with the other filters (AND). Omit for every category. | |
| featured | No | true returns only featured sources. Omit or false to include all. | |
| updated_since | No | YYYY-MM-DD calendar date. Keeps sources whose verified_at is later than this date (exclusive). A value that is not that form returns an isError result. Example: 2026-10-01. |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the safety profile (readOnly/idempotent/non-destructive), and the description layers on the things they cannot express: newest-first ordering with undated last, no offset pagination, 1-50 limit, count semantics, count 0 on no match, and two specific isError triggers (non-calendar updated_since, unknown category). 'Free, no auth' removes any auth guesswork.
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?
Every sentence carries a distinct behavioral fact — scoping, filter logic, ordering, pagination, error cases — with the most decisive claim ('the only library lookup') front-loaded. 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?
With an output schema present, return values need not be described, yet the description still clarifies count and empty-result behavior. For a 7-parameter, zero-required search tool with annotations already covering safety, nothing needed to invoke it correctly is missing.
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, but the description adds filter-combination semantics ('category, tag, type, featured, and updated_since are AND filters') and an error contract for unknown category that the schema does not state. It also restates some schema content (substring fields, limit range), so it is additive rather than fully value-adding.
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?
Opens with a specific verb+resource ('Find third-party library source cards') and immediately scopes it against the whole toolset: 'This is the only library lookup: text, exact filters, and newest-first browsing.' An agent can distinguish it from get_source and list_changes without opening any 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?
Gives explicit routing: use get_source for a single known id, use list_changes for unpaged cross-catalog sync, and omit query to browse newest sources. The conditions that select each alternative are stated, not implied.
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.
changes_sinceget_article1 field changedInput schema / properties / slug / descriptionPrevious value: -"Article slug exactly as in list_articles articles[].slug, e.g. machine-native-economy. Do not include the article: prefix that changes_since uses."New value: +"Article slug exactly as in list_articles articles[].slug, e.g. machine-native-economy. Do not include the article: prefix that list_changes uses."get_bot1 field changedInput schema / properties / id / descriptionPrevious value: -"Bot id exactly as in list_bots entries[].id, e.g. lnget. Do not include the bot: prefix that changes_since uses."New value: +"Bot id exactly as in list_bots entries[].id, e.g. lnget. Do not include the bot: prefix that list_changes uses."get_dataset1 field changedInput schema / properties / id / descriptionPrevious value: -"Dataset id exactly as in list_datasets entries[].id, e.g. agentpaywire-library. Do not include the dataset: prefix that changes_since uses."New value: +"Dataset id exactly as in list_datasets entries[].id, e.g. agentpaywire-library. Do not include the dataset: prefix that list_changes uses."get_protocol_factslatest_sourceslist_changesprotocol_factssearchsearch_librarysearch_sourceschanges_since1 field changedInput schema / properties / cursor / descriptionPrevious value: -"YYYY-MM-DD. Example: 2026-10-19. Records with a later verified_at are returned."New value: +"Date as YYYY-MM-DD, e.g. 2026-10-19. Records with verified_at strictly later are returned; today's date usually returns 0 rows. Other formats are rejected."get_article1 field changedInput schema / properties / slug / descriptionPrevious value: -"Article slug. Example: machine-native-economy."New value: +"Article slug exactly as in list_articles articles[].slug, e.g. machine-native-economy. Do not include the article: prefix that changes_since uses."get_botget_dataset1 field changedInput schema / properties / id / descriptionPrevious value: -"Dataset id. Example: agentpaywire-library."New value: +"Dataset id exactly as in list_datasets entries[].id, e.g. agentpaywire-library. Do not include the dataset: prefix that changes_since uses."get_source1 field changedInput schema / properties / id / descriptionPrevious value: -"Source id. Example: lightning-labs-l402-for-agents."New value: +"Source id exactly as returned in sources[].id, e.g. lightning-labs-l402-for-agents. Case and hyphens must match."latest_sources2 fields changedInput schema / properties / category / descriptionPrevious value: -"Category id. Example: bitcoin-lightning."New value: +"Optional category id from list_categories, e.g. bitcoin-lightning. Filters before the limit is applied; omit for all categories."Input schema / properties / limit / descriptionPrevious value: -"Maximum rows, from 1 to 50. Example: 10. Default 10."New value: +"Maximum rows to return, 1-50, default 10. Values above 50 are rejected, and there is no offset to page further."protocol_facts1 field changedInput schema / properties / id / descriptionPrevious value: -"Protocol id. Example: l402. Omit for every protocol."New value: +"Lowercase protocol id from the enum, e.g. l402. Set it to get one protocol object (smaller response); omit it to get every protocol in a protocols array."search7 fields changedInput schema / properties / category / descriptionPrevious value: -"Category id. Example: bitcoin-lightning."New value: +"Category id from list_categories, e.g. bitcoin-lightning."Input schema / properties / featured / descriptionPrevious value: -"true keeps featured records. Example: true. Omit to include the rest."New value: +"true returns only featured sources. Omit to include all."Input schema / properties / limit / descriptionPrevious value: -"Maximum rows, from 1 to 50. Example: 10. Default 10."New value: +"Maximum rows, 1-50, default 10. Values above 50 are rejected; there is no offset."Input schema / properties / q / descriptionPrevious value: -"One substring of id, title, summary, or publisher. Example: L402."New value: +"One substring, matched case-insensitively against id, title, summary or publisher (not authors or tags). Example: L402. Spaces are part of the substring."Input schema / properties / tag / descriptionPrevious value: -"Exact tag. Example: l402."New value: +"One tag, exact match, e.g. l402."Input schema / properties / type / descriptionPrevious value: -"Library type. Example: spec."New value: +"Source type from the enum, e.g. spec."Input schema / properties / updated_since / descriptionPrevious value: -"YYYY-MM-DD exclusive lower bound on verified_at. Example: 2026-10-01."New value: +"YYYY-MM-DD calendar date; returns sources whose verified_at is later than this date (exclusive). A value that is not that form returns an isError result. Example: 2026-10-01."search_library4 fields changedInput schema / properties / category / descriptionPrevious value: -"Category id. Example: bitcoin-lightning."New value: +"Optional category id from list_categories, e.g. bitcoin-lightning. Combined with query (AND)."Input schema / properties / featured_only / descriptionPrevious value: -"true keeps sources marked featured. Example: true. Omit to include the rest."New value: +"true returns only featured sources. Omit or false to include all."Input schema / properties / limit / descriptionPrevious value: -"Maximum rows, from 1 to 50. Example: 10. Default 10."New value: +"Maximum rows, 1-50, default 10. Values above 50 are rejected; there is no offset, so narrow the query to see other matches."Input schema / properties / query / descriptionPrevious value: -"Words that must all match. Example: lightning l402."New value: +"Space-separated words; every word must match (AND), case-insensitive substring. Example: lightning l402. An empty string matches everything."changes_since2 fields changedInput schema / properties / cursor / descriptionPrevious value: -"YYYY-MM-DD. Records with a later verified_at are returned."New value: +"YYYY-MM-DD. Example: 2026-10-19. Records with a later verified_at are returned."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "cursor": {
+ "type": "string"
+ },
+ "entries": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "kind": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "kind",
+ "title",
+ "verified_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "cursor",
+ "count",
+ "entries"
+ ],
+ "type": "object"
+}get_article2 fields changedInput schema / properties / slug / descriptionPrevious value: -"Article slug, for example machine-native-economy."New value: +"Article slug. Example: machine-native-economy."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "markdown": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "markdown"
+ ],
+ "type": "object"
+}get_dataset2 fields changedInput schema / properties / id / descriptionPrevious value: -"Dataset id, for example agentpaywire-library or elliptic."New value: +"Dataset id. Example: agentpaywire-library."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "access": {
+ "enum": [
+ "open",
+ "login",
+ "terms-acceptance"
+ ],
+ "type": "string"
+ },
+ "id": {
+ "type": "string"
+ },
+ "mirror_allowed": {
+ "type": "boolean"
+ },
+ "name": {
+ "type": "string"
+ },
+ "notes": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "publisher",
+ "url",
+ "access",
+ "mirror_allowed",
+ "notes"
+ ],
+ "type": "object"
+}get_source2 fields changedInput schema / properties / id / descriptionPrevious value: -"Source id, for example lightning-labs-l402-for-agents."New value: +"Source id. Example: lightning-labs-l402-for-agents."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "authors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "date_published": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "featured": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "publisher",
+ "authors",
+ "date_published",
+ "url",
+ "type",
+ "category",
+ "summary",
+ "tags",
+ "verified_at"
+ ],
+ "type": "object"
+}get_support_info1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "methods": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "type"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "voluntary": {
+ "type": "boolean"
+ }
+ },
+ "required": [
+ "voluntary",
+ "methods"
+ ],
+ "type": "object"
+}get_trust_checklist1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "items": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "status": {
+ "enum": [
+ "met",
+ "partial"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "status"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "tools": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "title",
+ "items",
+ "tools"
+ ],
+ "type": "object"
+}latest_sources6 fields changedInput schema / properties / category / descriptionPrevious value: -"Optional category id."New value: +"Category id. Example: bitcoin-lightning."Input schema / properties / category / enumAdded value: +[
+ "bitcoin-lightning",
+ "payments",
+ "agent-protocols",
+ "robotics-autonomy",
+ "iot",
+ "datasets-benchmarks",
+ "safety-security",
+ "regulation"
+]Input schema / properties / limit / descriptionPrevious value: -"Maximum results, 1 to 50. Default 10."New value: +"Maximum rows, from 1 to 50. Example: 10. Default 10."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "authors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "date_published": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "featured": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "publisher",
+ "authors",
+ "date_published",
+ "url",
+ "type",
+ "category",
+ "summary",
+ "tags",
+ "verified_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "sources"
+ ],
+ "type": "object"
+}list_articles1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "articles": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "date": {
+ "type": "string"
+ },
+ "md_url": {
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "status": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "summary",
+ "date",
+ "status",
+ "tags",
+ "url",
+ "md_url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "articles"
+ ],
+ "type": "object"
+}list_bots1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "disclaimer": {
+ "type": "string"
+ },
+ "entries": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "funds_or_keys": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "maker": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "maker",
+ "funds_or_keys",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "disclaimer",
+ "entries"
+ ],
+ "type": "object"
+}list_categories1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "categories": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "number"
+ },
+ "featured": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "label": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "label",
+ "featured",
+ "count"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "categories"
+ ],
+ "type": "object"
+}list_datasets1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "entries": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "name": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "name",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "model_note": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "count",
+ "entries",
+ "model_note"
+ ],
+ "type": "object"
+}protocol_facts3 fields changedInput schema / properties / id / descriptionPrevious value: -"Protocol id, for example l402 or x402."New value: +"Protocol id. Example: l402. Omit for every protocol."Input schema / properties / id / enumAdded value: +[
+ "l402",
+ "bolt12",
+ "bip21",
+ "nwc",
+ "x402",
+ "mpp",
+ "ap2",
+ "acp",
+ "ucp"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "protocols": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "type": "object"
+}search12 fields changedInput schema / properties / category / descriptionPrevious value: -"Exact category id."New value: +"Category id. Example: bitcoin-lightning."Input schema / properties / category / enumAdded value: +[
+ "bitcoin-lightning",
+ "payments",
+ "agent-protocols",
+ "robotics-autonomy",
+ "iot",
+ "datasets-benchmarks",
+ "safety-security",
+ "regulation"
+]Input schema / properties / featured / descriptionPrevious value: -"When true, keep featured records."New value: +"true keeps featured records. Example: true. Omit to include the rest."Input schema / properties / limit / descriptionPrevious value: -"Maximum results, 1 to 50. Default 10."New value: +"Maximum rows, from 1 to 50. Example: 10. Default 10."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / q / descriptionPrevious value: -"Substring matched against id, title, summary, and publisher."New value: +"One substring of id, title, summary, or publisher. Example: L402."Input schema / properties / tag / descriptionPrevious value: -"Exact tag."New value: +"Exact tag. Example: l402."Input schema / properties / type / descriptionPrevious value: -"Exact library type."New value: +"Library type. Example: spec."Input schema / properties / type / enumAdded value: +[
+ "announcement",
+ "directory",
+ "docs",
+ "regulatory",
+ "repo",
+ "report",
+ "research-paper",
+ "spec"
+]Input schema / properties / updated_since / descriptionPrevious value: -"YYYY-MM-DD. Exclusive lower bound on verified_at."New value: +"YYYY-MM-DD exclusive lower bound on verified_at. Example: 2026-10-01."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "authors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "date_published": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "featured": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "publisher",
+ "authors",
+ "date_published",
+ "url",
+ "type",
+ "category",
+ "summary",
+ "tags",
+ "verified_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "sources"
+ ],
+ "type": "object"
+}search_library8 fields changedInput schema / properties / category / descriptionPrevious value: -"Category id, for example bitcoin-lightning."New value: +"Category id. Example: bitcoin-lightning."Input schema / properties / category / enumAdded value: +[
+ "bitcoin-lightning",
+ "payments",
+ "agent-protocols",
+ "robotics-autonomy",
+ "iot",
+ "datasets-benchmarks",
+ "safety-security",
+ "regulation"
+]Input schema / properties / featured_only / descriptionPrevious value: -"When true, keep sources marked featured."New value: +"true keeps sources marked featured. Example: true. Omit to include the rest."Input schema / properties / limit / descriptionPrevious value: -"Maximum results, 1 to 50. Default 10."New value: +"Maximum rows, from 1 to 50. Example: 10. Default 10."Input schema / properties / limit / maximumAdded value: +50Input schema / properties / limit / minimumAdded value: +1Input schema / properties / query / descriptionPrevious value: -"Words to match. An empty query returns the filtered list."New value: +"Words that must all match. Example: lightning l402."Output schema / (root)Previous value: -nullNew value: +{
+ "$schema": "http://json-schema.org/draft-07/schema#",
+ "additionalProperties": false,
+ "properties": {
+ "count": {
+ "type": "integer"
+ },
+ "sources": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "authors": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "category": {
+ "type": "string"
+ },
+ "date_published": {
+ "type": [
+ "string",
+ "null"
+ ]
+ },
+ "featured": {
+ "type": "boolean"
+ },
+ "id": {
+ "type": "string"
+ },
+ "publisher": {
+ "type": "string"
+ },
+ "summary": {
+ "type": "string"
+ },
+ "tags": {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "title": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ },
+ "verified_at": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "publisher",
+ "authors",
+ "date_published",
+ "url",
+ "type",
+ "category",
+ "summary",
+ "tags",
+ "verified_at"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "count",
+ "sources"
+ ],
+ "type": "object"
+}get_datasetget_trust_checklistlist_botslist_datasetschanges_sinceget_articleget_sourceget_support_infolatest_sourceslist_articleslist_categoriesprotocol_factssearchsearch_libraryPublic read-only SYMBaiEX developer and agent documentation.
Read-only IMBA Agent API docs MCP. No register, deposit, buy, or withdraw.
Read-only Genko Prior Auth docs, guides, specialty checklists, facts, pricing and fit checks.
Help desk for agents. Search questions and answers first. Read-only MCP.
Add one secure layer between your agents and this server.