Server Quality Checklist

Tool Scores

• describe_gp_toolB
  3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool retrieves documentation, implying a read-only operation, but does not explicitly confirm safety, non-destructiveness, or any side effects. Important traits like authentication needs or rate limits are omitted.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, focused sentence with no superfluous words. It directly conveys the tool's purpose without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given that an output schema exists, the description is not required to detail return values. However, the description is minimal and does not explain the scope of 'full documentation' or how the output is structured. It is adequate but could be more complete, especially given the single required parameter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters1/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There is one required parameter ('tool') with 0% schema description coverage. The description does not explain what the parameter represents (e.g., tool name) or provide any value constraints. This leaves the agent with no semantic guidance for populating the parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool retrieves syntax and full documentation for a geoprocessing tool. It uses a specific verb ('Get') and resource ('syntax and full documentation'), and it distinguishes itself from sibling tools like 'run_gp_tool' (execution) and 'search_gp_tools' (searching).

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when-not-to-use scenarios, or contrast with sibling tools like 'run_gp_tool' or 'search_gp_tools'. Usage context is only implied.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• inspect_projectB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, so the description must disclose behavioral traits. It describes what the tool inspects but does not state that it is read-only, whether it requires specific permissions, or any side effects. The description is incomplete for a tool with 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One sentence that is front-loaded with the verb and resource. It efficiently summarizes the tool's purpose without extraneous words. Highly concise.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple input (one path parameter) and existence of an output schema, the description is mostly adequate. However, it lacks usage guidelines and any context on when to choose this tool over siblings, which reduces completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description adds value by specifying that path should point to an .aprx file. However, it does not explain other constraints like format, required extension, or absolute vs relative path, leaving gaps.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool inspects an ArcGIS Pro project (.aprx) and lists the components it covers (maps, layers, data sources, layouts, default geodatabase), making the purpose specific and distinct from sibling tools like describe_data or describe_gp_tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit guidance on when to use this tool versus alternatives. The description implies usage for inspecting a project but does not mention prerequisites, exclusions, or compare with similar tools like describe_data.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• list_workspaceB
  3.3/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided; description carries full burden. It describes the function as inventorying but does not disclose whether it is read-only, requires authentication, or has side effects. The term 'inventory' suggests read-only but is not explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Single sentence, no wasted words. Clearly communicates the tool's core function. However, it could be restructured to include parameter context or usage tips without adding length.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Tool is simple with one parameter and has an output schema, so description doesn't need to explain return values. However, it lacks usage guidelines and behavioral transparency. Acceptable for a basic tool but could be more informative.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so description must compensate. The description mentions 'workspace (geodatabase or folder)' which hints at the 'path' parameter meaning, but does not explain it directly or provide format/constraints. No additional value beyond schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states the verb 'inventory' and resource 'workspace (geodatabase or folder)', and lists the types of contents (feature classes, rasters, tables, datasets). It distinguishes from siblings like 'describe_data' by focusing on listing contents.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage for inventorying workspace contents but provides no explicit guidance on when to use this tool versus alternatives like 'describe_data' or 'inspect_project'. No when-not-to-use or prerequisites mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• describe_dataB
  3.4/5.0
  Behavior3/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden. It discloses that the tool produces a description (type, spatial reference, etc.) and works on many dataset types. However, it does not explicitly state that the tool is read-only, has no side effects, or mention performance implications. For a descriptive tool, this is minimally adequate but lacks depth.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description consists of two short sentences with no wasted words. It front-loads the key output attributes and then expands on supported input types. Very efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity and the existence of an output schema (which covers return structure), the description is largely complete. It explains what the tool does, what inputs it accepts, and what outputs are described. Minor gaps include error handling and behavior for unsupported types, but these are not critical for a basic descriptive tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters2/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, so the description must compensate. The tool description mentions that it works on various dataset types, indirectly clarifying the 'path' parameter as a dataset path. However, it does not explain valid formats, absolute vs relative paths, or provide examples. The parameter remains underdocumented.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Describe a dataset' and lists specific attributes (type, spatial reference, extent, fields, row count), making the tool's purpose unambiguous. It also specifies the input types (feature classes, shapefiles, rasters, etc.), distinguishing it from the sibling tool 'describe_gp_tool' which likely describes geoprocessing tools instead.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or scenarios where other tools (e.g., 'describe_gp_tool' or 'inspect_project') would be more appropriate. The agent is left to infer usage context.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• run_gp_toolA
  3.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations are provided, so the description must disclose behavioral traits. It mentions returning outputs and messages but does not state whether the tool can modify data, require permissions, or behave destructively. The timeout parameter is mentioned but not its implications.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three sentences, front-loaded with the main purpose, and every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers tool naming and parameter usage, and references describe_gp_tool for signature. However, given the complexity of running arbitrary geoprocessing tools, it lacks cautionary info about side effects, prerequisites, or failure behavior. The output schema exists but is not referenced.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description adds essential meaning: explains that tool accepts flat or module names, args for positional parameters, kwargs for named ones. However, it does not describe the timeout_seconds parameter beyond its existence.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states it runs a geoprocessing tool by name and returns outputs and messages, using specific verb+resource. It distinguishes from sibling describe_gp_tool by advising to use that first for signature uncertainty.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description advises to use describe_gp_tool if unsure of the signature, and explains naming conventions. It does not explicitly differentiate from sibling arcpy_execute or specify when not to use this tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• arcpy_executeA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  The description reveals key behaviors: code execution, persistent variables between calls, stdout capture, and return of the last expression's repr. It does not mention potential risks like destructive operations or error handling, but given the absence of annotations, it covers the core behavioral traits adequately.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise, using a brief introductory sentence followed by bullet-like points. Every sentence adds value, with no redundancy. Information is front-loaded, making the purpose immediately clear.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (arbitrary code execution, persistent state), the description covers the return value and stdout capture. An output schema exists but is not shown; the description explains how output is returned. Minor missing details include handling of timeouts and potential side effects, but overall it is sufficiently complete for an AI agent to use correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds meaning for the 'code' parameter by explaining how to get output (last expression repr) and that stdout is captured. However, it offers no additional semantic for 'timeout_seconds', and the input schema has 0% description coverage, so the description only partially compensates. A note on timeout behavior would improve clarity.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool executes Python code in a persistent ArcPy session, specifying the action and resource. It distinguishes from siblings like 'run_gp_tool' by emphasizing general-purpose usage for any ArcPy task, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides good guidance on when to use the tool: for any ArcPy operation, especially when state persistence is needed. It lists specific use cases like geoprocessing and automation. However, it does not explicitly mention when not to use it or suggest alternatives (e.g., 'run_gp_tool' for simple tool execution), which would strengthen guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_featuresA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description discloses read-only behavior, explains the 'where' clause and 'limit' truncation indication, and notes output coordinates are WGS84. This adds useful behavioral context beyond the schema.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences plus inline parameter clarifications, front-loading the main purpose. Every sentence adds value without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the parameter count (4) and the presence of an output schema, the description covers the core purpose, key parameters, and behavioral quirks. It could mention the 'path' parameter format but is adequate overall.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%; the description adds meaning for 'where' (SQL clause with example) and 'limit' (caps features, truncation indication). However, 'path' and 'timeout_seconds' are not explained, so not all parameters benefit.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool reads vector data (shapefile, feature class, layer) and outputs GeoJSON. It uses the verb 'read' and specifies the resource, distinguishing it from sibling tools like create_features.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description identifies it as the inverse of create_features, implying usage for inspecting geometries and attributes. It provides context but does not explicitly state when not to use it or mention alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• session_statusA
  4.2/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses side effect that starting the session may be slow, which is key behavioral info. No annotations provided, so description carries full burden.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences, front-loaded with purpose. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Output schema exists, and description outlines return contents. Adequately complete for a status check tool with 0 parameters.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist; schema coverage is trivially 100%. Description adds value by detailing what components are checked (license, workspace, variables).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description specifies verb 'Check' and resource 'ArcPy session' with concrete aspects (license level, workspace, live variables). Differentiates from siblings like restart_session and arcpy_execute.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies usage for checking session state before executing other tools, but lacks explicit when-to-use or when-not-to-use guidance.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• search_gp_toolsA
  4.3/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses search behavior: terms ANDed, matched against tool names, empty query lists everything up to limit. No annotations provided, so description carries burden; lacks mention of any side effects but search is harmless.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with clear structure: purpose then usage details. No unnecessary words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given simple parameters and presence of output schema, description covers essential usage: how to query and what happens with empty query. Fully adequate for agent invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Without schema descriptions (0% coverage), description implies query and limit parameters but does not explicitly define them or their defaults/ranges. Adds some value beyond schema names but not fully compensatory.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states it searches all available geoprocessing tools including extension toolboxes, distinguishing it from siblings like run_gp_tool and describe_gp_tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear guidance on query syntax (space-separated ANDed terms), name matching example, and empty query behavior, but does not explicitly compare to alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• restart_sessionA
  4.4/5.0
  Behavior4/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  No annotations provided, but the description details key behaviors: clearing session variables and releasing locks/licenses. Could mention if it terminates running processes or if it's asynchronous, but overall good transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise sentences with no wasted words. First sentence states action, second adds usage and effects. Front-loaded and efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (no params, no annotations), the description covers purpose, usage, and primary side effects. Could mention output schema briefly, but overall complete for its scope.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  No parameters exist; schema coverage is 100% trivially. Description adds no parameter info as none needed, which is appropriate for a 0-param tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool restarts the ArcPy worker process, with specific actions: clears session variables and releases locks/licenses. This distinguishes it from siblings like session_status or run_gp_tool.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly states when to use: after a hang, crash, or to free state. Lacks exclusions or alternatives, but the context is clear given the tool's simplicity.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• pro_live_executeA
  4.7/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description fully discloses behavioral traits: it runs in a live session, requires cowork mode, variables persist between calls, and warns about destabilizing Pro. It also explains error handling (exact one-liner pasting). This is comprehensive for a non-annotated tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is relatively long but well-structured with clear sections. It front-loads the main purpose and then provides necessary details. Every sentence adds value, though it could be slightly more concise without losing information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's complexity (3 parameters, no annotations, output schema exists), the description covers most aspects: purpose, usage guidelines, behavioral traits, and parameter semantics. It lacks explicit description of the timeout parameter and return values, but overall it is quite complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 the 'action' parameter usefully (human label for activity log) and implies 'code' is Python code. However, 'timeout_seconds' is not explicitly described. Despite this, the description adds significant value beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description clearly states that the tool executes Python inside the currently open ArcGIS Pro application, differentiating it from arcpy_execute. It explicitly mentions key capabilities like accessing arcpy.mp.ArcGISProject('CURRENT') and immediate layer appearance, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly contrasts with the sibling tool arcpy_execute (headless vs live), provides caution about avoiding rapid view/camera manipulation, and includes house rules (e.g., don't create new .aprx files unless asked). This offers clear guidance on when and how to use the tool.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_featuresA
  4.9/5.0
  Behavior5/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  Discloses key behaviors: overwriting existing outputs, automatic attribute field creation, geometry type inference, required WGS84 coordinate system, and return value. With no annotations, the description fully covers behavioral traits.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Organized with front-loaded purpose, each sentence adds value. The description is appropriately sized for the tool's complexity, with no redundant text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the 4 parameters, output schema availability, and no annotations, the description covers input/output, parameter usage, behavioral details, and return value. Complete for an agent to select and invoke correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema coverage, the description adds meaning to three of four parameters: 'geojson' (implied GeoJSON string), 'output_path' (format inference), and 'geometry_type' (when to set). However, 'timeout_seconds' is not explained, though it's a common default parameter. Almost fully compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Clearly states the tool creates vector data from GeoJSON, specifies output format options (shapefile vs geodatabase feature class), and distinguishes itself from sibling tools like 'export_features' by emphasizing creation from scratch with GeoJSON input.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit when-to-use guidance ('fastest way to MAKE data from scratch'), explains output format selection via 'output_path', and gives context for CRS transformation using a sibling tool. Also clarifies when to set 'geometry_type' parameter.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.