Find columns across a PowerDesigner model or a specific table by matching substring in column code or name. Returns table and column details for targeted schema inspection.
Search columns across the whole model (or one table) by substring in code/name. Returns table_code + column detail rows.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| query | Yes | ||
| model_id | Yes | ||
| page_size | No | ||
| table_ref | 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, the description carries the full burden. It discloses the return shape (table_code + column detail rows) and the search semantics (substring match). It does not mention pagination behavior, case sensitivity, or that it is a read-only operation, though these are likely inferred. It adds some value but could be richer given no annotation support.
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 concise sentences with no fluff. The main action is front-loaded, and the return format is stated. Every word adds value, making it efficient for an agent to parse quickly.
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?
For a 5-parameter tool with no output schema and no annotations, the description is underspecified. It does not explain the meaning of 'model_id', pagination parameters, or behavior on empty results. An agent would likely need to infer these from the schema or probe the tool, which reduces completeness.
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 0%, so the description must compensate. It explains 'query' via 'substring in code/name' and 'table_ref' via 'whole model (or one table)', but it does not clarify 'model_id' (which model to search), 'page', or 'page_size' (pagination). These are left entirely to the schema, which has minimal titles. The description covers only a fraction of the parameters.
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 action (search), the target resource (columns), the scope (whole model or one table), and the matching criteria (substring in code/name). It also specifies the return format (table_code + column detail rows), which distinguishes it from siblings like search_tables (which searches tables) and list_columns (which lists all columns without a search filter).
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 implies usage context: searching columns by substring across a model or a specific table. However, it does not explicitly state when to prefer this over list_columns or get_column, nor does it mention exclusions (e.g., 'if you need exact column details without search, use get_column'). The 'whole model or one table' phrasing gives some guidance but lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.