select_databaseSet the default IDA Pro instance for subsequent MCP calls. Provide an instance ID or omit it to auto-select the active database.
Choose the default IDA instance for subsequent calls. Returns {selected_instance_id} or {error}.
| Name | Required | Description | Default |
|---|---|---|---|
| instance_id | No | Instance id from list_databases; omit to auto-select |
Changes observed during successful MCP inspections.
v0.9.7Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the return shape ({selected_instance_id} or {error}) but omits important traits such as persistence scope, authentication/prerequisite requirements, behavior on invalid instance IDs, and side effects beyond selection.
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?
Two sentences, front-loaded with the core action and then the return contract. No filler, and the return information is useful because there is no output schema.
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?
The description covers purpose and return values, which is enough for basic invocation. However, for a stateful selection tool with no annotations and no output schema, it leaves gaps around prerequisites, persistence, and how selection interacts with other database tools.
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 100%, and the single parameter is fully documented in the schema as coming from list_databases with auto-select when omitted. The description adds no further parameter meaning, so the baseline of 3 applies.
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 states a specific verb and resource: choosing the default IDA instance, and adds the effect on subsequent calls. It does not explicitly differentiate this from sibling tools like list_databases or open_database, so a 4 is appropriate.
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?
The phrase 'for subsequent calls' implies when the tool should be used, but there is no explicit comparison to alternatives such as list_databases or open_database, nor any when-not guidance. Usage context is therefore present but left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.