arcgis_pro_table_selection_fidsRetrieve the ordered OIDs of a standalone table's current selection set, with a limit and truncation flag to keep results bounded.
返回独立表当前选择集的有序 OID，带上限和截断标志。
| Name | Required | Description | Default |
|---|---|---|---|
| map_name | Yes | ||
| aprx_path | Yes | ||
| max_items | No | ||
| table_name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description's main added value is the mention of an upper limit and a truncation flag – real behavioral context absent from the annotations. However it does not explain the default max_items=1000 or what the truncation flag implies for the caller, leaving the disclosure thin.
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?
A single front-loaded sentence naming the return content, its ordering, and the limiting behavior. No waste, though it is terse to the point of under-specification for a 4-parameter tool.
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?
An output schema exists, so the return shape need not be restated, and the description correctly summarizes what comes back. The gap is input-side: three required path/name parameters are undocumented anywhere, which is a meaningful shortfall for a tool that must be called with exact aprx, map and table identifiers.
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 there are 4 parameters, so the description carries the full burden. It only gestures at max_items via '上限' and the truncation flag; the three required parameters (aprx_path, map_name, table_name) and their expected formats are entirely undocumented in both schema and description.
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?
States a specific verb and resource ('返回独立表当前选择集的有序 OID' – returns ordered OIDs of the current selection set of a standalone table). The qualifier '独立表' implicitly separates it from the layer-oriented sibling arcgis_pro_layer_selection_fids, though no sibling is named explicitly.
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?
No when-to-use guidance at all. It does not say when to prefer this over arcgis_pro_table_selection_count or arcgis_pro_select_table_by_attribute, nor what prerequisites (an existing selection, an open project) must hold.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.