Retrieve radare2 configuration values by key or all settings, optionally for a specific analysis session, to inspect and verify reverse-engineering parameters.
Get configuration value(s) (e).
| Name | Required | Description | Default |
|---|---|---|---|
| key | No | ||
| session_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden, yet it discloses almost nothing: not whether key=null returns all values, not the behavior when session_id is omitted, not whether this is read-only or what the return shape is. "Get" weakly implies a read, which is the only behavioral signal present.
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?
It is short, but shortness here reflects under-specification rather than conciseness. The cryptic "(e)" token wastes one of the few words available and should have been replaced with substantive guidance.
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?
No output schema, no annotations, and zero schema description coverage means the description is the only information channel, and it supplies essentially none. For a config-access tool with two optional parameters, an agent cannot determine semantics such as null-key behavior or session scoping.
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 description coverage is 0% for both key and session_id, and the description adds nothing about either — no format, no default behavior, no key naming conventions. With zero compensation for an undocumented parameter set, this is a clear gap.
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?
"Get configuration value(s) (e)" largely restates the tool name get_config and offers no scope, resource context, or distinguishing detail. The trailing "(e)" is unexplained noise. An agent cannot tell from this text what configuration domain it reads (session config? binary config?) or how it differs from siblings like get_binary_info or list_functions.
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?
There is no statement of when to use this tool, no preconditions (e.g. a session must exist), and no reference to the obvious counterpart set_config or to session-scoped alternatives. The agent is left to infer everything from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.