Skip to main content
Glama

BlockRazor Docs

by io.blockrazor
OverviewDiscussionsAdmin

Server Details

Official BlockRazor documentation for sending and receiving transations faster.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Last Tested
Transport
Streamable HTTP · MCP 2025-06-18
URL

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: askQuestion answers natural-language questions, searchDocumentation finds pages by keyword, getPage retrieves full page content, and sendFeedback reports doc issues. There is no meaningful overlap between them.

Naming Consistency5/5

All tool names follow a consistent camelCase verb-first pattern: askQuestion, getPage, searchDocumentation, sendFeedback. The verbs (ask, get, search, send) are distinct and align with each tool's action.

Tool Count5/5

Four tools is well-scoped for a documentation server: two retrieval paths (search and direct answer), one page fetcher, and one feedback mechanism. Each tool earns its place without redundancy.

Completeness5/5

The set covers the full documentation workflow: discovering relevant pages (searchDocumentation), reading full content (getPage), getting synthesized answers (askQuestion), and reporting problems (sendFeedback). There are no obvious gaps for the stated purpose.

Available Tools

4 tools
askQuestionA
Read-only
Inspect

Ask a natural-language question about BlockRazor and get a synthesized answer, with links to the source pages. Prefer this over searchDocumentation when you want a direct answer to a question rather than a list of matching pages; use searchDocumentation/getPage when you need to browse or read full pages yourself.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalNoThe broader end goal you are ultimately trying to accomplish (as/on behalf of the user). Used to tailor the answer to be most useful for your goal. Optional.
questionYesThe natural-language question to answer about BlockRazor.

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already cover read-only and open-world hints. Description adds that answers are synthesized with source links and can be tailored via 'goal' parameter, but doesn't detail other behavioral traits like latency or error handling.

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 efficient sentences: first states core functionality, second gives usage guidance. No unnecessary words, well 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 tool with two parameters and no output schema, the description adequately explains the return format (synthesized answer with links) and the role of the optional 'goal' parameter. Missing details on edge cases but still complete for typical use.

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?

Schema already describes both parameters well (100% coverage). Description adds context that 'goal' tailors the answer, which goes beyond the schema description.

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?

Clear verb ('ask'), resource ('BlockRazor'), and outcome ('synthesized answer with links'). Explicitly distinguishes from sibling 'searchDocumentation'.

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

Usage Guidelines5/5

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

States when to prefer this tool (direct answers) versus alternatives ('searchDocumentation'/'getPage' for browsing). Provides clear guidance on usage context.

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

getPageA
Read-onlyIdempotent
Inspect

Fetch the full markdown content of a specific documentation page from BlockRazor. Use this when you have a page URL and want to read its content. Accepts full URLs (e.g. https://docs.blockrazor.io//getting-started). Since searchDocumentation returns partial content, use getPage to retrieve the complete page when you need more details. The content includes links you can follow to navigate to related pages.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesThe URL of the page to fetch

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. Description adds that it fetches markdown content, accepts full URLs, and includes navigable links. No contradictions. Adds useful behavioral context 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.

Conciseness5/5

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

Three sentences: front-loaded with purpose, then usage and input format, then sibling contrast and navigation feature. No redundant words.

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?

Given low complexity (1 param, good schema, annotations), description sufficiently explains what it returns, when to use it, and how it relates to siblings. No missing critical information.

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?

Schema description for url parameter is present (100% coverage). Description adds example URL format and clarifies it accepts full URLs, adding meaning beyond 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?

Description clearly states verb (Fetch), resource (full markdown content of a specific documentation page), and context (BlockRazor). It distinguishes from sibling searchDocumentation by mentioning partial vs. full content.

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

Usage Guidelines5/5

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

Explicitly says 'Use this when you have a page URL and want to read its content.' Also contrasts with searchDocumentation: 'use getPage to retrieve the complete page when you need more details.' Provides clear when-to-use and alternative.

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

searchDocumentationA
Read-onlyIdempotent
Inspect

Search across the documentation to find relevant information, code examples, API references, and guides. Use this tool when you need to answer questions about BlockRazor, find specific documentation, understand how features work, or locate implementation details. The search returns contextual content with titles and direct links to the documentation pages.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already mark the tool as read-only, open-world, and idempotent. The description adds that the search returns contextual content with titles and direct links, giving the agent insight into the response format. No contradictions with annotations.

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?

Three concise sentences, front-loaded with the action, followed by usage guidance, then output description. No unnecessary words; each sentence adds value.

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?

Given only one parameter and no output schema, the description adequately covers the return type (titles and links) and the scope (BlockRazor documentation). Could mention limitations like result count, but overall sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

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

The only parameter 'query' is a string with no description in the schema (0% coverage). The description adds no additional meaning about the query parameter, such as format or expected input. With low schema coverage, the description should compensate but does not.

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

Purpose4/5

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

The description clearly states the tool searches documentation for various content types (code examples, API references, guides). It specifies the resource (documentation) and action (search). While it distinguishes itself from siblings by being a search tool, it does not explicitly contrast with siblings like askQuestion or getPage.

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 explicitly lists when to use: to answer questions about BlockRazor, find specific documentation, understand features, or locate implementation details. It provides clear context for use but does not mention when not to use or suggest alternatives.

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

sendFeedbackAInspect

Report an issue in the documentation of BlockRazor so the team can fix it. Use it whenever, while helping a user, you come across content that is outdated, contradictory, missing information, or otherwise unhelpful. Also use it when the user themselves reports a problem with the docs, even if you could not verify it yourself. If it's your own observation, do a quick sanity check that the issue is real before reporting — no need to exhaustively re-read the page. Send one call per distinct issue and do not report the same issue twice in a conversation. Do not use this tool to confirm that a page is accurate; it is for reporting problems only.

ParametersJSON Schema
NameRequiredDescriptionDefault
goalNoThe broader end goal you were ultimately trying to accomplish (as/on behalf of the user) when you hit this issue. Gives the team the context you were working towards. Optional.
contentYesExplain the issue in full, as if writing to a documentation maintainer who never saw this conversation. Describe what is wrong, where on the page it appears (quote the exact sentence or section title when possible), what the user was trying to do, and, when relevant, what the correct or expected information should be. Write a few clear, specific sentences in English. Never include personal or confidential information from the conversation. Up to 2048 characters.
pageUrlYesThe full URL of the page the issue is about (e.g. https://docs.blockrazor.io//getting-started), so the finding is linked to the exact page.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already indicate this is not read-only, not idempotent, and not destructive. The description adds useful behavioral constraints beyond that: one call per distinct issue, no duplicate reports, and a sanity check for personal observations. It does not detail submission or response behavior, but that is a minor omission for a feedback tool.

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 front-loaded with purpose, and every sentence earns its place: conditions, verification expectations, deduplication rule, and an explicit non-use case. There is no fluff or redundancy.

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?

For a three-parameter feedback tool with fully documented schema, the description covers when to use it, when not to, how to batch issues, and how to handle unverified user reports. No output schema is present, and nothing needed for correct invocation 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%, and the schema already explains content, pageUrl, and goal in detail, including length limits and examples. The description reinforces the reporting semantics but adds no parameter-level details beyond the schema, so 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 description opens with a specific verb and resource: 'Report an issue in the documentation of BlockRazor'. This clearly distinguishes it from sibling tools like askQuestion, getPage, and searchDocumentation, which retrieve or ask rather than report.

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

Usage Guidelines5/5

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

It gives explicit triggers: use when encountering outdated, contradictory, or missing docs, or when the user reports a problem even if unverified. It also gives exclusions: do not use to confirm a page is accurate, send one call per issue, and avoid reporting the same issue twice.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • ChangedsendFeedback1 field changed
      • addedInput schema / properties / goal / maxLength
        Added value: +1024
  2. 1 tool update
    • ChangedsendFeedback4 fields changed
      • removedInput schema / properties / category
        Removed value: -{
-  "description": "The kind of issue. \"content-outdated\": the content was correct at some point but no longer matches the current product or reality. \"incoherence\": the content contradicts itself or another page. \"content-gap\": information the reader needs is missing entirely, whether or not it was ever documented. \"other\": only as a last resort when none of the above fits.",
-  "enum": [
-    "content-outdated",
-    "content-incorrect",
-    "content-gap",
-    "other"
-  ],
-  "type": "string"
-}
      • addedInput schema / properties / goal
        Added value: +{
+  "description": "The broader end goal you were ultimately trying to accomplish (as/on behalf of the user) when you hit this issue. Gives the team the context you were working towards. Optional.",
+  "type": "string"
+}
      • changedInput schema / properties / pageUrl / description
        Previous value: -"The full URL of the page the issue is about (e.g. https://docs.blockrazor.io//getting-started). Provide it whenever you can so the finding is linked to the exact page."New value: +"The full URL of the page the issue is about (e.g. https://docs.blockrazor.io//getting-started), so the finding is linked to the exact page."
      • changedInput schema / required
        Previous value: -[
-  "category",
-  "content"
-]New value: +[
+  "content",
+  "pageUrl"
+]
  3. 4 tool updates
    • First observedaskQuestion
    • First observedgetPage
    • First observedsearchDocumentation
    • First observedsendFeedback

Related MCP Connectors

Related MCP Servers

  • Blockchain Payment MCP Server

    logos-42
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables blockchain payment operations across multiple networks including Base, Ethereum, BSC, Polygon, and Avalanche. Supports balance queries, token transfers, transaction tracking, wallet management, and gas fee estimation with built-in security limits.
    MIT
  • Tatum MCP Server by tatumio

    Tatum MCP Serverofficial

    tatumio
    A
    license
    B
    quality
    C
    maintenance
    Provides access to Tatum's blockchain API across 40+ networks, enabling developers to interact with blockchain data, manage notifications, estimate fees, access RPC nodes, and work with smart contracts through natural language.
    31
    41 npm
    15
    MIT
Try in Browser
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