BlockRazor Docs
Server Details
Official BlockRazor documentation for sending and receiving transations faster.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.4/5 across 4 of 4 tools scored.
Each tool serves a distinct purpose: askQuestion for synthesized answers, searchDocumentation for search results, getPage for full page content, and sendFeedback for reporting issues. No overlap in functionality.
All tool names follow a consistent verbNoun camelCase pattern (askQuestion, getPage, searchDocumentation, sendFeedback), making them predictable and easy to understand.
Four tools is appropriate for a documentation server, covering the essential operations of searching, asking, reading pages, and providing feedback without unnecessary complexity.
The tool set covers the primary documentation tasks (search, ask, read, provide feedback). Minor gaps include lack of a tool to list all pages or categories, but navigation via links in search results mitigates this.
Available Tools
4 toolsaskQuestionARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | The 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. | |
| question | Yes | The natural-language question to answer about BlockRazor. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is clear. The description adds behavioral detail: the answer is synthesized and includes links to source pages. Could mention latency or knowledge freshness but not required given openWorldHint.
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?
One concise paragraph that front-loads the main purpose and then provides usage guidelines. Every sentence adds value with no wasted words.
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 simple tool with two well-described parameters, no output schema, and strong annotations, the description fully covers what the tool does, when to use it, and the nature of the output (synthesized answer with links). No significant gaps.
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?
Both parameters are fully described in the input schema (100% coverage). The tool description does not add extra meaning beyond what is already in the schema, 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 states the verb 'ask' and resource 'BlockRazor' to get a synthesized answer with links. It differentiates itself from sibling tools by explaining when to prefer it over searchDocumentation and getPage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use this tool ('when you want a direct answer') and when to use alternatives ('use searchDocumentation/getPage when you need to browse or read full pages yourself'). Also implies not for feedback (sendFeedback sibling).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
getPageARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The URL of the page to fetch |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint. Description adds minor context about URL format and content including links, but does not add significant new behavioral traits.
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 concise sentences, front-loaded with purpose, no redundant information. Every sentence adds value.
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's simplicity (one parameter, good annotations, no output schema needed), the description covers purpose, usage, URL format, and relationship to sibling tools completely.
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 has 100% description coverage. Description adds an example URL format (https://docs.blockrazor.io//getting-started) that clarifies the expected input beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (Fetch), resource (full markdown content of a specific documentation page), and distinguishes from sibling searchDocumentation by noting it returns partial content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (when you have a page URL and want full content) and when not (use searchDocumentation for partial content). Provides alternative and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchDocumentationARead-onlyIdempotentInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld. Description adds return format (contextual content with titles and links), enhancing transparency 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 concise sentences, no fluff. Front-loaded with purpose, well-structured.
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?
Adequately covers purpose, usage, and returns given simple tool. Minor gap: no mention of result limits or explicit alternative tool usage.
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 has 0% description coverage. The description indirectly explains the query parameter ('search across documentation') but lacks specifics on format, length, or examples.
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 'search across the documentation' and lists specific content types (code examples, API references, guides). It distinguishes from siblings like askQuestion and getPage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (answer questions, find specific docs, understand features). Lacks explicit guidance on when not to use or direct alternatives, though siblings are named.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Explain 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. | |
| pageUrl | No | 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. | |
| category | Yes | 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=false and destructiveHint=false, which is consistent. Description adds behavioral context: it's a write operation to a feedback system, and it warns against reporting the same issue twice (non-idempotent behavior). Adds the privacy concern (no personal info). This 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 front-loaded with purpose and then usage rules. While it is a bit lengthy (several sentences), every sentence adds value. Could be slightly tighter but overall well-structured for the complexity.
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 and simple parameters, the description is exceptionally thorough: it covers purpose, when/why to use, behavior rules, privacy, and even a sanity check. It is complete for an agent to use 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% with detailed descriptions for all three parameters (content, pageUrl, category). The description does not add significant param-specific detail beyond the schema, 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 states the tool is for reporting issues in BlockRazor documentation, with specific examples of issue types (outdated, contradictory, missing). It distinguishes from sibling tools like askQuestion and searchDocumentation by being exclusively for feedback.
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?
Provides explicit guidance on when to use (when encountering doc issues or user reports), when not to use (not for confirming accuracy), and how to use (one call per issue, no duplicates, sanity check for own observations). Includes exclusionary language and alternatives implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!