List runtime symbols and safely inspect Python API signatures without modifying the scene. Avoid trial-and-error calls by checking exact function signatures first.
List runtime symbols; inspect_md_api reads signatures safely without trial calls. Does not mutate the MD scene.
| Name | Required | Description | Default |
|---|---|---|---|
| module | Yes | ||
| contains | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It explicitly states that the tool does not mutate the MD scene, which is useful safety information for an agent. It does not discuss rate limits, return format, failure modes, or prerequisites, but for a listing operation the non-mutation guarantee is a meaningful baseline.
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 short and front-loaded with the primary purpose, 'List runtime symbols'. The second sentence adds relevant differentiation from inspect_md_api. It is efficient, though the mention of 'inspect_md_api reads signatures safely without trial calls' is slightly tangential to md_api itself and could be clearer.
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?
This is a simple two-parameter tool, but with no output schema and no annotations, the description must provide more operational context. It explains the high-level purpose and safety profile, but omits parameter semantics and any guidance on expected results or edge cases, leaving an agent under-equipped to invoke it 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 description coverage is 0% and the description gives no meaning to either parameter, 'module' or 'contains'. An agent cannot know what values to supply for module or how contains filters results. The description does nothing to compensate for the schema's lack of explanatory text.
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 starts with a specific action and object: 'List runtime symbols', which clearly identifies what the tool does. It also hints at the distinction from the sibling inspect_md_api, which 'reads signatures safely without trial calls', giving the agent some differentiation. However, it does not define what 'runtime symbols' includes or what the output looks like, so it stops short of full clarity.
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 description indirectly contrasts md_api with inspect_md_api: one lists symbols, the other reads signatures. This implies a usage split but does not explicitly state when to use md_api versus alternatives, nor does it mention any conditions or exclusions. The safety note 'Does not mutate the MD scene' offers some context but not concrete selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.