rizin-mcp

by kd992102

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose: opening/analyzing, capa analysis, listing functions, decompiling, disassembling, binary info, string search, xrefs, raw command execution, and closing. The only potentially overlapping tool is execute_rizin_command, but it is explicitly a high-privilege escape hatch, not a competitor to the purpose-built tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case: open_and_analyze, run_capa_analysis, list_functions, decompile_function, disassemble_function, get_binary_info, search_strings, get_xrefs, execute_rizin_command, close_file. The naming is uniform and predictable.
Tool Count5/5
10 tools are well-scoped for a binary analysis server. Each tool covers a distinct operation without redundancy, and the count feels appropriate for the domain.
Completeness5/5
The tool set covers the full binary analysis lifecycle: open/analyze, inspect (info, strings, functions), analyze (decompile, disassemble, xrefs), advanced analysis (capa), raw command access for any gap, and close. No critical operations are missing for the stated purpose.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 22 commits in the last 12 weeks
- Last stable release on August 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It only states the action without mentioning prerequisites (e.g., a loaded binary), error behavior, or side effects, leaving important operational details unspecified.
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?
The description is a single front-loaded sentence, easily parsed. The redundant phrase 'assembly disassembly' is minor but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered. However, the description omits context such as whether a prior open_and_analyze is required and what constitutes a valid address/name, leaving the agent with gaps in invocation context.
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 single parameter address_or_name is restated in the description as 'specified function/address', but no additional format or example is given. The property name already conveys the same information, so the description adds minimal value.
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 retrieves assembly disassembly for a given function/address, distinguishing it from decompile_function which returns high-level code and other analysis tools.
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 inspecting low-level assembly but does not explicitly state when to prefer it over decompile_function or how it fits into the analysis workflow. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only mentions 'open and automatically analyze' without detailing side effects, such as whether the file remains open, what analysis entails (e.g., running 'aaa'), or potential errors. This is minimal insight into 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?
The description consists of two concise, front-loaded sentences with no filler. Every word adds value, establishing the action, the resource, and the critical prerequisite rule.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which relieves the need to describe return values), the description is incomplete for a tool with a mandatory prerequisite role. It does not clarify what 'automatically analyze' means, how the analyze_level parameter impacts behavior, or whether the file remains open for subsequent operations. The agent is left missing key context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain either parameter. It fails to mention 'file_path' or 'analyze_level', and the 'automatically analyze' phrasing offers no clue about the analysis level default 'aaa'. The description falls far short of compensating for the lack of parameter documentation.
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 a specific action and resource: 'Open and automatically analyze a binary file.' It also distinguishes itself from sibling tools by establishing it as a prerequisite, noting it 'must be called before performing any decompilation, disassembly, or queries on the file.'
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?
The description provides explicit usage guidance: 'This tool must be called before performing any decompilation, disassembly, or queries on the file.' This clearly tells the agent when to use it, establishing it as the mandatory first step in the workflow.
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, the description carries the burden of disclosing behavior. It mentions searching and filtering, which implies a read-only operation, but does not explicitly state that the file is not modified, how results are returned, or details like case sensitivity. This is minimal but not misleading.
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 consists of two concise sentences, each adding relevant information: the core search capability and the filtering option. There is no fluff, and the structure 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 simple tool with one parameter and an existing output schema, the description adequately covers the core functionality and filtering. It omits finer behavioral details such as output format or search scope, but the output schema likely handles return values, making the description 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 schema provides only a 'query' property with no description, and schema coverage is 0%. The description compensates by explaining that query is used for filtering, which adds meaning beyond the schema. However, it lacks specifics like matching rules or the behavior of an empty query, so compensation is partial.
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 function: searching for readable strings in the binary file. This distinguishes it from sibling tools like list_functions or decompile_function, which operate on different aspects of binary analysis.
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 one needs to find strings in a binary, but does not explicitly state when to prefer this tool over alternatives or exclude other tools. No context is given about when not to use it, leaving the agent to infer.
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?
The description mentions disk caching and returning cached results, which is useful. However, the sentence 'It fully analyzes all functions until completion' is ambiguous—it likely refers to open_and_analyze, not run_capa_analysis, causing potential confusion about which tool performs the analysis. No annotations are present, so the description carries the responsibility but does not clearly separate dependency behavior from the tool's own behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains a run-on sentence with an ambiguous pronoun reference ('It'), which affects structural clarity. It could be tighter and more direct in separating the tool's role from its dependency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained. The description covers the key prerequisite and caching behavior, but the ambiguity about which tool performs analysis and the lack of explicit parameter guidance leave some gaps. Overall, it is adequate but not fully complete for a tool with a dependency.
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 0%, and the description never mentions the 'force_reanalysis' parameter. However, the single boolean parameter's name is self-explanatory, and the mention of cached results implies a reanalysis flag is available. The description provides indirect meaning but does not explicitly connect it to the parameter.
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 matches capa-rules and identifies malicious capabilities using a pre-analyzed Rizin Session. This is specific and unique among siblings, which are general file analysis tools.
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 explicitly states 'open_and_analyze must be called first', providing a clear prerequisite and dependency. This gives strong guidance on when to use the tool.
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?
No annotations are provided, so the description carries the burden. It adds the context that the tool operates on the 'current binary file', implying a read-only get operation. However, it does not disclose potential side effects, prerequisites, or response behavior beyond the content list.
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 that is front-loaded with the verb and resource, and efficiently lists examples. No wasted words.
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 the tool is a simple read-only info retrieval with an output schema present, the description is mostly complete. It names the architectural components covered and implies a dependency on an opened binary file. It could explicitly state that a file must be opened first (e.g., via open_and_analyze), but 'current binary file' sufficiently implies this.
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?
The tool has 0 parameters and schema coverage is 100%, so the baseline is 4. The description adds no parameter-specific meaning, but it implicitly clarifies that the input is the already-loaded binary file, not a function argument, which is useful context.
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 function: to 'Get detailed architectural information of the current binary file'. It lists concrete content types (Headers, Sections, Imports, Exports) which differentiates it from siblings like list_functions or decompile_function that focus on specific aspects.
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 this is for retrieving high-level architectural details, but it does not explicitly state when to use it versus alternatives (e.g., list_functions for functions only) or provide exclusions. The context 'current binary file' suggests it should be used after opening a file, but this is not made explicit.
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?
The '[High Privilege Tool]' prefix is a meaningful behavioral warning, and the description conveys raw command execution. However, with no annotations, it lacks details about potential side effects, state changes, or security implications beyond the privilege flag.
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?
A single, front-loaded sentence that includes a warning, a clear verb-object phrase, and examples. Every element adds value without redundancy.
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 one parameter and an output schema, the description is nearly complete. The main gap is not stating that the command operates on the currently open analysis file, though sibling context implies it.
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 coverage is 0%, so the description must compensate. It provides concrete examples of valid commands, effectively illustrating the format of the 'command' parameter, which is the sole parameter.
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 executes custom Rizin commands with specific examples, and it distinguishes itself from specialized sibling tools like list_functions or disassemble_function by serving as a general-purpose command executor.
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 indicates this tool is for direct Rizin command execution, implying use when specialized tools don't cover a need. However, it does not explicitly mention when not to use it or name alternatives.
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 full transparency burden. It discloses the return format (a list of dictionaries) and the two input modes (address/name or global query). It does not mention error behavior or side effects, but for a read-only analysis tool this is adequate.
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 two concise sentences that front-load the purpose and then provide input modes and a concrete output example. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and schema descriptions, the description covers core invocation details (input modes) and the expected return shape. It could be more complete by listing xref_type options, but the defaults and example reduce ambiguity enough for an agent to select and call the tool.
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 has no parameter descriptions (0% coverage), so the description must compensate. It explains address_or_name and hints at xref_type via the CALL example, but it does not explain the 'limit' parameter or enumerate possible xref_type values. This leaves a notable gap.
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: 'Find and analyze cross-references (Xrefs) and call dependencies for a specified function or address.' This specific verb-resource pairing distinguishes it from sibling tools such as decompile_function and list_functions.
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 context by specifying it works for a function or address, and it mentions support for a global query. However, it does not explicitly contrast with alternative tools or state when not to use it, so it misses the highest bar.
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?
No annotations are provided, so the description carries the full burden. It discloses the output type (C pseudocode) and accepted inputs, but it does not mention prerequisites such as the file being open or analyzed, potential failure cases, or whether 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, well-structured sentence that leads with the main verb, specifies the tool, and includes relevant examples. No unnecessary content.
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 tool with an output schema present, the description is nearly complete. A minor gap is the lack of explicit note about needing an open/analyzed binary, but the sibling list provides some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter with 0% coverage, but the description fully compensates by providing concrete examples and clarifying that both addresses and function names are accepted. This is exactly what an agent needs to correctly populate the parameter.
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 decompiles a specified memory address or function name into C pseudocode using Ghidra. The verb 'decompile' and the resource distinction set it apart from sibling tools like disassemble_function and list_functions.
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 gives explicit input formats and examples (0x140001000, fcn.140001000, main), making it clear how to invoke the tool. It does not explicitly mention when not to use it or name alternatives like disassemble_function, but the context is clear enough.
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?
No annotations are provided, so the description carries the full burden. It discloses that the tool lists functions and supports filtering, but it does not explicitly state that it is a read-only operation or describe any edge cases (e.g., sorting, ordering, or handling of special function names). For a simple listing tool, this is adequate but not rich.
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 two sentences long, front-loaded with the primary action, and contains no fluff. Every word contributes to understanding the tool's purpose and main parameter.
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 simple listing tool with one optional parameter and an output schema, the description is complete. It covers the core functionality, the current-file scope, and the filtering option. The return values are presumably documented in the output schema, so no additional explanation is needed.
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?
The schema provides only a type and default for filter_keyword, with 0% description coverage. The description adds meaningful semantics by explaining the keyword filters by function name or address. This goes beyond the schema's basic type information, though it leaves open details like matching semantics (substring, exact) or address format.
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 function: 'List all functions identified in the current file.' This is a specific verb+resource construction that distinguishes it from siblings like decompile_function or disassemble_function. The filtering capability is also mentioned, further clarifying its purpose.
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 context for when to use the tool—when you need to enumerate functions in the current file—and mentions the optional filtering feature. It does not explicitly name alternatives or exclusions, but the scope ('current file') and filtering behavior imply the intended use case without ambiguity.
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 behavioral burden. It explicitly states that both the binary file and the Rizin Session are closed, which is key side-effect information. It does not mention reversibility or saved state, but 'Close' and session termination are clear enough for this simple operation.
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, concise sentence that is front-loaded with the action 'Close' and immediately specifies the target. Every word contributes meaning.
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 zero-parameter close tool, the description fully covers the operation. It names exactly what is closed, and since an output schema exists, return value details are not required.
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?
The schema shows zero parameters, so there is nothing to document. The baseline of 4 applies because no parameter information is needed.
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 'Close' with the resource 'currently opened binary file and Rizin Session,' clearly distinguishing it from sibling tools like open_and_analyze. It precisely names the action and scope.
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 phrase 'currently opened' provides clear context that this tool should be used after a file is opened, and it implies cleanup or session termination. It does not explicitly name alternatives or exclusions, but for a 0-parameter close operation this is sufficient.
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:

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

Score Badge

Copy to your README.md:

[![rizin-mcp MCP server](https://glama.ai/mcp/servers/kd992102/rizin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/kd992102/rizin-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/kd992102/rizin-mcp'

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