Cited Bitcoin coordination record search (~783k). Lightning. MCP. Not prices/chain analytics.
Scored across 11 tools
Each tool has a distinct retrieval or analysis purpose, with search, specialized find_* lookups, passage retrieval, claim verification, issue/PR review, argument assessment, and contributor lookup separated clearly. The find_* family and the get_passage/verify_claim pair have some conceptual overlap, but their descriptions specify enough boundaries to prevent serious misselection.
Tool names mostly follow a readable verb_noun snake_case pattern: analyze_issue, find_precedent, get_passage, verify_claim. Minor deviations such as the bare verb search and the abbreviated find_spec_impl are understandable and do not undermine the overall consistency.
Eleven tools is well within the ideal range for a research and evidence-retrieval server. Each tool earns its place by covering a distinct operation, from general index search to specialized precedent, incident, and spec/implementation lookups.
The surface covers the core evidence workflow well: search the index, retrieve passages, verify claims, find specific citation categories, analyze issues/PRs, assess arguments, and look up contributor facts. Minor gaps exist around direct comparison or export of evidence and the read-only, capped nature of issue/PR analysis, but these do not fundamentally block the server's purpose.
Issue review scaffold for a public GitHub issue. Live-fetches title, body, and a capped comment thread. Private repos fail. Precedent from the index. Does not post comments.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Alternate to url: owner/repo/issues/n. | |
| url | No | Public GitHub issue URL (https://github.com/owner/repo/issues/n). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses concrete behaviors: live network fetch, capped comment thread, failure on private repos, precedent retrieval from the index, and no comment posting. These details reinforce the readOnly, idempotent, and non-destructive traits without contradicting them.
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 declarative sentences, front-loaded with purpose and key behavior. Every sentence contributes value, though phrases like 'scaffold' and 'Precedent from the index' are slightly cryptic and could be clearer.
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 two-parameter, read-only tool with rich annotations, the description covers access constraints, failure modes, side-effect absence, and live-fetch behavior. It does not describe the exact return shape, but no output schema exists and the behavioral detail is adequate for an agent to invoke it 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%, with both ref and url already documented in the schema. The description adds behavioral context around public issues but does not add extra parameter-level guidance such as ref/url precedence, matching the baseline for high schema coverage.
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?
Description names the resource (public GitHub issue), the behavior (live-fetches title, body, and capped comment thread), and explicit boundaries (private repos fail, does not post comments). This clearly differentiates it from sibling tools like analyze_pr or assess_argument.
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?
The description provides useful context about when the tool applies (public issues) and exclusions (private repos), but it never explicitly states when to prefer this tool over alternatives such as analyze_pr or assess_argument. Usage is implied rather than directly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PR review scaffold for a public GitHub PR. Fetches filenames and a 4000-char patch pack, plus a capped live thread. Private repos fail. Precedent from the index. Does not post comments.
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Alternate to url: owner/repo#n. | |
| url | No | Public GitHub pull request URL (https://github.com/owner/repo/pull/n). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive behavior, and the description adds meaningful behavioral detail beyond that: it fetches filenames and a capped patch pack, caps the live thread, fails on private repos, pulls precedent from the index, and does not post comments. This substantially helps an agent understand side effects and limits.
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 short, front-loaded with the core purpose, and every sentence adds a distinct fact: public scope, fetched content, private-repo failure, precedent, and no comment posting. No filler or redundant 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?
The description covers the main inputs, key limits, failure behavior, and non-mutating nature, which is sufficient for an agent to select and invoke the tool. It does not explain what 'Precedent from the index' means in detail, but the overall fetch behavior is well specified.
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 both parameters already have clear descriptions in the schema. The tool description does not add parameter-level details, but it does not need to because the schema fully documents url and ref.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool fetches data for a public GitHub PR: filenames, a 4000-char patch pack, a capped live thread, and precedent. It is the only PR-specific tool among the siblings, and the phrase 'Does not post comments' further distinguishes it from mutating PR actions.
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?
The description provides clear context: use it for a public GitHub PR, and private repos will fail. It does not explicitly name alternative tools or when-not-to-use conditions relative to siblings, but the public-PR scope and failure mode give an agent enough context to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Match the claim to a discourse game, then the documented counter-move, from Bitcoin_Discourse_Games or Bitcoin_Governance_Complete_Argument_Map. Return pattern + cites. No new synthesis. These files are product policy (internal), not contemporaneous evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Claim or thread excerpt to match against the documented discourse games. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the tool is non-destructive and open-world. The description adds that no new synthesis occurs and the files are product policy, not contemporaneous evidence. It doesn't contradict annotations; it complements them by clarifying the nature of the data. The description adds valuable context about the tool's internal behavior, which is more than just repeating 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 concise and front-loaded with the main action ('Match the claim to a discourse game') and the resources. It provides critical constraints (no new synthesis, internal files) in a compact way. No wasted words, structured effectively for quick consumption.
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 the tool has a single string parameter and no output schema, the description covers the purpose and key constraints. It doesn't describe the return format beyond 'pattern + cites', which might be sufficient for an agent. However, it could clarify what is meant by 'pattern' and 'cites' or how the output is structured, but given the simplicity, it is adequate.
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 parameter 'text' is already well-documented in the schema. The description adds that 'text' should be a claim or thread excerpt to match, which does not go beyond the schema's description. Since coverage is high, a baseline of 3 is appropriate; the description adds no extra semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool matches a claim to a discourse game and returns pattern and citations. It identifies the specific resources used (Bitcoin_Discourse_Games or Bitcoin_Governance_Complete_Argument_Map). It does not explicitly differentiate from siblings, but the verb 'assess' and focus on argument patterns distinguishes it from more general tools like search or analyze_pr.
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?
The description implies usage: when you need to classify a claim into a discourse game and find documented counter-moves. It provides implicit guidance by noting what it does not do ('No new synthesis') and the context of the files. It doesn't explicitly name alternatives, but the sibling list suggests other tools are for different purposes (e.g., analyze_pr for PRs, find_precedent for precedents).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve GitHub, mail, IRC, and Delving cites for a path or symbol. Mail/IRC rarely include paths.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Source path to search (e.g. src/validation.cpp). | |
| repo | No | Optional owner/repo token to include in the query. | |
| query | No | Optional extra search text. | |
| symbol | No | Optional function or type name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, open-world, idempotent, and non-destructive behavior. The description adds genuinely useful behavioral context: the exact sources queried and the limitation that Mail/IRC rarely include paths. This goes beyond the annotations, though it omits any indication of result shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler. The resources and scope appear in the first sentence, and the caveat earns its place in the second.
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 read-only multi-source lookup with fully documented parameters and safety annotations, the description covers the essentials. The main gaps are lack of sibling routing and no description of what a returned cite looks like, so it is adequate but not 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?
The input schema documents all four parameters with meaningful descriptions, so the description does not need to repeat them. Mentioning 'path or symbol' aligns with the schema but adds no new semantics about combinations or defaults, so the baseline of 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?
Description uses a specific verb ('Retrieve') and names concrete resources (GitHub, mail, IRC, and Delving cites) plus the search subject (path or symbol), making the tool's function clear. It does not explicitly differentiate from sibling tools like search or find_incident, so it stops just short of full clarity.
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?
No guidance is given on when to choose this tool over its siblings. The only contextual note, 'Mail/IRC rarely include paths,' is a result-availability caveat rather than an invocation condition, leaving the agent without explicit when/when-not routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve index cites for a named incident or CVE (e.g. CVE-2018-17144). Same search page as search. Empty if the index has no passage.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | CVE id or incident name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds value by specifying that the result is empty when no passage exists in the index, which is a useful edge-case behavior beyond the annotations. It also transparently notes the shared search page with the sibling 'search'.
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 succinct and front-loaded with the core action in the first sentence. The second sentence adds two useful clarifications without fluff. No wasted words, and the structure supports quick comprehension.
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?
The tool is simple with one required parameter and no output schema, and the description explains the output as 'index cites' and the empty-result case. It could be slightly more explicit about the exact return format or pagination, but for a simple read-only lookup tool it is largely 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?
The schema already fully documents the 'query' parameter as 'CVE id or incident name.' The description essentially repeats this and adds an example CVE ID. With 100% schema coverage, the description adds only marginal semantic value, so a baseline score of 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?
The description clearly states a specific action ('Retrieve index cites') on a specific resource ('named incident or CVE'), with an illustrative example. It also differentiates from the search sibling by noting it shares the same search page but is scoped to incidents. This is enough for an agent to know what the tool does.
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?
The usage context is implied: an agent can infer to use this when the query is a named incident or CVE. However, there is no explicit statement of when to prefer this over 'search' or other find_* siblings. The line 'Same search page as search' hints at a relationship but does not give clear routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve BIP, GitHub, and mail cites for a proposal. Disposition is only what a cite heading or URL already says. Does not invent merged/rejected/stalled labels.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Proposal title, BIP number, or change description. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description explicitly states that dispostion is copied from heading/URL and never inented. This prevents an agent from expecting infered merged/rejected/staled statuses – a meaningful behavioral limitation that schema and annotations alone don't convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no filler, and the most scoping fact (what it retrieves) is first. The caveat earns its place by preventing a common misinterpretation.
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 one-parameter read-only lookup the description is mostly complete; annotations cover safety and idempotency. It never spells out the return shape (e.g., list of cite objects vs string), but the term 'cites' plus the dispostion caveat give enough context for selection and invocation. A small gap in output details keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter with an adequate description. The tool description adds no new parameter-level detail beyond reinforcing the BIP angle, so it sits at the baseline for high schema coverage.
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?
Description uses specific verb 'Retrieve' and names exact resource class (BIP, GitHub, mail cites), which clearly separates it from generic 'search' and semantic siblings like find_discourse/find_incident. The scope 'for a proposal' further disambiguates purpose.
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?
The tool's use case is implied: call it when proposual precedent/cites are needed. It never names alternatives or says when not to use it, so an agent comparing siblings must infer routing instead of being tought.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve spec, Core source, and GitHub cites for a spec section or behavior. Cites only. Does not emit aligned/gap/divergence verdicts.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Spec section, rule, or implementation question. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the key behavioral nuance that it returns 'Cites only' and does not emit verdicts, which is not present in annotations. This extra context clarifies the scope of results and avoids misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences, no filler. The core action, scope, and explicit negative constraint are front-loaded. Every word contributes to decision-making, and the structure is highly scannable for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, single-parameter read-only tool, the description covers the essential behavior and output type (spec, Core source, GitHub cites) despite lacking an output schema. It does not discuss edge cases like pagination or formatting, but those are likely unnecessary given the tool's simplicity and annotation-based safety profile. The description is adequate for correct invocation.
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 input schema has 100% coverage for the single 'query' parameter, describing it as 'Spec section, rule, or implementation question.' The tool description adds only the synonym 'behavior' but no new format, constraints, or examples. Since the schema already fully documents the parameter, the description provides marginal added value, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Retrieve') with clear resources ('spec, Core source, and GitHub cites') and scope ('for a spec section or behavior'). It explicitly excludes verdicts, which distinguishes it from siblings like verify_claim or assess_argument. The purpose is unambiguous and differentiated.
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?
The description provides a clear when-not: 'Does not emit aligned/gap/divergence verdicts,' which implies it is for citation retrieval, not analysis. However, it stops short of naming specific sibling tools as alternatives, so it lacks full explicit routing. This gives clear context without formal exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public-record facts for a GitHub login from research findings. Known set is small (canonical maintainers). Most logins return found=false. Do not invent employment or affiliation.
| Name | Required | Description | Default |
|---|---|---|---|
| login | Yes | GitHub login, case-insensitive. Unknown logins return found=false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive, and the description meaningfully augments them by stating that the dataset is tiny, many lookups are misses, and the agent must not fabricate facts. This is exactly the behavioral context needed for an open-world lookup.
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 short sentences, front-loaded with the tool purpose, then constraints and an anti-hallucination warning. Every sentence earns its place and there is no fluff.
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 one-parameter, read-only tool with no output schema, the description sufficiently covers what the result contains, how often it misses, and what the agent must not do. Nothing critical is missing for correct invocation and interpretation.
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%: the login parameter already explains case-insensitivity and unknown-login behavior. The description adds no extra parameter-level detail but reinforses the small known-set context, 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?
The description clearly identifies the resource (GitHub login) and the operation (retrieve public-record facts from research findings). It implicitly distinguishes itself from sibling tools by its GitHub-specific contributor profile focus, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: the known set is small, most logins return found=false, and the agent must not invent employment or affiliation. This tells the agent when to trust the result, but it does not explicitly state when to prefer sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the stored index passage for a search cite. Pass id from the cite, or source plus doc. Not a live web fetch. If ok is false, the index has no passage.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Vectorize id from a search cite. | |
| doc | No | Document id when id is omitted (with source). | |
| source | No | Corpus source when id is omitted (with doc). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds the behavioral nuance that this is not a live fetch (data comes from the index) and discloses the response condition 'If ok is false, the index has no passage', which is useful beyond 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?
Three short sentences with no filler: purpose, usage, and a key behavioral note. The most important information is front-loaded, and every sentence earns its place without redundancy.
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 no output schema, the description mentions the 'ok' field and the absence condition, which is helpful. It doesn't describe the full passage structure or behavior when both id and source+doc are provided, but the simplicity of the tool and clear parameter guidance make it sufficiently complete for most calls.
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 each parameter is documented individually. The description adds the grouping semantics: id is an alternative to source+doc, clarifying the relationship. This goes beyond the schema's individual descriptions, enhancing the agent's understanding of parameter combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a stored index passage for a search cite, using the specific verb 'return' and the resource 'stored index passage'. This distinguishes it from sibling tools like search or verify_claim, none of which directly retrieve a stored passage.
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 specifies the parameter selection ('Pass id from the cite, or source plus doc') and explicitly notes it is not a live web fetch, which sets an exclusion. However, it doesn't name an alternative tool for live fetching or explain when to prefer this over search, though the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cited Bitcoin coordination index. Not a live quote, ETF, derivatives, or chain analytics. Pin a layer with source. If ok is false, the index has no passage. Every plan searches both layers. Record: IRC review logs, bitcoin-dev and cryptography mailing lists, GitHub PRs/issues/commits, Delving Bitcoin, Bitcointalk, Satoshi communications, BIP text and BIP PRs/issues, release tags/signers, and Bitcoin Core source (consensus, policy, script, validation, net, mempool, miner). Price: CoinMetrics community PriceUSD (source=price), every daily close from 2010-07-18 through the last dated row, packed by ISO week. Curated: named precursor papers (source=articles); academic protocol/security papers (source=papers); open textbooks (source=textbooks: Learning Bitcoin from the Command Line, Karasavvas, minium, Elementary Bitcoin, Dorier C#, Book of Bitcoin commentary, Mastering Bitcoin 2e, Mastering Bitcoin 3e, Mastering LN, Lightning BOLTs, Mastering Taproot, bitcoin.org developer docs and RPC reference, Optech topics/newsletters); specs, maps, research, and topic syntheses (source=synthesis).
| Name | Required | Description | Default |
|---|---|---|---|
| when | No | Optional date pin YYYY, YYYY-MM, or YYYY-MM-DD. Keeps cites whose passage date starts with that prefix. Undated cites drop. | |
| query | Yes | Natural-language question or topic to retrieve cited passages for. | |
| source | No | Optional pin to one corpus source (e.g. github, irc, mail, price, textbooks). Omit to search both layers. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, and idempotentHint, so the tool is known to be safe and non-mutating. The description adds behavioral context such as the 'ok is false' condition meaning no passage found, and the dual-layer search behavior, which goes beyond 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 verbose and dense, with a long list of sources that could be in the enum or a separate document. It lacks front-loading of the core purpose; a lot of detail is packed into one paragraph, making it hard to parse quickly.
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?
The description is rich with context for a complex tool: it explains the data sources, layers, and the 'ok' flag. Although there's no output schema, the description covers return behavior (e.g., cited passages, 'ok is false'), which is sufficient for an agent to use it 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 the schema already documents each parameter adequately. The description adds some semantic context around 'source' (e.g., 'price' for CoinMetrics price) and the meaning of 'when' (date pinning), but mostly reiterates schema info, so a 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?
The description clearly identifies the tool as a search over a cited Bitcoin coordination index, with a specific resource (index) and a clear scope. It distinguishes itself from siblings by focusing on the index search rather than analysis or retrieval of specific passages, though it does not explicitly name sibling 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?
The description provides explicit guidance on when to use the tool: it's not a live quote, ETF, or derivatives, and it explains how to pin a layer with source. It implies that the tool covers both layers of search, but it doesn't contrast with alternatives like 'get_passage' or 'find_discourse' explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Score whether a stored index passage supports a claim. Pass id from a search cite, or source plus doc. Loads the stored excerpt then returns noul 0-1, skipped if the judge is unavailable, or no_passage if the index has no excerpt. Not a live web fetch. The judge is not a source.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Vectorize id from a search cite. | |
| doc | No | Document id when id is omitted (with source). | |
| claim | Yes | Claim to score against the stored excerpt. | |
| source | No | Corpus source when id is omitted (with doc). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive, so the description adds valuably by disclosing edge-case behavior: possible return states like 'skipped' and 'no_passage,' and the warning that 'The judge is not a source.' This goes well beyond the annotation hints.
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 concise and front-loaded: it states the core action, then invocation pattern, then return behavior. The typo 'noul' (apparently 'null') is a minor blemish that prevents a perfect score, but 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?
Even without an output schema, the description enumerates the key return conditions, input alternatives, and a critical caveat about the judge not being a source. For a 4-parameter tool with strong annotations, this is sufficient for an agent to call it 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 coverage is 100%, so the baseline is 3. The description adds meaningful grouping and provenance: id comes 'from a search cite,' and source is used 'with doc,' clarifying the two valid invocation forms beyond the schema's individual property 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?
The description opens with a specific action and resource: 'Score whether a stored index passage supports a claim.' It also distinguishes itself from sibling search/retrieval tools by emphasizing it uses a stored passage and is 'not a live web fetch.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear invocation context: 'Pass id from a search cite, or source plus doc,' which tells an agent when and how to call it. It also warns this is 'not a live web fetch,' but it does not explicitly name sibling tools as alternatives, so it stops short of full when/when-not routing.
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.
analyze_issueanalyze_prassess_argumentfind_discoursefind_incidentfind_precedentfind_spec_implget_contributor_profileget_passagesearchverify_claimLeading non-price Bitcoin signals over MCP: sovereign, hiring, hashrate. Not financial advice.
mempool.space MCP — Bitcoin block explorer + mempool/fee stats
Quantitative Bitcoin stratigraphy dataset featuring thermodynamic signals, Groth16 zk-SNARK verification, and P2P mesh consensus accessible via L402 micropayments.
Bitcoin-anchored sealed-forecast record: search, grades, calibration, luck test. Read-only, no key.
Add one secure layer between your agents and this server.
