particlehealth

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

Annotations supply destructiveHint=true and the WRITE title; the description adds the async lifecycle (returns query_id, must be polled), the underlying endpoint, and a prominent write warning. It stops short of explaining why the operation is flagged destructive, what permissions or purpose-of-use compliance rules apply, or whether the retrieval is audited or billable.

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 tight sentences plus the endpoint, with the WRITE warning front-loaded and the next-step guidance immediately after the return value. No filler.

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 4-parameter write tool with no output schema, the description covers the return value (query_id), the polling path, and the endpoint, which is most of what an agent needs. It omits permission/purpose-of-use requirements and the async-vs-sync tradeoff against the get_* siblings.

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 100%, so the schema already documents all four parameters (hints, specialties, purpose_of_use, particle_patient_id) with examples. The description adds nothing parameter-specific beyond the patient id appearing in the endpoint path, so the baseline 3 applies.

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 ('initiate a nationwide clinical-record retrieval for a patient') and implicitly distinguishes itself from the synchronous particle_get_fhir/particle_get_ccda siblings by being a query-creation tool. The WRITE label and endpoint reinforce exactly what the tool does.

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?

Tells the agent the required follow-up ('poll particle_get_query_status for progress'), which is genuinely useful routing. It does not, however, explain when to use this asynchronous query instead of the direct-fetch siblings (get_fhir, get_ccda, get_flat), which is the real selection decision.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the burden and does add real value: it warns the payload may be large, that the return is XML/text passed through as-is unless JSON, and gives the exact endpoint. It does not cover permissions or any failure modes, but the format/size disclosure is meaningfully beyond the annotation.

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 tight sentences with the purpose front-loaded and the format caveat immediately after. The trailing endpoint string is mildly redundant but does aid invocation, so nothing much is wasted.

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?

With no output schema, the description usefully compensates by explaining the return format (XML/text, conditional JSON parsing) and size risk. The main remaining gap is the absence of any routing information relative to the sibling retrieval tools.

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?

With a single parameter at 100% schema coverage, the schema already documents particle_patient_id fully. The description reinforces the patient-scoped nature via the endpoint path but adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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 (Retrieve) and resource (the patient's C-CDA clinical document(s)), which is clearly narrower than mere FHIR or flat retrieval. It does not, however, explicitly contrast itself with siblings like particle_get_fhir, particle_get_flat, or particle_get_patient_documents, so the agent must infer the distinction from the format name alone.

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?

There is no when-to-use guidance and no mention of alternatives. An agent cannot tell from this description when a C-CDA fetch is preferable to particle_get_fhir or particle_get_patient_documents, or what prerequisites (e.g., an existing query/patient record) might apply.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful context: the return format (FHIR searchset Bundle), support for incremental sync via _since, and pagination via _page_token. It does not mention rate limits or auth requirements, but adds solid value beyond annotations.

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?

Three sentences, front-loaded with the core action and return type. The endpoint sentence is arguably unnecessary for an MCP tool but does not bloat the description. Every sentence carries some information.

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?

No output schema exists, so the description must explain the return value; it states the result is a FHIR searchset Bundle and covers pagination/incremental sync. It could elaborate on what clinical resources are included, but it is sufficiently complete for an agent to call the tool correctly given full schema coverage.

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 100%, so all four parameters are already documented in the schema. The description only loosely ties 'incremental sync' and 'pagination' to _since and _page_token without adding syntax or format details beyond the schema. Baseline 3 is appropriate.

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 (Retrieve) and resource (patient's complete clinical record as a FHIR searchset Bundle). The scope 'complete clinical record' implicitly distinguishes it from particle_get_fhir_by_type, but does not name or explicitly contrast with the sibling.

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?

Mentions incremental sync and pagination, which are usage hints, but provides no guidance on when to choose this tool over alternatives like particle_get_fhir_by_type, particle_get_ccda, or particle_get_flat. No conditions or exclusions are given.

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

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

The readOnlyHint annotation already establishes this is a safe read, and the description adds real value beyond it: the response is returned as a Bundle, pagination matches particle_get_fhir, and the underlying endpoint is given. It does not discuss auth requirements or rate limits, but the Bundle return format and pagination note are meaningful behavioral context.

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 tight sentences front-load the core action and scope, and the trailing endpoint is compact reference detail. Nothing is redundant, though the endpoint line is marginal value for most agents.

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 read tool with 100% schema coverage, no output schema, and flat parameters, the description is nearly complete: it states scope, return type (Bundle), and pagination behavior. The only gap is the lack of explicit disambiguation from the multi-type particle_get_fhir sibling.

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 100%, so all five parameters (including _count, _since, and _page_token) are already documented in the schema. The description adds nothing beyond the required resource_type examples, so the baseline 3 applies.

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 has a specific verb (Retrieve), resource (one FHIR resource type), and scope (for a patient), with concrete examples like Condition, MedicationRequest, and Observation. It names the sibling particle_get_fhir implicitly by referencing shared pagination, but stops short of contrasting the two, so an agent must infer that particle_get_fhir handles the multi-type case.

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?

Usage is implied by 'Retrieve only one FHIR resource type,' which suggests this is the single-type variant, but there is no explicit when-to-use/when-not statement. It references particle_get_fhir for pagination behavior yet never directs the agent to prefer that tool for all-types retrieval or points to get_flat/get_ccda.

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

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

readOnlyHint=true already establishes this is a safe read, lowering the disclosure burden. The description adds the useful context that output is de-nested/flattened versus raw FHIR. However, it says nothing about permissions, pagination, or response size, so it adds only modest value beyond the annotation.

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 tight sentences with the format distinction front-loaded, followed by the filtering note. The endpoint string is mildly redundant but conventional and not wasteful.

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?

With no output schema, the description usefully frames the return format as flattened/de-nested data, and the annotation covers the safety profile for a 3-parameter read tool. Minor gaps around pagination and update semantics remain but are not blocking for correct invocation.

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 100%, so all three parameters are documented in the schema. The description only restates the optional domain filter and adds nothing about the _since timestamp or the patient id format. Baseline 3 is appropriate when the schema carries the parameter detail.

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 (Retrieve) and resource (patient clinical data) and characterizes the output as Particle's flattened/de-nested format. The phrase 'easier to read than raw FHIR' implicitly distinguishes it from the particle_get_fhir sibling, but it doesn't name that alternative directly, so differentiation relies on inference.

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?

'Optionally filter to one domain' hints at a use case, but there is no explicit guidance on when to choose this over particle_get_fhir, particle_get_fhir_by_type, or particle_get_ccda. Usage is implied rather than stated.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower. The description adds the concrete REST endpoint and path, which is useful context, but says nothing about error behavior (e.g. unknown id), record contents, or whether the call is scoped to an authenticated org.

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 short sentences with zero filler; the purpose is front-loaded and the endpoint detail is a compact second sentence that earns its place.

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 one-parameter read tool with no output schema and full annotation coverage, the definition is essentially complete. The only omission is any hint about failure modes or what the returned record contains, which is minor given the simplicity.

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 100% and the single parameter is already documented as the 'Particle-assigned patient id (from submit/search)', so the description adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 gives a specific verb and resource ('Fetch a single patient record') and pins the lookup key to the Particle patient id, which separates it from list-style siblings like particle_search_patient. It stops short of naming an explicit alternative, so sibling differentiation is implied rather than stated.

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?

Usage is only implied: an agent infers this is the right call when it already holds a Particle patient id from submit/search. There is no explicit when-to-use or when-not-to-use guidance and no signposting toward particle_search_patient or the get_fhir/get_ccda variants for different data shapes.

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

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

The annotations already declare readOnlyHint=true, and the description is consistent by describing a pure list/read. It adds the HTTP endpoint as extra context, but says nothing about pagination, filtering, ordering, or the shape of the returned documents, so it stays at 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?

Two short sentences, front-loaded with the action and resource. The trailing endpoint sentence is mildly extraneous but compact and mildly useful for API-level callers.

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 simple one-parameter read with no output schema, the essentials are present, but nothing is said about how documents are returned (list contents, ordering, limits), which an agent may need. Adequate but with a clear gap.

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?

There is a single parameter documented at 100% schema coverage, so the schema already carries semantics. The description adds nothing beyond restating that documents are scoped to a patient, which is the schema baseline.

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 uses a specific verb+resource ("List the documents uploaded / available for a patient") and names the endpoint, so an agent knows exactly what it retrieves. It is reasonably distinguishable from siblings dealing with FHIR/CCDA/query resources, though it never explicitly contrasts itself with them.

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?

There is no guidance on when to use this tool versus alternatives such as particle_get_fhir or particle_get_flat, nor any prerequisites or exclusions. Usage is only implied by the tool name and resource.

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

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

Annotations already declare readOnlyHint=true, so the safe-read profile is covered. The description adds the useful detail that a COMPLETE query is required/returned when query_id is omitted, but says nothing about polling behavior, whether incomplete queries error or return partial data, or auth requirements beyond the endpoint path. Modest added value over the annotations.

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 tight sentences with the purpose front-loaded and the query_id rule immediately after. The endpoint string (GET /api/v2/...) is mildly redundant with the readOnly annotation but is compact and not disruptive.

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?

With no output schema, the description correctly compensates by naming what the response contains (state, timing, demographics, files) and the patient-scoped endpoint. It is nearly complete for a two-parameter read tool; only the behavior for non-complete or missing queries is left unstated.

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 100%, so both parameters are already documented in the schema, and the description's 'omit query_id for the latest COMPLETE query' mirrors the schema text almost verbatim. Baseline 3 is appropriate since the description adds no semantics beyond what structured fields provide.

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 ('Get the status of a clinical-record retrieval query') and enumerates the returned facets (state, timing, demographics, files), which cleanly separates it from sibling operations like particle_create_query or the various get_fhir/get_ccda retrieval tools.

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 gives one conditional usage rule ('Omit query_id to get the latest COMPLETE query'), but that is really parameter behavior rather than when-to-use guidance. It never states when this tool should be preferred over siblings or what prerequisites exist, leaving usage largely inferred.

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

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

Annotations already declare readOnlyHint=true, so the safe read nature is covered. The description adds the underlying endpoint and its variant paths plus the paging mechanism, which is useful operational context, but it does not say what a response contains or how pagination terminates. Modest added value over the annotation.

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 sentences, front-loaded with the resource and clarified scope, followed by the optional filters and paging. The trailing endpoint note is compact and no sentence is redundant.

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 read-only, zero-required-parameter list tool with a fully documented schema and no output schema, the description covers purpose, filters, and pagination adequately. It stops just short of explaining the continuation_token's origin/termination or the response shape.

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 100%, so all three parameters (state, zipcode, continuation_token) are already documented, including the state-over-zipcode precedence. The description restates the same filters and paging without adding format or boundary details, so baseline 3 applies.

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+resource ('List the health-data network participants') and clarifies with a parenthetical what a participant is ('organizations Particle can query'). This is readily distinguishable from the sibling patient/query/document tools, which all operate on clinical data rather than the network directory.

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 via the optional filters and paging, and the schema notes zipcode is ignored when state is set. However, it never states when an agent should reach for this tool versus siblings like particle_search_patient, nor any prerequisites (e.g., auth scope) — guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, so 'non-mutating' adds little. However, the description goes beyond annotations by disclosing the return shape (array of matching patient objects) and the empty-result behavior (204 message when none match) — meaningful since no output schema exists.

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?

Three compact sentences, front-loaded with purpose before return behavior and endpoint. Every sentence carries information, though the raw endpoint URL is arguably meta-detail rather than agent-facing guidance.

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 13-parameter, 8-required search tool with no output schema, the description covers purpose, return shape, and no-match behavior. It could note lifecycle or matching-threshold behavior, but for correct invocation it is essentially complete.

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 100%, so all 13 parameters are already documented in the schema with types, enums, and formats. The description adds only the general notion of demographic matching, not syntax or field-level semantics beyond what the schema provides — baseline 3.

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 states a specific verb and resource ('Search for an existing patient by demographics'), which clearly distinguishes a demographic-search operation from an ID-based lookup like particle_get_patient. It stops short of naming that sibling explicitly, so the differentiation is inferable rather than stated.

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 phrase 'by demographics' implies the usage context (use when you don't have a known patient ID), but there is no explicit when-to-use, when-not-to-use, or named alternative against particle_get_patient. Guidance is implied rather than prescribed.

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

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

Annotations declare destructiveHint=true but no readOnlyHint, and the description reinforces the write nature with a ⚠️ WRITE marker plus the concrete effect (a new patient record is created) and return value. It adds the endpoint and the system-generated id behavior, though it says nothing about idempotency or duplicate handling.

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?

Three tightly-packed elements with the warning marker front-loaded, followed by the action and the return-value payoff. Every sentence earns its place with no redundancy.

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?

With no output schema, the description correctly fills that gap by explaining what is returned (the patient plus particle_patient_id). For a 13-parameter write tool this is a solid, well-scoped description, though it omits error/duplicate behavior.

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 100%, so all 13 parameters, including required fields, enum, and format constraints, are already documented in the schema. The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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 ('register a new patient with Particle Health'), which is unambiguously distinct from siblings like particle_get_patient and particle_search_patient. The POST endpoint confirms this is the creation entry point.

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?

Usage context is only implied: the note that the returned particle_patient_id is 'use[d] for subsequent queries' hints at the workflow, but there is no explicit statement of when to register vs. look up or search an existing patient, nor any prerequisites.

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