Chroma MCP Server

# Chroma MCP Server - Test Flow Simulation This document outlines a sequence of Model Context Protocol (MCP) tool calls to simulate a basic workflow and test the functionality of the `chroma-mcp-server`. This is useful for verifying that the server and its tools are operating correctly after setup or changes. **Important Note on Tool Naming:** The tool call examples in this document use generic base tool names (e.g., `chroma_create_collection`, `chroma_get_server_version`). When executing these tests, you will need to **prepend the correct prefix for your specific Chroma MCP server instance** as defined in your MCP client configuration (e.g., if your server is named `my_chroma` in `.cursor/mcp.json`, a tool call would look like `default_api.my_chroma_chroma_create_collection(...)`). **Test-Driven Learning Automation:** For information on the automated test-driven learning workflow, including: - Setting up automated test failure and success tracking - Running tests with the `--auto-capture-workflow` flag - Detecting and promoting test transitions automatically - Creating validation evidence from test improvements See the [Automated Test Workflow Guide](usage/automated_test_workflow.md) and use the client commands: ```bash # Setup test workflow automation chroma-mcp-client setup-test-workflow --workspace-dir /path/to/workspace # Check for test transitions after making changes chroma-mcp-client check-test-transitions --workspace-dir /path/to/workspace --auto-promote ``` **Assumptions:** - The `chroma-mcp-server` is running and accessible via the MCP client (e.g., through Cursor's `chroma_test` or `chroma` configuration). - **Embedding Function:** The server uses an embedding function (configured via `--embedding-function` CLI arg or `CHROMA_EMBEDDING_FUNCTION` env var, defaulting to `all-MiniLM-L6-v2`). The specific function used can slightly affect the results of semantic searches (query/find_similar operations). - **Recent Refactoring:** Document `add`, `update`, and `delete` tools now operate on **single documents** to improve compatibility with certain clients/models. Query and Get operations still support multiple items/results. **Error Handling Note:** - All tool implementations now raise `mcp.shared.exceptions.McpError` on failure (e.g., validation errors, collection not found, ChromaDB errors). Expect error responses to be structured accordingly, rather than returning `isError=True`. **Tool Usage Format Note:** - For tools that accept a `tool_usage` parameter (such as `chroma_log_chat`), the standard format requires each item to have a `name` key and an optional `args` object: ```json {"name": "tool_name", "args": {"param1": "value1", "param2": "value2"}} ``` - The legacy format with `tool` and `params` keys is deprecated but still supported for backward compatibility. - For complete details on tool usage format, see the [Tool Usage Format Specification](docs/usage/tool_usage_format.md). **Client-Side/Framework Limitations Note (Important):** - Testing has revealed that some MCP clients or the framework layer (particularly the test harness) might have limitations in correctly serializing or interpreting tool parameters, especially lists or values **explicitly provided** for parameters that were originally designed as optional. - Specifically: - **Formerly Optional Parameters:** Providing values for parameters like `limit`, `offset`, `n_results`, `session_id`, `branch_id`, `threshold`, `increment_index` in a test tool call can lead to errors like `Parameter '...' must be of type undefined, got number/string`. The framework layer seems to misinterpret the argument *before* it reaches Python/Pydantic validation. - **List Parameters:** Required list parameters like `ids` or `query_texts` may be incorrectly serialized as strings by some clients (e.g., `'["id1", "id2"]'`) instead of proper JSON arrays, causing Pydantic validation errors on the server. - **Workarounds (Mainly for Test Environment):** - **Omit formerly optional parameters** (`limit`, `offset`, `n_results`, `session_id`, `branch_id`, `threshold`, `increment_index`) in tool calls whenever possible, especially in the test harness. Rely on the default values defined in the implementation (e.g., `limit=0`, `offset=0`, `n_results=10`, `session_id=""`, `threshold=-1.0`, `increment_index=True`). The implementation code handles these defaults correctly. - For specifying included fields in `get` operations, use the dedicated tool variants (`chroma_get_documents_by_ids_embeddings`, `chroma_get_documents_by_ids_all`). Base tools now always use ChromaDB defaults. - **JSON String Parameters:** Ensure `metadata`, `where`, `where_document` are passed as valid **JSON strings** (e.g., `'{"key": "value"}'`). Do not pass Python dictionaries directly for these. - Required lists (`ids`, `query_texts`) remain potentially susceptible to client-side list serialization bugs, which might make tools requiring them unusable with certain clients. - Single-item operations (add, update, delete) and simple *required* string/boolean parameters are generally unaffected by these issues. ## Test Sequence ### 1. Check Server Version Verify the server is responding and get its version. ```tool_code print(default_api.chroma_get_server_version(random_string="check")) ``` *Expected Outcome:* A JSON response containing the package name and installed version. ### 2. Create a New Collection Let's create a collection to store test data using the basic tool. ```tool_code print(default_api.chroma_create_collection(collection_name="mcp_flow_test_coll")) ``` *Expected Outcome:* Confirmation of creation with collection name, ID, and default metadata/settings. If the collection already exists, an `McpError` indicating this will be raised. ### 2b. Create Collection with Metadata Create a second collection, this time specifying metadata upfront. ```tool_code print(default_api.chroma_create_collection_with_metadata( collection_name="mcp_flow_test_coll_meta", metadata='{\"description\": \"Collection for metadata tests\", \"topic\": \"testing\"}' )) ``` *Expected Outcome:* Confirmation of creation with the specified metadata. ### 2c. Rename Collection Rename the second collection. ```tool_code print(default_api.chroma_rename_collection( collection_name="mcp_flow_test_coll_meta", new_name="mcp_flow_test_coll_renamed" )) ``` *Expected Outcome:* Confirmation of rename. ### 3. List Collections Verify the new collection appears in the list. ```tool_code print(default_api.chroma_list_collections()) ``` **Note:** Due to potential client limitations with optional parameters, `name_contains` is omitted. Verify manually if needed. *Expected Outcome:* A list including `"mcp_flow_test_coll"` and `"mcp_flow_test_coll_renamed"`. ### 4. Get Collection Details Retrieve information about the newly created collection. ```tool_code print(default_api.chroma_get_collection(collection_name="mcp_flow_test_coll")) ``` *Expected Outcome:* Details including name, ID, metadata, count (should be 0 initially), and sample entries (should be empty initially). ### 5. Add a Document (with Metadata as JSON String) Add a sample document using the single-item tool that expects metadata as a JSON string. ```tool_code print(default_api.chroma_add_document_with_metadata( collection_name="mcp_flow_test_coll", document="This is the first test document.", metadata='{\"source\": \"test_flow\", \"topic\": \"general\"}' # Single JSON string # increment_index is optional, defaults to True as per server implementation (omitted here to rely on default) )) ``` *Expected Outcome:* Confirmation that 1 document was added. The response might include the auto-generated ID if the tool implementation returns it (design choice). Let's assume we don't know the ID for now. ### 5b. Add Another Document (with ID) Add another document, this time specifying an ID. ```tool_code print(default_api.chroma_add_document_with_id( collection_name="mcp_flow_test_coll", document="Here is another document for testing purposes.", id="test-doc-2" # Parameter remains singular 'id' as per schema )) ``` *Expected Outcome:* Confirmation that 1 document was added with the specified ID. ### 5c. Add Third Document (with ID and Metadata) Add a third document with both ID and metadata. ```tool_code print(default_api.chroma_add_document_with_id_and_metadata( collection_name="mcp_flow_test_coll", document="The quick brown fox jumps over the lazy dog.", id="test-doc-pangram", metadata='{\"source\": \"test_flow\", \"topic\": \"pangram\"}' )) ``` *Expected Outcome:* Confirmation that 1 document was added with the specified ID and metadata. ### 5d. Add Document (Basic) Add a basic document without specifying ID or metadata to the first collection. ```tool_code print(default_api.chroma_add_document( collection_name="mcp_flow_test_coll", document="This is a basic document with no extra info." )) ``` *Expected Outcome:* Confirmation that 1 document was added (response might include the generated ID). ### 6. Peek at Collection Check the first few entries. ```tool_code print(default_api.chroma_peek_collection(collection_name="mcp_flow_test_coll")) ``` **Note:** `limit` is omitted due to potential client issues. *Expected Outcome:* A sample of documents (default limit is 10) including the ones we added (e.g., ID "test-doc-2", "test-doc-pangram", and one auto-generated ID). ### 6b. Get All Documents Retrieve all documents from the first collection (respecting potential default limits). ```tool_code print(default_api.chroma_get_all_documents(collection_name="mcp_flow_test_coll")) ``` *Expected Outcome:* A list containing all documents currently in `mcp_flow_test_coll`. ### 7. Query Documents Perform a semantic search. This tool now queries both the specified `collection_name` AND the `derived_learnings_v1` collection, merging the results. **Note:** The quality and specific ranking of results depend on the chosen embedding function and the content of both collections. Each result item's metadata will include a `source_collection` field indicating its origin. ```tool_code print(default_api.chroma_query_documents( collection_name="mcp_flow_test_coll", query_texts=["Tell me about test documents"], # Required list, should work # n_results is optional (defaults to 10), include is optional )) ``` **Note:** Optional parameters omitted due to potential client issues. Use specific variants for filtering if needed and if the client supports them. *Expected Outcome (Client Limitation possible):* A list of results including relevant documents from BOTH `mcp_flow_test_coll` and potentially `derived_learnings_v1`. Each result item's metadata should include a `source_collection` field indicating its origin (`mcp_flow_test_coll` or `derived_learnings_v1`). May fail if client cannot handle `query_texts` list. ### 7b. Query with Metadata Filter (`where`) Perform a query filtering by metadata. ```tool_code print(default_api.chroma_query_documents_with_where_filter( collection_name="mcp_flow_test_coll", query_texts=["Tell me about pangrams"], where='{\"topic\": \"pangram\"}' # Filter for topic as JSON string )) ``` *Expected Outcome:* Results containing the "pangram" document. ### 7c. Query with Document Filter (`where_document`) Perform a query filtering by document content. ```tool_code print(default_api.chroma_query_documents_with_document_filter( collection_name="mcp_flow_test_coll", query_texts=["Tell me about general test documents"], where_document='{\"$contains\": \"first test\"}' # Filter for content as JSON string )) ``` *Expected Outcome:* Results containing the document with "first test" in its content. ### 8. Get Specific Documents by ID Retrieve documents using their known IDs. Use the specific `_by_ids` variant. **This step might fail with affected clients due to list handling.** ```tool_code # Use the IDs we specified earlier. print(default_api.chroma_get_documents_by_ids( collection_name="mcp_flow_test_coll", ids=["test-doc-2", "test-doc-pangram"] # Required list # Optional parameters like 'include' are omitted as per client limitations note / Pydantic models )) ``` *Expected Outcome (in affected clients):* Likely failure due to client list handling. *Expected Outcome (if successful):* JSON containing the requested documents "test-doc-2" and "test-doc-pangram". ### 8b. Get Documents with Metadata Filter (`where`) Retrieve documents filtering by metadata. ```tool_code print(default_api.chroma_get_documents_with_where_filter( collection_name="mcp_flow_test_coll", where='{\"source\": \"test_flow\"}' # Filter for source as JSON string # Optional parameters like 'limit', 'offset', 'include' are omitted )) ``` *Expected Outcome:* Documents matching the `source` metadata. ### 8c. Get Documents with Document Filter (`where_document`) Retrieve documents filtering by content. ```tool_code print(default_api.chroma_get_documents_with_document_filter( collection_name="mcp_flow_test_coll", where_document='{\"$contains\": \"basic document\"}' # Filter for content as JSON string # Optional parameters like 'limit', 'offset', 'include' are omitted )) ``` *Expected Outcome:* Documents containing "basic document". ### 8d. Get Specific Documents by ID (Embeddings Only) Retrieve document embeddings only using their known IDs. **This step might fail with affected clients due to list handling.** ```tool_code # Use the IDs we specified earlier. print(default_api.chroma_get_documents_by_ids_embeddings( collection_name="mcp_flow_test_coll", ids=["test-doc-2", "test-doc-pangram"] # Required list )) ``` *Expected Outcome (in affected clients):* Likely failure due to client list handling. *Expected Outcome (if successful):* JSON containing `ids` and `embeddings` for the requested documents. ### 9. Update Document Content Modify a document's content using its ID. Use the single-item update tool. ```tool_code # Use one of the known IDs. print(default_api.chroma_update_document_content( collection_name="mcp_flow_test_coll", id="test-doc-2", # Single ID document="This document content has been updated." # Single document content )) ``` **Note:** To update metadata, use `default_api.chroma_update_document_metadata` (takes single `id` and `metadata` dict/JSON string). *Expected Outcome:* Confirmation of update request for 1 document. ### 9b. Update Document Metadata Update the metadata of a document. ```tool_code print(default_api.chroma_update_document_metadata( collection_name="mcp_flow_test_coll", id="test-doc-pangram", metadata='{\"source\": \"test_flow_updated\", \"topic\": \"pangram\", \"status\": \"updated\"}' # New metadata as JSON string )) ``` *Expected Outcome:* Confirmation of metadata update request. ### 10. Verify Update with Get (All Data) Retrieve the updated documents using their IDs and the "all" variant tool to see the changes. **Required `ids` list might still fail with affected clients.** ```tool_code # Use the same IDs used in Step 9/9b. print(default_api.chroma_get_documents_by_ids_all( collection_name="mcp_flow_test_coll", ids=["test-doc-2", "test-doc-pangram"] # Required list )) ``` *Expected Outcome (in affected clients):* Likely failure due to client list handling. *Expected Outcome (if successful):* JSON containing `ids`, `documents`, `metadatas`, `embeddings` for the requested documents, showing the updated content for `test-doc-2` and updated metadata for `test-doc-pangram`. May raise an `McpError` with code `INVALID_PARAMS` if the collection doesn't support loading URIs/data. ### 11. Delete Document by ID Remove a specific document using its ID. Use the single-item delete tool. ```tool_code # Use one of the known IDs. print(default_api.chroma_delete_document_by_id( collection_name="mcp_flow_test_coll", id="test-doc-2" # Single ID )) ``` **Note:** Use filter variants (`delete_documents_by_where_filter`, `delete_documents_by_document_filter`) for bulk deletion based on criteria. *Expected Outcome:* Confirmation of delete request for 1 document. ### 12. Verify Deletion with Get Attempt to retrieve the deleted document. **This step might fail with affected clients due to list handling.** ```tool_code # Use the same ID used in Step 11. print(default_api.chroma_get_documents_by_ids( collection_name="mcp_flow_test_coll", ids=["test-doc-2"] # Required list )) ``` *Expected Outcome (in affected clients):* Likely failure due to client list handling. *Expected Outcome (if successful):* JSON response indicating the document with ID "test-doc-2" was not found (e.g., empty result or specific error). ### 12b. Attempt Get on Non-Existent Document Attempt to retrieve a document ID that never existed. **This step might fail with affected clients due to list handling.** ```tool_code print(default_api.chroma_get_documents_by_ids( collection_name="mcp_flow_test_coll", ids=["this-id-never-existed"] # Required list )) ``` *Expected Outcome (in affected clients):* Likely failure due to client list handling. *Expected Outcome (if successful):* JSON response indicating document not found. ### 13. Delete Remaining Documents (`test-doc-pangram`, generated IDs) Delete the other known documents from the first collection. ```tool_code # First, delete the pangram doc print(default_api.chroma_delete_document_by_id( collection_name="mcp_flow_test_coll", id="test-doc-pangram" # Single ID )) # Need to retrieve IDs of auto-generated docs to delete them # For this example, we'll assume we know one from a peek/get_all result # Replace 'generated-doc-id-1' with an actual ID obtained from Step 6b # print(default_api.chroma_delete_document_by_id( # collection_name="mcp_flow_test_coll", # id="generated-doc-id-1" # )) # print(default_api.chroma_delete_document_by_id( # collection_name="mcp_flow_test_coll", # id="generated-doc-id-2" # )) ``` *Expected Outcome:* Confirmation of delete requests. *Note: Manual step needed to get generated IDs for full cleanup in a real run.* ### 14. Delete First Collection (`mcp_flow_test_coll`) Clean up by deleting the first test collection. ```tool_code print(default_api.chroma_delete_collection(collection_name="mcp_flow_test_coll")) ``` *Expected Outcome:* Confirmation of deletion. If it doesn't exist, an `McpError` is raised. ### 14b. Delete Second Collection (`mcp_flow_test_coll_renamed`) Clean up by deleting the second (renamed) test collection. ```tool_code print(default_api.chroma_delete_collection(collection_name="mcp_flow_test_coll_renamed")) ``` *Expected Outcome:* Confirmation of deletion. ### 15. Verify Collection Deletion Attempt to list collections (should be empty or only contain non-test collections). ```tool_code print(default_api.chroma_list_collections()) ``` **Note:** `name_contains` omitted. Verify manually. *Expected Outcome:* A list of collection names that does not include `mcp_flow_test_coll` or `mcp_flow_test_coll_renamed`. --- ## Advanced: Thinking Tools (Example Flow) This section demonstrates a more realistic workflow using the sequential thinking tools, simulating debugging and feature planning. These tools operate independently and use their own internal storage mechanisms. **Note:** A `session_id` is generated on the first call for a new sequence and should be reused for subsequent thoughts in that sequence. ### T1. Start Session 1: Debugging Login Record the first thought in a new session about a login issue. ```tool_code print(default_api.chroma_sequential_thinking( thought="User reports login fails frequently after recent deployment. Need to check server logs for errors.", thought_number=1, total_thoughts=3 # session_id is omitted, will be generated for session 1 )) ``` *Expected Outcome:* Confirmation, including the generated `session_id` (let's call it `session_id_1`). ### T2. Continue Session 1: Identify Error Record the second thought, using `session_id_1`. ```tool_code # Replace 'session_id_1' with the actual ID from T1's output print(default_api.chroma_sequential_thinking( session_id="session_id_1", thought="Logs show intermittent 'InvalidCredentialsError'. Suspect password hashing or comparison logic in auth_utils.py.", thought_number=2, total_thoughts=3 )) ``` *Expected Outcome:* Confirmation. ### T3. Continue Session 1: Found Bug Record the final thought for the debugging session. ```tool_code # Replace 'session_id_1' with the actual ID from T1's output print(default_api.chroma_sequential_thinking( session_id="session_id_1", thought="Found the bug! Salt generation during registration used a non-deterministic source. Fixing auth_utils.py.", thought_number=3, total_thoughts=3 )) ``` *Expected Outcome:* Confirmation. ### T3a. Get Session 1 Summary Retrieve the summary of the first thinking session. ```tool_code # Replace 'session_id_1' with the actual ID from T1's output print(default_api.chroma_get_session_summary( session_id="session_id_1" # Use actual session_id_1 # include_branches defaults to True, omit for test simplicity due to client limitations )) ``` *Expected Outcome:* A JSON object containing thoughts from `session_id_1`. ### T4. Start Session 2: Planning MFA Start a new session for planning a new feature. ```tool_code print(default_api.chroma_sequential_thinking( thought="Product requirement: Add multi-factor authentication (MFA) for enhanced security.", thought_number=1, total_thoughts=3 # session_id is omitted, will be generated for session 2 )) ``` *Expected Outcome:* Confirmation, including a *new* generated `session_id` (let's call it `session_id_2`). ### T5. Continue Session 2: Research Options Record the second thought for the MFA planning. ```tool_code # Replace 'session_id_2' with the actual ID from T4's output print(default_api.chroma_sequential_thinking( session_id="session_id_2", thought="Researching MFA options. TOTP (like Google Authenticator) seems the best balance of security and user experience vs SMS/Email codes. Will investigate the 'pyotp' library.", thought_number=2, total_thoughts=3 )) ``` *Expected Outcome:* Confirmation. ### T5a. Continue Session 2: Implementation Plan Record the final thought outlining the implementation plan. ```tool_code # Replace 'session_id_2' with the actual ID from T4's output print(default_api.chroma_sequential_thinking( session_id="session_id_2", thought="MFA Implementation Plan: 1. Update User model (add TOTP secret field). 2. Integrate 'pyotp' library. 3. Create QR code setup flow in user profile page. 4. Modify login view/API to check for TOTP code after password validation.", thought_number=3, total_thoughts=3 )) ``` *Expected Outcome:* Confirmation. ### T5b. Get Session 2 Summary Retrieve the summary of the second thinking session. ```tool_code # Replace 'session_id_2' with the actual ID from T4's output print(default_api.chroma_get_session_summary( session_id="session_id_2" # Use actual session_id_2 )) ``` *Expected Outcome:* A JSON object containing thoughts from `session_id_2`. ### T5c. Find Similar Thoughts Search for thoughts related to a specific topic across sessions. ```tool_code # Example query print(default_api.chroma_find_similar_thoughts( query="password hashing issue", # session_id, n_results, threshold, include_branches are optional. # Omitting them here to rely on defaults and due to client limitations. # Defaults: n_results=5, threshold=-1.0 (uses server default, e.g. 0.75), include_branches=True )) ``` *Expected Outcome:* A list of thoughts semantically similar to "password hashing issue". Should likely find the second thought from `session_id_1`. ### T5d. Ensure Sessions Collection Exists Ensure the internal collection used by `find_similar_sessions` exists. This might normally be handled by server initialization, but we include it here for test robustness. ```tool_code # This command remains the same print(default_api.chroma_create_collection(collection_name="thinking_sessions")) ``` *Expected Outcome:* Confirmation of creation or an McpError indicating it already exists (which is also acceptable for the test). ### T6. Find Similar Sessions Search for entire sessions similar to a query related to the new examples. We will test with different thresholds. **Note:** Session similarity scores depend on the chosen embedding function. ```tool_code # Query relevant to both Session 1 (login issue) and Session 2 (MFA involves auth) print(default_api.chroma_find_similar_sessions( query="frequent login failures after deployment", # We will vary the threshold in the actual test runs (e.g., 0.5, 0.75) threshold=0.5 # Placeholder value, will be changed in execution )) ``` *Expected Outcome:* A list of session IDs and summaries that are semantically similar to the query, depending on the threshold used during execution. --- ## Advanced: Auto Log Chat (Enhanced Chat Logging) This section demonstrates using the auto_log_chat functionality to log comprehensive chat summaries with rich context to the `chat_history_v1` ChromaDB collection. ### LC1. Log Basic Chat Log a basic chat interaction with essential information: ```tool_code print(default_api.chroma_log_chat( prompt_summary="User asked about implementing JWT authentication", response_summary="Provided code example for JWT implementation", raw_prompt="How do I implement JWT authentication in my Express application?", raw_response="Here's how to implement JWT authentication in Express: [code example]" # The following parameters are optional and will use defaults: # tool_usage, file_changes, involved_entities, session_id, collection_name )) ``` *Expected Outcome:* Confirmation of successful logging with a generated chat_id (UUID). ### LC2. Log Chat with Tool Usage (Standard Format) Log a chat interaction including the tool_usage parameter using the standard format: ```tool_code print(default_api.chroma_log_chat( prompt_summary="User asked for help debugging authentication error", response_summary="Fixed incorrect parameter in JWT verification", raw_prompt="My JWT verification is failing with 'invalid signature'", raw_response="The issue is in your verification options. Here's the fix: [code]", tool_usage=[ {"name": "codebase_search", "args": {"query": "JWT verification"}}, {"name": "read_file", "args": {"target_file": "auth.js"}}, {"name": "edit_file", "args": {"target_file": "auth.js"}} ] )) ``` *Expected Outcome:* Confirmation of successful logging with a generated chat_id. ### LC3. Log Chat with File Changes Log a chat interaction that includes file changes: ```tool_code print(default_api.chroma_log_chat( prompt_summary="User requested optimization of database query", response_summary="Added index and optimized query pattern", raw_prompt="My database query is slow, can you help optimize it?", raw_response="I've optimized your query by adding an index and restructuring the join.", tool_usage=[ {"name": "read_file", "args": {"target_file": "database.js"}}, {"name": "edit_file", "args": {"target_file": "database.js"}} ], file_changes=[ { "file_path": "database.js", "before_content": "db.users.find({email: userEmail}).sort({created: -1})", "after_content": "db.users.find({email: userEmail}).hint({email: 1}).sort({created: -1})" } ], involved_entities="database.js,query optimization,MongoDB,indexing" )) ``` *Expected Outcome:* Confirmation of successful logging with enhanced context and file changes. ### LC4. Query Logged Chats Query the chat history for relevant entries: ```tool_code print(default_api.chroma_query_documents( collection_name="chat_history_v1", query_texts=["JWT authentication implementation"], n_results=3 )) ``` *Expected Outcome:* A result set containing chat entries related to JWT authentication, likely including the entries created in LC1 and LC2. **Note:** The chat history is also automatically included in the results of regular queries to document collections through the updated `chroma_query_documents` tool (which now queries both the specified collection AND the `derived_learnings_v1` collection). --- This flow covers the primary CRUD operations, filter/query variations, and provides a more detailed example of the thinking tools. Client limitations with list parameters may still affect query/get operations.