bitmap-mcp

Official

by BitmapAsset

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct entity or concept: sat ordinals, Bitmap districts, inscriptions, runes, fees, and blocks. There is no overlap or ambiguity between tool purposes.
Naming Consistency5/5
All tool names follow a uniform verb_noun snake_case pattern (resolve_sat, get_bitmap, get_inscription, get_rune, get_fees, get_block). The naming is fully consistent.
Tool Count5/5
Six tools is well within the ideal range and appropriate for a Bitcoin/Ordinals data server. Each tool covers a meaningful aspect without redundancy.
Completeness4/5
The tool set covers the core entities of the domain (sats, inscriptions, bitmaps, runes, blocks, fees), but lacks address-level or transaction-level lookups, which are common extensions for such a service. These gaps are minor and not severe.
Average 4.1/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool returns specific fields, indicating a read-only retrieval, but does not address error cases, authentication, or side effects. The 'look up' verb implies safety, though not explicitly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that lists the action and all relevant return values. No wasted words, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup tool with no output schema, the description covers the purpose and return fields sufficiently. It lacks explicit differentiation guidance from sibling tools, but the resource-specific wording makes the tool's role clear within the family.
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?
The input schema fully documents the single 'id' parameter with format details. The description simply says 'by id' and adds no additional semantic meaning beyond the schema, so it stays 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Look up' and clearly identifies the resource 'Ordinals inscription' by id, listing the returned fields (content type, owner address, sat, genesis height, current location, content URL). This distinguishes it from sibling tools like get_bitmap or get_fees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for looking up inscription details by id, but provides no explicit when-to-use or alternative references. It doesn't mention when not to use this tool or suggest other tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses the core ownership rule, 'a district N is owned by the first valid '<N>.bitmap' inscription', which informs the agent of the deterministic resolution. It does not mention edge cases like unresolved districts or that it is a read-only operation, but the verb 'resolve' suggests a safe lookup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the main purpose, then the ownership rule. Every sentence adds value with no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description states the return items (inscription id, owner address, sat) and explains how the district is claimed. It lacks details on behavior for unclaimed districts, but for a simple lookup tool with a single parameter, this is sufficient.
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?
The schema covers the parameter fully, describing district as a Bitcoin block height and enforcing a minimum of 0. The description adds a concrete example ('0 for the '0.bitmap' district') and links the parameter to the resolution rule, but no substantial new semantics beyond the schema.
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 description uses the specific verb 'Resolve' and identifies the resource as 'a Bitmap district number (a Bitcoin block height)' and the output as 'claiming inscription id, owner address, and sat'. This clearly distinguishes it from sibling tools like resolve_sat or get_inscription, which address different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to resolve a Bitmap district to its ownership info, use this tool. However, it does not explicitly mention when not to use it or mention alternative tools, so it falls short of explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Look up' implies a read-only operation, but the description does not disclose error behavior, not-found handling, or permission requirements. For a simple lookup, this level of transparency is minimal but acceptable; it neither misleads nor enriches.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that begins with the action ('Look up a Rune by name') and efficiently lists the return data. No redundant words, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter lookup with no output schema and no annotations, the description covers the essential context: the input format flexibility and the specific output fields. It doesn't address error scenarios, but for a simple read tool with strong schema coverage, this is sufficiently complete.
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?
The input schema already provides 100% coverage for the 'name' parameter, including an explicit explanation and examples. The description merely reiterates the 'with or without bullet separators' detail, adding no new semantic meaning beyond the schema. Baseline 3 applies because the schema does the heavy lifting.
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 description clearly states the tool's purpose: 'Look up a Rune by name' and lists specific return data (supply, divisibility, holder count, mint status, market data). This specific verb-resource pairing distinguishes it from sibling tools like get_bitmap, get_inscription, and get_block.
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?
The context is clear: this tool is for looking up Rune by name, as opposed to other sibling lookups for sats, bitmaps, inscriptions, fees, or blocks. It doesn't explicitly state when not to use it or name alternatives, but the resource-specific wording and sibling names make the appropriate use case evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It discloses the conditional 'if inscribed' behavior and specifies the return fields, which is valuable for a read-only lookup. However, it does not explicitly state error handling or that the operation is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the input and output. Every word earns its place, and there is no extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description lists the expected return fields, which gives sufficient context. It could include an example or field names, but given the low complexity, it is largely complete.
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 coverage is 100% for the single parameter 'sat', so the baseline is 3. The description repeats the input meaning and adds output context, but the schema already documents the same information. No additional syntax or constraints are provided.
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 description uses a specific verb 'resolve' with the resource 'sat' and clearly enumerates the exact outputs: Rodarmor rarity, mint block, and current inscription/owner if inscribed. This distinguishes it from sibling tools like get_block or get_inscription by focusing on sat ordinal properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies what the tool does but stops short of explicitly stating when to use it over alternatives. It does not mention sibling tools or provide exclusions, though the intended use case is reasonably implied by the context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses what the summary includes and the special behavior when height is omitted. It does not mention error handling or explicitly confirm read-only semantics, but the read-only nature is strongly implied by 'summary' and the listed fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and immediately lists the output fields and the key behavioral nuance. There is no wasted wording.
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?
The tool has no output schema, but the description enumerates the return fields, making the output explicit. It also explains the only behavioral nuance (chain tip when height omitted). For a simple one-parameter read tool, this is fully complete.
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?
The schema already provides 100% coverage of the single parameter 'height' with a clear description. The tool description repeats the omit-for-tip behavior but adds no new semantic detail beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('a Bitcoin block') with a clear scope ('summary') listing the fields (hash, timestamp, transaction count, size, weight, difficulty). This clearly distinguishes get_block from sibling tools that address other Bitcoin entities (sat, bitmap, inscription, rune, fees).
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?
The description provides clear usage context: it summarizes a Bitcoin block and explains the omit-height behavior for the current chain tip. However, it does not explicitly mention alternatives or when not to use this tool, though sibling names make the distinction implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It accurately indicates a read-only operation ('Return') and specifies output categories, but does not mention authentication, rate limits, or potential side effects. For this simple getter, this is adequate and provides full disclosure of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with the action and resource, no wasted words. It is concise and well-structured.
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?
The description fully specifies the return values (sat/vB with five categories), which is sufficient for a zero-param tool with no output schema. It doesn't need to explain parameters or side effects, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (vacuously). The description correctly focuses on the output rather than parameters, so it provides no additional parameter semantics needed. This aligns with the baseline for a tool with no parameters.
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 description uses a specific verb ('Return') and identifies the exact resource ('Bitcoin transaction fee estimates') with units (sat/vB) and categories (fastest, half hour, hour, economy, minimum). This clearly distinguishes it from sibling tools that handle other Bitcoin data types like blocks, runes, or inscriptions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—if you need current fee estimates, use this tool—but it does not explicitly state when to use it versus alternatives or mention exclusions. Sibling tools are about different resources, so context is clear, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bitmap-mcp MCP server](https://glama.ai/mcp/servers/BitmapAsset/bitmap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/BitmapAsset/bitmap-mcp)

Score Badge

Copy to your README.md:

[![bitmap-mcp MCP server](https://glama.ai/mcp/servers/BitmapAsset/bitmap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/BitmapAsset/bitmap-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/BitmapAsset/bitmap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server