Skip to main content

BTCDecoded Intelligence

by org.btcdecoded

Overview Discussions Admin

analyze_submission

Read-onlyIdempotent

Advisory spec-versus-submission check. Retrieves cited index passages, then a closed judge label: met, not_met, or ambiguous. Empty or off-topic cite packs are ambiguous. Scores a named requirement only when a packed cite bears on it. structuredContent.rationale names met, unmet, and unaddressed requirements without pasting excerpts. Optional public GitHub PR (github_pr) is packed; private repos fail. Not a merge, payout, or money check. Does not post comments.

Input Schema

Name	Required	Description	Default
`spec`	Yes	Natural-language spec or acceptance criteria to check against.
`when`	No	Optional date pin YYYY, YYYY-MM, or YYYY-MM-DD. Keeps cites whose passage date starts with that prefix.
`source`	No	Optional pin to one corpus source (e.g. github, irc, mail, spec). Omit to search both layers.
`github_pr`	No	Optional public GitHub PR URL (https://github.com/owner/repo/pull/n) or ref (owner/repo#n). Packed into the submission. Private repos fail. Not an arbitrary URL fetch.
`caller_ref`	No	Optional opaque correlation id. Echoed, not interpreted.
`submission`	Yes	Natural-language submission text (description and/or public PR pack).
`requirements`	No	Optional named criteria strings. When present, the judge scores a criterion 0-1 only if packed cites bear on it; otherwise the score is omitted.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / source / enum

Previous value: -[
-  "corpus",
-  "findings",
-  "spec",
-  "book",
-  "maintainers",
-  "secsov",
-  "commons-whitepaper",
-  "bitcoin-whitepaper",
-  "articles",
-  "papers",
-  "textbooks",
-  "nips",
-  "slips",
-  "sv2",
-  "ln-spec",
-  "tooling",
-  "hw",
-  "synthesis",
-  "blvm-docs",
-  "pool",
-  "vision",
-  "governance",
-  "github",
-  "irc",
-  "mail",
-  "delving",
-  "bitcointalk",
-  "core_src",
-  "src",
-  "satoshi",
-  "releases",
-  "bips",
-  "price",
-  "transcripts",
-  "project"
-]New value: +[
+  "corpus",
+  "findings",
+  "spec",
+  "book",
+  "maintainers",
+  "secsov",
+  "commons-whitepaper",
+  "bitcoin-whitepaper",
+  "articles",
+  "papers",
+  "textbooks",
+  "nips",
+  "slips",
+  "sv2",
+  "ln-spec",
+  "tooling",
+  "hw",
+  "synthesis",
+  "blvm-docs",
+  "pool",
+  "vision",
+  "governance",
+  "github",
+  "irc",
+  "mail",
+  "delving",
+  "bitcointalk",
+  "stackexchange",
+  "core_src",
+  "src",
+  "satoshi",
+  "releases",
+  "bips",
+  "price",
+  "transcripts",
+  "project"
+]

Changed1 schema field changedOct 12, 2026

changedInput schema / properties / source / enum

Previous value: -[
-  "corpus",
-  "findings",
-  "spec",
-  "book",
-  "maintainers",
-  "secsov",
-  "commons-whitepaper",
-  "bitcoin-whitepaper",
-  "articles",
-  "papers",
-  "textbooks",
-  "nips",
-  "slips",
-  "sv2",
-  "ln-spec",
-  "tooling",
-  "hw",
-  "synthesis",
-  "blvm-docs",
-  "pool",
-  "vision",
-  "governance",
-  "github",
-  "irc",
-  "mail",
-  "delving",
-  "bitcointalk",
-  "core_src",
-  "src",
-  "satoshi",
-  "releases",
-  "bips",
-  "price",
-  "transcripts"
-]New value: +[
+  "corpus",
+  "findings",
+  "spec",
+  "book",
+  "maintainers",
+  "secsov",
+  "commons-whitepaper",
+  "bitcoin-whitepaper",
+  "articles",
+  "papers",
+  "textbooks",
+  "nips",
+  "slips",
+  "sv2",
+  "ln-spec",
+  "tooling",
+  "hw",
+  "synthesis",
+  "blvm-docs",
+  "pool",
+  "vision",
+  "governance",
+  "github",
+  "irc",
+  "mail",
+  "delving",
+  "bitcointalk",
+  "core_src",
+  "src",
+  "satoshi",
+  "releases",
+  "bips",
+  "price",
+  "transcripts",
+  "project"
+]

Changed1 schema field changedSep 30, 2026

changedInput schema / properties / source / enum

Previous value: -[
-  "corpus",
-  "findings",
-  "spec",
-  "book",
-  "maintainers",
-  "secsov",
-  "commons-whitepaper",
-  "bitcoin-whitepaper",
-  "articles",
-  "papers",
-  "textbooks",
-  "nips",
-  "slips",
-  "sv2",
-  "ln-spec",
-  "tooling",
-  "hw",
-  "synthesis",
-  "blvm-docs",
-  "pool",
-  "vision",
-  "governance",
-  "github",
-  "irc",
-  "mail",
-  "delving",
-  "bitcointalk",
-  "core_src",
-  "src",
-  "satoshi",
-  "releases",
-  "bips",
-  "price"
-]New value: +[
+  "corpus",
+  "findings",
+  "spec",
+  "book",
+  "maintainers",
+  "secsov",
+  "commons-whitepaper",
+  "bitcoin-whitepaper",
+  "articles",
+  "papers",
+  "textbooks",
+  "nips",
+  "slips",
+  "sv2",
+  "ln-spec",
+  "tooling",
+  "hw",
+  "synthesis",
+  "blvm-docs",
+  "pool",
+  "vision",
+  "governance",
+  "github",
+  "irc",
+  "mail",
+  "delving",
+  "bitcointalk",
+  "core_src",
+  "src",
+  "satoshi",
+  "releases",
+  "bips",
+  "price",
+  "transcripts"
+]

Changed1 schema field changedSep 27, 2026

changedInput schema / properties / source / enum

Previous value: -[
-  "corpus",
-  "findings",
-  "spec",
-  "book",
-  "maintainers",
-  "secsov",
-  "commons-whitepaper",
-  "bitcoin-whitepaper",
-  "articles",
-  "papers",
-  "textbooks",
-  "nips",
-  "sv2",
-  "ln-spec",
-  "tooling",
-  "hw",
-  "synthesis",
-  "blvm-docs",
-  "pool",
-  "vision",
-  "governance",
-  "github",
-  "irc",
-  "mail",
-  "delving",
-  "bitcointalk",
-  "core_src",
-  "src",
-  "satoshi",
-  "releases",
-  "bips",
-  "price"
-]New value: +[
+  "corpus",
+  "findings",
+  "spec",
+  "book",
+  "maintainers",
+  "secsov",
+  "commons-whitepaper",
+  "bitcoin-whitepaper",
+  "articles",
+  "papers",
+  "textbooks",
+  "nips",
+  "slips",
+  "sv2",
+  "ln-spec",
+  "tooling",
+  "hw",
+  "synthesis",
+  "blvm-docs",
+  "pool",
+  "vision",
+  "governance",
+  "github",
+  "irc",
+  "mail",
+  "delving",
+  "bitcointalk",
+  "core_src",
+  "src",
+  "satoshi",
+  "releases",
+  "bips",
+  "price"
+]

Changed1 schema field changedSep 23, 2026

changedInput schema / properties / requirements / description

Previous value: -"Optional named criteria strings. When present, the judge may score each 0-1 from the cite pack."New value: +"Optional named criteria strings. When present, the judge scores a criterion 0-1 only if packed cites bear on it; otherwise the score is omitted."

Changed1 schema field changedSep 19, 2026

changedInput schema / properties / source / enum

Previous value: -[
-  "corpus",
-  "findings",
-  "spec",
-  "book",
-  "maintainers",
-  "secsov",
-  "commons-whitepaper",
-  "bitcoin-whitepaper",
-  "articles",
-  "papers",
-  "textbooks",
-  "nips",
-  "sv2",
-  "ln-spec",
-  "synthesis",
-  "blvm-docs",
-  "pool",
-  "vision",
-  "governance",
-  "github",
-  "irc",
-  "mail",
-  "delving",
-  "bitcointalk",
-  "core_src",
-  "src",
-  "satoshi",
-  "releases",
-  "bips",
-  "price"
-]New value: +[
+  "corpus",
+  "findings",
+  "spec",
+  "book",
+  "maintainers",
+  "secsov",
+  "commons-whitepaper",
+  "bitcoin-whitepaper",
+  "articles",
+  "papers",
+  "textbooks",
+  "nips",
+  "sv2",
+  "ln-spec",
+  "tooling",
+  "hw",
+  "synthesis",
+  "blvm-docs",
+  "pool",
+  "vision",
+  "governance",
+  "github",
+  "irc",
+  "mail",
+  "delving",
+  "bitcointalk",
+  "core_src",
+  "src",
+  "satoshi",
+  "releases",
+  "bips",
+  "price"
+]

AddedSep 19, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent, but the description adds genuinely new behavior: it explains the retrieval-then-judge sequence, the ambiguity rule for empty cite packs, what structuredContent.rationale contains, and the failure mode for private repos. These are non-obvious traits not derivable from 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then dense supporting facts with no filler. The telegraphic fragment style ('Not a merge, payout, or money check') is efficient, though the staccato phrasing is slightly harder to parse than flowing prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, yet the description fully explains the return shape (closed judge label plus structuredContent.rationale listing met/unmet/unaddressed requirements) and the edge cases that affect results. 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.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter is already documented in the schema. The description adds meaning for github_pr (packed as submission, not an arbitrary URL fetch) but says little about the semantics of 'when', 'source', or 'requirements' beyond what the schema states, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening 'Advisory spec-versus-submission check' names a specific verb and resource, and the description immediately discloses the closed output label (met, not_met, ambiguous). It also bounds scope negatively ('Not a merge, payout, or money check; does not post comments'), which cleanly separates it from siblings like analyze_pr and analyze_issue.

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

Usage Guidelines4/5

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

It states concrete operating conditions: empty/off-topic cite packs are ambiguous, a named requirement is scored only when a packed cite bears on it, and private-repo PRs fail. What's missing is an explicit 'use this instead of analyze_pr when...' routing sentence against named siblings, but the context is otherwise clear.

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

All BTCDecoded Intelligence tools Inspect

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?