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

No annotations, so the description carries the full burden. It implies a read-only enumeration scoped to 'tracked' event types and discloses what the returned _id is for, but says nothing about pagination, ordering, size of result set, or required permissions for the project.

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, zero filler, with the what-it-does statement first and the practical cross-reference second. Nothing could be removed without losing value.

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 single-parameter, read-only list tool with no output schema, the description covers purpose, input provenance (via schema) and the downstream use of the result. Only list-level behavior such as pagination or result ordering is absent.

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?

Only one parameter and schema coverage is 100%, so the schema already explains app_project_id and even its provenance (analytics_projects_list). The description adds no further detail about the parameter, which meets the baseline-3 expectation.

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 ('List tracked event types of an analytics app project'), and explicitly differentiates itself from nearby siblings by pointing to analytics_export_create as the consumer of the returned _id. An agent can distinguish this from analytics_projects_list and analytics_exports_list without opening any schema.

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?

Gives an explicit downstream usage rule: take the event type _id and pass it as event_type_id to analytics_export_create filters. It does not state exclusions or prerequisites (e.g., that the project must exist / be an analytics app project), so it stops short of a full when/when-not guide.

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?

With no annotations, the description carries the full burden and does so thoroughly: concurrency limit (one active export, HTTP 409), hourly cap (HTTP 429), API-key interval (429), filter mismatch (400) and membership (403) errors, plus the QUEUED->RUNNING->DONE/FAILED lifecycle. It also discloses that nothing is returned through MCP, that the download link is valid 15 minutes, that files are gzipped (Content-Encoding) with a curl --compressed recipe, and that files are deleted after 7 days.

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?

Every sentence carries operational information — purpose, limits, errors, lifecycle, download mechanics — with the purpose front-loaded. It is a single dense paragraph rather than being broken into scannable segments, which is the only reason it falls short of a 5.

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 9-parameter asynchronous export tool with nested filters and no output schema, the description supplies everything an agent needs: where org_id comes from, kind-specific requirements, error meanings, polling cadence, and how the result is actually retrieved. Nothing material is left to inference.

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 the baseline is 3, but the description adds cross-parameter semantics the schema cannot express: USER_EVENTS requires exactly one ID in user_filter.analytics_user_ids, time_from/time_to apply only to EVENTS and USER_EVENTS, and the 1,000,000-row cap with is_truncated semantics. It does not explain app_project_id or csv_delimiter beyond what the schema already states.

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?

Opens with a specific verb and resource ("Start a file export of analytics data of an org") and immediately enumerates the three export kinds with their scope. It also names the sibling analytics_export_status as the polling tool, so an agent can distinguish it from analytics_exports_list without opening either schema.

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?

Explicit guidance on when to use it and what to do next: poll analytics_export_status until DONE or FAILED, no more often than every ~10 seconds, and call it again if the download link expires. It also states prerequisites (org_id from analytics_orgs_list or MCP_ANALYTICS_ORG_ID) and constraint cases per export kind.

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?

With no annotations, the description carries the behavioral burden and discloses the 20-item cap, newest-first ordering, absence of download links, and the env fallback for org_id. It does not discuss permissions or pagination beyond the 20-newest limit, but the key behavioral constraints are present.

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?

The description is two sentences with no wasted text. The core listing behavior and the status-tool alternative are both front-loaded and easy to scan.

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 read-only list tool with optional parameters and no output schema, the description provides enough context: what is returned, ordering, cap, lack of download links, org_id source, and how to get links. Nothing critical is missing 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 description coverage is 100%, so both org_id and app_project_id are already documented in the schema. The description reinforces the org_id source and env fallback but does not add meaning for app_project_id, so the baseline of 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?

The description states a specific verb and resource: list the 20 newest analytics exports of an org, newest first, without download links. It also distinguishes the tool from analytics_export_status by explaining that status is where download links are obtained.

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?

It explicitly directs the agent to analytics_orgs_list or MCP_ANALYTICS_ORG_ID for the org_id, and names analytics_export_status as the alternative when a download link is needed. The selection condition between listing exports and checking export status is clear.

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?

No annotations are provided, so the description carries the full burden and does so: background execution model, the QUEUED -> RUNNING -> DONE|FAILED state machine, download_url being null until DONE, 15-minute link lifetime, 7-day file retention, and the gzip/Content-Encoding behavior with a concrete curl invocation. This is precisely the operational context an agent cannot infer from the one-parameter schema.

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?

Front-loaded with purpose and return shape, then lifecycle, polling cadence, download mechanics, and retention, each in its own compact sentence. The gzip/curl sentence is long but is actionable operational detail rather than 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?

With no annotations and no output schema, the description fully compensates by enumerating the response fields (export_job sub-fields, download_url and its expiry) and describing async behavior. Nothing an agent needs to call and correctly interpret this tool is missing.

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?

Only one parameter and schema description coverage is 100%, so the schema already documents export_id as the _id returned by analytics_export_create. The description adds no further parameter-level detail, but none is needed; 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 ('Get the status of an analytics export and its download link') and immediately enumerates the returned fields. An agent can distinguish it from analytics_export_create and analytics_exports_list without opening any schema.

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?

Gives explicit operating instructions: poll until DONE or FAILED, no more often than once per ~10 seconds, call again for a fresh link once the 15-minute URL expires. It also confirms no rows come through MCP, only status and link, which prevents the agent from attempting a data-fetch path that doesn't exist.

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?

With no annotations, the description carries the burden and does disclose the access scope: only orgs the API key owner is a member of. It also documents the returned fields and how the ID is used elsewhere. It does not explicitly state read-only behavior or describe edge cases such as empty results.

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?

The description is three compact sentences with no wasted wording. The core purpose is front-loaded, followed by practical guidance for using the returned org ID.

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 zero-parameter list tool with no output schema, the description provides enough: it states the access scope, returned fields, and how to use the returned _id. No additional parameter or output documentation is required for an agent to call it correctly.

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?

The tool takes zero parameters, so the schema baseline is already strong. The description does not need to clarify parameter semantics, and it appropriately focuses on output fields and ID usage instead.

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 clear verb+resource formulation: 'List analytics orgs the API key owner is a member of', and it names the returned fields (_id, org_name). It does not explicitly contrast this tool with sibling analytics list tools such as analytics_projects_list, so it falls short of the highest clarity tier.

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?

It explains the key downstream usage: use the returned org _id as org_id in other analytics tools or set MCP_ANALYTICS_ORG_ID. It does not explicitly say when to choose this tool over alternatives or discuss exclusions, but the usage context is clear.

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?

No annotations exist, so the description carries the burden; it implies a read-only enumeration but never states that directly. It does disclose a useful behavioral fact — that the project _id is the value consumed as app_project_id elsewhere — but says nothing about result size, pagination, or ordering.

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 compact sentences, the purpose stated first and the prerequisite plus downstream usage second. No filler or redundant phrasing.

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 list tool with no output schema, the description supplies the input source and the key output-handling hint (use _id as app_project_id), which is exactly what an agent needs to chain calls. Only the lack of any listing-size or pagination note keeps it from a 5.

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% and the single org_id parameter is already fully documented in the schema, including the env-var fallback. The description restates that fallback rather than adding new semantics, 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 ("List app projects") scoped to "an analytics org", which separates it from project_list_by_payment_account and project_list siblings. It does not explicitly name the sibling it is not, but the domain qualifier does the distinguishing work.

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?

Gives concrete prerequisite guidance (org_id from analytics_orgs_list or the MCP_ANALYTICS_ORG_ID env var) and routes the agent forward by telling it to pass the returned _id to analytics_event_types_list and analytics_export_create. No explicit when-not-to-use or comparison against the payment-account project listing, which keeps it below a 5.

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?

No annotations are provided, so the description carries the full disclosure burden. It implies a harmless read of type metadata and adds useful workflow context, but says nothing about whether the returned types are global or scoped to a project/scheme, how large the payload is, or whether the result is static and safe to cache.

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 first defines what is returned, the second the sequencing rule, and the precondition is front-loaded where the agent will act on it.

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 zero-parameter, no-output-schema introspection tool this is nearly complete: what it returns (node/trigger/action types and their config options) and when to call it are both stated. Only the scoping of results and the general shape of the returned config options are left implicit.

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?

Zero parameters, so the schema baseline is 4. The description correctly implies no input is needed to retrieve type information, and there is nothing for it to compensate for.

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 information about available node types") and enumerates the subtypes it covers (trigger_types, action_types) plus their configuration options. An agent can distinguish this discovery tool from the node_create_trigger / node_create_action siblings, though it never names those siblings directly.

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?

"Call this first to see available types before creating nodes" gives an explicit ordering precondition and ties it to the node-creation workflow. It stops short of stating exclusions (e.g., when to skip it because types are already known) or naming alternatives, so it lands at 4 rather than 5.

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?

With no annotations, the description carries the entire burden. It signals a mutation ('create an execution flow') but discloses nothing about idempotency, failure modes when a node ID is invalid, permission requirements, or what happens to an existing edge between the same pair.

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

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

A single front-loaded sentence with zero filler. It is efficient, though its brevity borders on under-specification for a four-parameter mutation tool.

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

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

For a mutation tool with no annotations and no output schema, one sentence is not enough. The agent cannot tell whether the call returns an edge identifier, whether it errors on duplicate edges, or what preconditions (existing nodes, valid scheme) apply.

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 schema itself richly documents node_from/node_to direction, edge_type values, and connection_index semantics including CONDITION outputs. The description adds nothing beyond that, 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 and resource ('Connect two nodes together') plus the outcome ('create an execution flow'), which implicitly contrasts with the sibling node_disconnect. It never names a sibling explicitly, so it stops short of full differentiation.

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

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

No when-to-use or when-not-to-use guidance. It doesn't say whether both nodes must already exist, whether duplicate connections are rejected, or how this relates to node_disconnect / node_get_scheme_edges. The agent must infer all preconditions.

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?

No annotations are provided, so the description carries the full burden. It doesn't disclose whether the copy is deep or shallow, how it's named, whether it's auto-placed in the scheme, or whether the operation is reversible — all critical for a mutation tool.

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

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

A single efficient sentence, front-loaded with the action and resource, with zero filler. It is appropriately sized for what it says, though it says very little.

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 mutation tool with no annotations and no output schema, the description leaves key questions unanswered: what the returned copy contains, its naming, and its placement. One-param schema simplicity helps, but the behavioral gap remains significant.

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?

Only one parameter with 100% schema description coverage ("The node ID to copy"), so the schema fully documents it. The description adds nothing beyond that, but the high coverage justifies the 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?

States a specific verb and resource: "Create a copy of an existing node." This clearly distinguishes it from creation siblings like node_create_action/node_create_trigger, though it doesn't say how the copy differs from node_create.

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

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

No guidance on when to copy versus creating a fresh node, no prerequisites, no note on where the copy lands (same scheme? parent?). The agent must infer all usage context.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It mentions that actions perform operations like sending emails and making HTTP requests, hinting at potential side effects of the created node. However, it omits key behavioral details such as required permissions, whether the scheme must exist, what happens on failure, and whether creation is reversible.

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?

The description is three sentences, front-loaded with the core action, followed by context and a prerequisite. It is efficient with no wasted words, though the example sentence could be seen as slightly extraneous. Overall, it is well-structured.

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?

The description covers purpose and a prerequisite, and the input schema is fully documented. However, with no output schema, the description should ideally explain what is returned (e.g., node ID) and any error conditions or side effects. These omissions leave the agent with an incomplete picture 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 description coverage is 100%, so the schema fully documents all four parameters. The description adds only a minor hint about action_type values via 'Call get_nodes_info first to see available types.' Baseline 3 is appropriate since 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 states a specific verb and resource: 'Create a new action node in a scheme.' It also provides examples of what actions do ('sending emails, making HTTP requests'), which helps distinguish this from sibling tools like node_create_trigger. However, it does not explicitly contrast with the trigger sibling, leaving some inference to the agent.

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 a clear prerequisite: 'Call get_nodes_info first to see available types.' This is actionable usage guidance. It does not explicitly state when to use this tool versus node_create_trigger, but the action/trigger distinction is implied by the naming and description.

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?

No annotations, so the description carries the full burden; it discloses that this is a mutating create operation and that the resulting trigger will start workflow execution, which is meaningful behavioral context. It omits permissions, whether the trigger is active immediately upon creation, and duplicate/slug conflict behavior.

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 short sentences, front-loaded with the action, then purpose, then prerequisite. No filler and nothing repeated from the schema.

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?

Adequate for a simple four-parameter create call, but with no output schema the description never indicates what comes back (e.g., the new node ID that node_connect/node_update later need) and gives no idempotency or error expectations.

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, giving a baseline of 3. The description only indirectly helps by pointing at get_nodes_info for valid trigger_type values; it adds no syntax, defaults, or constraints beyond the schema.

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 ('Create a new trigger node in a scheme') and adds a functional gloss distinguishing triggers from other node types: 'Triggers start the execution of automation workflows.' It does not explicitly contrast with the sibling node_create_action, but the trigger/action distinction is carried by the name and gloss.

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?

Gives one concrete prerequisite ('Call get_nodes_info first to see available types'), which is useful sequencing guidance, but says nothing about when to use this versus node_create_action or when creation is inappropriate.

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?

With no annotations, the description carries the full burden, and it does disclose the most important trait: the action is irreversible. However, it says nothing about side effects in a graph editor — whether connected edges, triggers/actions, or configs attached to the node are also removed — nor about required permissions.

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 ending on the critical warning. No filler, nothing 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 one-parameter destructive tool with no annotations and no output schema, the description covers the essential safety warning but omits cascade behavior and permission requirements that matter for a node-graph mutation. Adequate, not 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% with a single well-documented node_id parameter, so the schema already does the work. The description adds no format hints (ID shape, where to obtain the node_id) beyond what the schema states, 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 and resource: 'Delete a node from a scheme.' An agent can distinguish this from scheme_delete or node_process_delete by the node-level scope. It stops short of explicitly contrasting with siblings such as node_disconnect, but the operation itself is unambiguous.

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

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

No guidance on when to use this versus alternatives in a large sibling set (node_disconnect, node_copy, scheme_delete, node_process_delete). The only implicit signal is 'irreversible', which warns but doesn't route. An agent must infer that this is for permanent removal rather than rewiring.

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?

No annotations are provided, so the description carries the full burden and discloses almost nothing. It does not say whether the disconnect is reversible, what happens if no edge exists, whether permissions are required, or what is returned — all critical for a mutation tool.

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

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

A single short sentence with no padding, so there is no waste — but the terseness is under-specification rather than efficiency. It is front-loaded but nearly empty of content.

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 two-required-parameter mutation tool with no annotations and no output schema, the definition omits side effects, failure modes, and return behavior. An agent could invoke it, but could not predict consequences.

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%, with node_from and node_to both documented as source and target node IDs. The description adds no format, ID-source, or ordering detail beyond the schema, 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 ("Disconnect two nodes") so an agent can tell it removes a link between two nodes. It does not, however, contrast with the inverse sibling node_connect or clarify whether this operates on scheme graph edges.

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

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

No guidance on when to use this versus node_connect, node_delete, or node_get_scheme_edges. No preconditions (both nodes must exist? must the edge exist?) are given, leaving the agent to infer everything.

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?

Since no annotations are provided, the description must carry the behavioral burden. It simply states what is found, but fails to describe the behavior (e.g., whether it returns IDs, configurations, or a list of objects) or any limitations.

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?

The definition is a single, focused sentence. It is highly concise and effectively conveys the tool's main function in one breath.

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?

Given the lack of annotations and output schema, the description is incomplete. It does not define what is returned, making it difficult for an agent to confirm if the tool meets its needs without further trial and error.

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 100% schema description coverage, the parameter semantics are already fully defined in the input schema. The description adds no information that goes beyond the structured fields.

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

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

The description clearly identifies the resource (nodes) and the action (finding existing output buttons/connections). While clear, it does not explicitly distinguish this function from the many existing node-related siblings provided in the context.

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 is a functional statement rather than guidance. It provides no context on when this tool should be used versus alternatives like `node_get_scheme_edges` or `node_get`, leaving the AI to infer the best time to use it.

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?

With no annotations at all, the description carries the full behavioral burden. 'Get details' implies a read, but it says nothing about failure behavior for unknown IDs, permissions, or what 'details' includes — and there is no output schema to fall back on.

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?

One sentence, front-loaded with the verb and resource, with no redundant phrasing. It is economically written, though the economy comes partly from omission.

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 tool in a crowded family of node_* operations, with no annotations and no output schema, the description should at least distinguish node_get from get_nodes_info/node_list_by_scheme and say what happens on a missing ID. Neither is covered.

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% and the single node_id parameter is documented in the schema, so the description adds nothing beyond it. 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?

States a specific verb ('Get') and resource ('details of a specific node') keyed by ID, so the agent knows exactly what it returns conceptually. It does not differentiate from nearby siblings such as get_nodes_info or node_list_by_scheme, so it falls short of a 5.

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, no mention of covering alternatives, and no preconditions stated. The only hint is 'by its ID', which merely restates the required parameter.

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?

No annotations are provided, so the description carries the full disclosure burden. 'Get all' usefully signals an unfiltered, non-paginated read, but nothing is said about permissions, behavior for an unknown scheme_id, or what an edge record contains (no output schema exists to cover that).

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?

One compact sentence with the resource front-loaded and no filler. It is efficient, though the terseness contributes to the missing guidance elsewhere.

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-optional-parameter read tool with no output schema, the essentials are covered. Still missing are error behavior for a missing scheme and any hint at the shape of the returned edges, which the agent cannot obtain elsewhere.

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% and the single scheme_id parameter is documented in the schema, including the MCP_SCHEME_ID env fallback, which the description does not restate. Baseline 3 applies since the schema does the work.

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 ('Get') and resource ('connections (edges) between nodes in a scheme'), disambiguating from node_get and node_list_by_scheme by returning the relationship graph rather than node data. It does not explicitly name a sibling, but the resource is distinctive enough to select on.

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 versus node_get, node_list_by_scheme, or the mutation siblings node_connect/node_disconnect. The agent must infer that this is the read-side counterpart of connect/disconnect from the name alone.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about return format, pagination, ordering, or permissions. For a list operation over a potentially large node set, this leaves meaningful behavioral gaps.

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

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

A single front-loaded sentence with no wasted words. It is appropriately sized, though it errs toward under-specification rather than over-verbosity.

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?

The tool is simple — one optional parameter, no output schema, no annotations — so a short description is defensible. Still, it omits the shape of the returned node list and any scoping or pagination behavior an agent might need.

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 schema already explains scheme_id and its environment-variable fallback. The description adds nothing about the parameter, so 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 and resource: list all nodes scoped to a scheme. It is clear enough to separate from node_get or node_delete, but it does not distinguish itself from adjacent listing tools such as get_nodes_info or node_process_list_filtered.

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: you use it to enumerate nodes in a scheme. There is no explicit when-to-use guidance, no mention of alternatives like node_get_scheme_edges or get_nodes_info, and no stated prerequisites.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a destructive mutation but says nothing about irreversibility, whether related scheme edges/processes are affected, permission requirements, or failure modes for an invalid ID.

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

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

A single short sentence, front-loaded with the verb, with zero filler. It is efficient, though its brevity contributes to the gaps elsewhere rather than being a structural flaw.

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 destructive operation with no annotations and no output schema, the definition should disclose side effects and confirmation expectations. None of that is present, leaving an agent under-informed before an irreversible call.

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% and the single parameter node_process_id is fully documented in the schema. The description adds no additional meaning about the ID, 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?

The description states a specific verb ('Delete') and resource ('node process record'), which is enough to distinguish it from node_delete and scheme_process_delete by resource type. It does not explicitly contrast with the sibling scheme_process_delete, so sibling differentiation is only implied.

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 node_delete or scheme_process_delete, and no prerequisite or confirmation guidance. The agent must infer usage purely from the name.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it says nothing about read-only safety, permissions, error behavior for an unknown ID, or what 'details' actually contains. For a lookup tool with zero structured safety metadata, a single generic sentence leaves the agent guessing.

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

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

A single front-loaded sentence with no filler or repetition. It is efficiently sized for a one-parameter lookup, though brevity here borders on under-specification rather than economy.

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 annotations, no output schema, and no explanation of what fields 'details' covers, an agent cannot anticipate the response shape or any failure mode. A one-parameter read tool can be described briefly, but this leaves a meaningful informational gap given the surrounding scheme/node complexity.

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 single node_process_id parameter is already documented with type and meaning. The description adds only that it identifies a 'specific' node process execution, which is the baseline expectation rather than new semantic value.

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 ('Get details of a specific node process execution') that clearly identifies a single-record fetch. It does not, however, distinguish this tool from near-siblings such as node_process_list_filtered or scheme_process_get, so the agent must infer the boundary.

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 statement of when to use this vs. the list/filtered variant, no mention that the ID typically comes from node_process_list_filtered, and no exclusions. The one word 'specific' is the only usage cue, which is not enough guidance for choosing among the many node_* and *_process_* siblings.

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?

No annotations are provided, so the description carries the full burden. It discloses that this is a paginated read and imposes a filter precondition, but it says nothing about result ordering, AND vs OR semantics when multiple filters are supplied, maximum page size, or empty-result behavior.

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 the core action front-loaded and the constraint second. 'with pagination' is mildly redundant given page_size/page_index exist, but there is no padding or 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 7-parameter list tool with no annotations and no output schema, the description covers the essentials of what it returns (a filtered list) and the key constraint, but omits filter combination semantics and any hint of the response shape, which the agent must discover by calling it.

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 parameter meanings are well documented and a 3 would be baseline. The description adds value beyond the schema by imposing a cross-parameter constraint (at least one of scheme/node/scheme_process) that the schema does not express, since required is empty.

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 filtered list of node processes') plus the pagination aspect. It is clear what the tool does, but it never distinguishes itself from close siblings such as node_process_get, scheme_process_list_filtered, or node_list_by_scheme, so the agent must infer the boundary.

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 a real usage precondition ('At least one of scheme, node or scheme_process is required'), which is useful guidance. However, it offers no when-to-use/when-not-to-use framing relative to the sibling list tools (node_process_get vs scheme_process_list_filtered), leaving selection to inference.

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?

No annotations exist, so the description carries the full behavioral burden, yet it discloses nothing: not whether this is a partial patch (only the three named fields) or a full replace, what happens to omitted fields, what auth is required, or whether changes are reversible. Only the bare word "update" signals mutation.

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

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

A single short sentence with no filler, so it is not bloated, but it is also under-specified and slightly ungrammatical ("an existing node properties"). Brevity here reflects missing content rather than discipline.

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 mutation tool with no annotations and no output schema, the description should at minimum explain update semantics (partial vs. full), required permissions, and how it relates to node_update_config. None of that is present, leaving the agent to infer the whole behavior contract from the schema.

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 each of the three parameters (slug, node_id, description) has its own inline description, so the schema does the work. The tool description adds nothing beyond it, which is the baseline 3 case.

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?

"Update an existing node properties" names a verb and a resource, but stops there: it never says which properties are mutable or how this differs from the very similar sibling node_update_config. An agent can infer it is a mutation on a node, but nothing more specific.

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 statement of when to use this tool rather than node_update_config, node_create_action, or the other node_* siblings, and no prerequisites or exclusions. The agent must open the schema and guess from the parameter names.

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?

No annotations are provided, so the description carries the full behavioral burden. It only states that configuration is updated and gives examples, but does not explain whether the config replaces or merges with existing settings, what permissions are required, whether changes are reversible, or what the response contains.

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?

The description is a single front-loaded sentence with no wasted words. It is appropriately concise for a simple update tool, though it could have used its brevity more effectively by including a usage distinction.

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?

The tool has no output schema and no annotations, so the description should convey more about mutation behavior and return expectations. It covers the basic action and parameter schema is complete, but leaves important operational details 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. The description adds examples of configuration content but no additional semantics about the JSON string structure or validation beyond what the schema provides, making baseline 3 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 and resource: updating a node's configuration, with examples of what configuration may include. It does not explicitly distinguish this from the sibling node_update tool, which likely handles general node updates, so sibling differentiation is missing.

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?

Provides no guidance on when to use this tool versus node_update or other node tools, and gives no prerequisites or exclusions. The intended usage is only implied by the tool name and description.

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?

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a read operation, but the description does not disclose permissions, whether the relationship is one-to-one, what happens when no payment account exists, or what the response contains.

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?

The description is a single, front-loaded sentence with no redundant or wasted words. It communicates the core action immediately.

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 getter, the description covers the basic operation. However, with no annotations and no output schema, it leaves important context unstated, such as return behavior, error cases, and whether the payment account is guaranteed to exist.

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?

The schema fully documents the single project_id parameter, and the description adds only the phrase 'by project ID', which is already conveyed by the parameter name and schema. With 100% schema coverage, the baseline score of 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?

The description states a specific verb and resource: get a payment account scoped by project ID. It implicitly distinguishes itself from payment_account_get_by_user through the 'by project ID' scoping, but it does not explicitly name the alternative or clarify the distinction.

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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. An agent can infer usage from the name, but the description provides no routing help against siblings such as payment_account_get_by_user or project_get.

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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation but does not disclose permissions, error behavior when no account exists, or what kind of account data is returned.

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?

The description is a single front-loaded sentence with zero wasted text. It communicates the core lookup immediately.

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 lookup with full schema coverage and no output schema, the description is minimally adequate. It still leaves gaps around return value and not-found behavior, which matters more because there are no annotations.

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?

The schema fully documents the single user_id parameter at 100% coverage, and the description reinforces that it is a user ID. However, it adds no format, validation, or lookup semantics beyond what the schema already provides.

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: get a payment account, qualified by user ID. This distinguishes it from payment_account_get_by_project, though it does not explicitly name or contrast with that 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?

There is no guidance on when to use this tool versus alternatives such as payment_account_get_by_project or payment_account_get_transactions. The intended use is only implied by the parameter name.

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?

With no annotations at all, the description carries the full burden and delivers almost nothing beyond implying a read. It says nothing about whether results are paginated, time-bounded, sorted, capped in size, or what permissions are needed to read another account's transaction history.

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

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

A single short sentence with the resource and scope front-loaded and no filler. It is efficient, though the terseness reflects missing content rather than disciplined editing.

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?

The tool is structurally simple (one required param, no nesting, no output schema), so the description need not explain return shapes. Still, for a history/listing endpoint, the absence of any note on paging or result limits leaves a meaningful gap, and there are no annotations to compensate.

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 only one parameter and the schema already documents it at 100% coverage, so the baseline is 3. The phrase 'for an account' confirms the mapping to payment_account_id but adds no format, prefix, or source-of-ID guidance beyond the schema.

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 ('Get') and resource ('payment transactions history') scoped to an account, which is enough to distinguish it from account-lookup siblings like payment_account_get_by_user or payment_account_get_by_project. It does not explicitly name what it is not, so it stops short of a 5.

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 statement of when to use this versus alternatives (e.g. transaction queries scoped by project or the analytics/export siblings), no prerequisites, and no exclusions. Usage can only be inferred from the phrase 'transactions history for an account', which is the bare minimum implied guidance.

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?

No annotations are provided, so the description must carry the full behavioral burden. It indicates a destructive removal but does not disclose irreversibility, side effects on related projects, required permissions, or what the operation returns.

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?

The description is a single front-loaded sentence with no filler. Every word contributes directly to the stated operation.

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 destructive mutation tool with no annotations and no output schema, the description is too thin. It should explain irreversibility, permissions, side effects on related projects, and expected outcome to be complete enough for safe 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 description coverage is 100%, and the sole user_id parameter is already documented as 'The user ID'. The description adds no additional semantics beyond the schema, making baseline 3 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?

The description states a specific verb and resource: remove a payment account from a user. It is clearly distinct from payment_account_update and payment_account_get_by_user, though it does not explicitly name those siblings or clarify scope such as whether the removal is per-user or global.

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 no guidance on when to use this tool versus alternatives like payment_account_update or payment_account_get_by_user. It also omits prerequisites, confirmation requirements, or conditions under which removal is appropriate.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not explain whether this is a partial update, what happens to omitted fields, what permissions are required, whether changes are reversible, or what the response contains. It identifies the editable fields but offers little operational context for a mutation tool.

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?

It is a single efficient sentence with the core update scope front-loaded and no wasted wording. It is appropriately sized, though its brevity contributes to the missing behavioral detail elsewhere.

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 mutation tool with four parameters, no annotations, and no output schema, the description is too sparse. It names the editable fields but omits permissions, partial-update semantics, side effects, and response behavior needed to call the tool safely and correctly.

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 with clear meanings. The description reinforces that payment_account_name and the automatic refill settings are the update targets, but it adds no syntax or format detail beyond the schema.

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 (Update) and resource (payment account settings) and names the two configurable fields, name and automatic balance refill. This distinguishes it from sibling read/remove tools such as payment_account_get_by_user and payment_account_remove, though it does not explicitly contrast with any update-adjacent alternative.

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?

It says what can be updated but gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The mutation context is only implied by the verb 'Update'.

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?

With zero annotations, the description carries the full behavioral burden but discloses almost none of it: no statement about slug uniqueness or collision behavior, whether user_id must reference an existing user, what permissions are needed, or whether creation is idempotent. The only added context is the domain definition of a project.

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 tightly written sentences with the action front-loaded and a follow-on definition; nothing is wasted. It is efficient but borderline thin rather than padded, so not a 5.

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?

This is a mutation tool with no annotations and no output schema, so the description should cover success behavior, validation constraints, and permission/ownership expectations. All three parameters are required yet nothing explains what happens on failure or what is returned.

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 each of the three required parameters is documented inline, so the schema does the work. The description adds no parameter-level meaning beyond that, which is the expected baseline of 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?

Specific verb+resource ("Create a new project") with a useful domain gloss that projects are containers for schemes (automation workflows), which tells an agent what a project means in this system. It does not explicitly contrast with project_update/project_get or the scheme_* family, so it lands just short of 5.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. An agent gets no signal about when a project should be created versus when an existing one should be fetched or updated, even though project_get/project_list_by_payment_account are obvious siblings in the list.

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?

With no annotations, the description carries the full burden and does disclose the two most consequential behaviors for a delete tool: it cascades to associated schemes and it is irreversible. It stops short of stating permission requirements, whether a confirmation step exists, or what happens when the ID does not exist.

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, the destructive effect and cascade are front-loaded, and nothing is wasted. Optimal size for a single-parameter deletion tool.

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

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

For a one-parameter tool with no output schema and no annotations, the description covers the risky parts (cascade, irreversibility) adequately. Only error/nonexistent-ID behavior and permission expectations are left unstated, which is a minor gap given the tool's 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 coverage is 100% and the single parameter's fallback to the MCP_PROJECT_ID env var is already documented in the schema. The description adds no extra meaning about the identifier, 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 (delete) plus resource (project) and adds the cascade scope ('all its associated schemes'), so it is clearly distinguished from project_update, project_get, and scheme_delete. No explicit sibling naming, but the operation is unmistakable.

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 statement of when to use this tool versus alternatives (e.g., project_update, payment_account_remove), nor any prerequisite or confirmation guidance. The only usage-shaped signal is the warning that the action is irreversible, which is a caution rather than routing guidance.

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?

No annotations are supplied, so the description carries the full disclosure burden, yet it only implies a read via "Get." It says nothing about behavior when the project is not found, the auth/workspace scope of the lookup, or that the ID silently falls back to MCP_PROJECT_ID (that detail lives only in 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.

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

One short, front-loaded sentence with no filler or redundancy. It is arguably too terse for the gaps it leaves, but nothing in it wastes the agent's attention.

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 annotations and no output schema, the description is the only place an agent can learn what "details" actually comprises and how failures surface, and it supplies neither. For a lookup tool this leaves a meaningful hole despite the trivial schema.

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 project_id parameter is fully documented there, including the env-var fallback. The description's "by its ID" adds only slight reinforcement, 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 ("Get details of a specific project by its ID"), which is unambiguous on its own. However, it does nothing to distinguish itself from siblings such as project_list_by_payment_account or scheme_get, so the agent must infer the boundary from the 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 guidance on when to use this tool versus project_list_by_payment_account or the other project/scheme getters in the sibling set. No preconditions or alternatives are named, leaving routing entirely to inference.

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?

With no annotations, the description carries the full behavioral burden. 'Get list' implies a read-only operation and 'all projects' conveys scope, but it does not disclose permissions, pagination, ordering, or any other behavioral traits needed to invoke the tool correctly.

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?

The description is one front-loaded sentence with no wasted words. It is appropriately sized for a simple list operation.

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 tool with one fully documented parameter and no output schema, the description adequately states the resource and scope. It could optionally mention pagination or return format, but nothing critical is missing given the low complexity.

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 single payment_account_id parameter is already documented in the schema. The description adds no format, syntax, or example details beyond what the schema provides, which meets the baseline for high schema coverage.

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: getting a list of all projects associated with a payment account. This clearly distinguishes it from single-project tools like project_get or project_update, though it does not explicitly name sibling alternatives such as payment_account_get_by_project.

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 provides no guidance on when to use this tool versus alternatives. It does not mention the reverse lookup payment_account_get_by_project, any prerequisites, or exclusions.

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?

With no annotations, the description carries the full behavioral burden and supplies almost nothing. It does not disclose whether this is a partial/patch update (all three params are optional, which is significant and undocumented), whether omitted fields are preserved, what permissions are required, or whether the change is reversible.

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

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

A single front-loaded sentence with no filler, so it is concise. But the brevity comes at the cost of specification rather than being earned — the sentence is too thin to be useful and is not even grammatically clean.

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 mutation tool with zero annotations and no output schema, the description should at minimum cover patch semantics and any permission or side-effect context. Instead it leaves the agent to reconstruct behavior from an all-optional schema, which is a material gap for a write operation.

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 each parameter is documented in-schema, including the MCP_PROJECT_ID fallback for project_id, so the baseline is 3. The description adds nothing beyond the schema — notably it never explains the all-optional patch semantics implied by required: [].

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 verb ("Update") and resource ("an existing project") with a properties qualifier, so the basic intent is inferable and it is clearly distinct from project_create and project_delete. However, "properties" is left generic and the sentence is grammatically awkward ("project properties"), giving no hint that the updatable fields are name and slug without opening the schema.

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 statement of when to use this tool versus siblings such as project_get, project_create, or project_delete, and no prerequisites or exclusions. The agent must infer from the name alone that this is the mutation path for an already-existing project.

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?

No annotations are provided, so the description carries the full behavioral-disclosure burden. It implies a mutation ('Create') but does not describe permissions, idempotency, side effects, or what is returned, leaving significant gaps for a write operation.

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?

The description is a single front-loaded sentence with zero wasted wording. It directly identifies the action and resource without unnecessary repetition.

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?

The tool is structurally simple: two parameters, full schema coverage, and no output schema. The description covers the basic purpose but, with no annotations, does not provide enough behavioral context about mutation side effects or return behavior for full completeness.

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

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

Schema description coverage is 100%, so both parameters are already documented in the input schema. The description adds only the phrase 'within a project', which loosely maps to project_id but does not add format or fallback details beyond the schema.

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 clear verb and resource: 'Create a new scheme (automation workflow) within a project.' The parenthetical clarifies what a scheme is, making it distinguishable from sibling tools like scheme_update or scheme_get, though it does not explicitly compare itself to alternatives such as scheme_import.

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 no explicit guidance on when to use this tool versus alternatives like scheme_import or when not to use it. Usage is only implied by the verb 'Create', leaving prerequisites and selection context to inference.

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?

With no annotations at all, the description carries the full burden and does disclose the two traits that matter most for a destructive tool: cascading removal of all child nodes and irreversibility. It stops short of permissions, behavior when the scheme is missing, or what the call returns.

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 its blast radius, followed by the irreversibility warning. Nothing is wasted and nothing important is buried.

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 destructive tool with a fully documented schema and no output schema, the description covers what is destroyed and the durability of the effect. Only minor gaps remain: error behavior for an unknown scheme_id and any permission requirements.

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% and the single scheme_id parameter is fully documented in the schema, including the MCP_SCHEME_ID env fallback, so baseline 3 applies. The description adds no additional meaning about the identifier beyond what the schema states.

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?

Specific verb+resource ("Delete a scheme") with the important scope detail that all its nodes go with it. This clearly separates it from scheme_update/scheme_get/scheme_export among the siblings, though it never names an alternative explicitly.

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

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

Usage is implied rather than stated: the irreversible warning signals 'use with care,' but there is no explicit when-to-use, no mention of when to prefer node_delete or scheme_update instead, and no prerequisite/confirmation guidance. The agent must infer the context.

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?

With no annotations, the description carries the full behavioral burden. It does not say whether export is a pure read, whether it writes a file to disk or returns JSON inline, what permissions are required, or what the response looks like — the word 'export' is genuinely ambiguous between those readings.

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

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

A single front-loaded sentence with no filler. Nothing to trim, and the scope clarification is placed where it is immediately useful.

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?

There is no output schema, so the description should clarify what the export actually returns (inline JSON string vs. file location vs. a job/status object), and it does not. With one optional parameter and no annotations, the definition is minimally viable but leaves the return contract undefined.

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 fully documented in the schema, including the MCP_SCHEME_ID environment fallback, so baseline 3 applies. The description adds nothing about the parameter beyond restating the resource being exported.

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?

Specific verb 'Export' plus the resource 'scheme configuration', with a clarifying parenthetical that the payload is nodes and connections as JSON. It does not distinguish itself from nearby siblings such as scheme_get, scheme_get_swagger_json, or scheme_import, so it falls short of a 5.

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

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

No indication of when to choose this over scheme_get (which likely also returns a scheme) or scheme_import (its natural counterpart). There is no mention of preconditions, side effects, or what happens when scheme_id is omitted beyond what the schema already states.

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?

No annotations are provided, so the description carries the full behavioral burden. It does not say what happens when the ID is missing or invalid, whether it errors or returns empty, or how large the returned scheme detail is (nodes, edges, processes). Only 'Get' hints that it is non-mutating.

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

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

A single front-loaded sentence with zero waste. Its brevity borders on under-specified rather than verbose, but every word 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?

A minimal single-record getter with no output schema needs little, but with zero required parameters the tool can be called with no arguments and resolve via MCP_SCHEME_ID – an important behavior the description never mentions. Adequate but with clear gaps.

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% and the schema already documents scheme_id including the MCP_SCHEME_ID env fallback. The phrase 'by its ID' merely echoes the parameter, adding no syntax or format detail beyond the schema.

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 details of a specific scheme by its ID'. Clear enough to act on, but it does not distinguish itself from near-name siblings such as scheme_get_context_type, scheme_get_swagger_json, or scheme_list_by_project.

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 by 'by its ID' – the agent infers this is the single-record fetch to use when it already holds a scheme ID. There is no explicit when-to-use versus scheme_list_by_project or the other scheme_get_* variants.

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?

With no annotations, the description carries the full behavioral burden. It does not explicitly state that this is a read-only, side-effect-free operation, nor does it describe permissions, the return value, or the environment-variable fallback for scheme_id, leaving key behavior to inference.

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?

The description is a single front-loaded sentence with no wasted words. It is appropriately terse for a one-parameter getter, though the extreme brevity contributes to the ambiguity around 'context type'.

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 tool with no output schema and an undefined domain concept, the description should explain what 'context type' means and what the caller receives. It does not, so the agent can call it with a scheme_id but cannot predict the result or confidently compare it to scheme_get.

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 scheme_id parameter is fully documented in the schema, including the MCP_SCHEME_ID fallback. The description adds no further parameter meaning, so the baseline of 3 applies when the schema already does the work.

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 names a specific action (get) and resource (context type of a scheme), so the agent knows this is a retrieval operation. However, 'context type' is never defined, and the description does not distinguish this from sibling tools like scheme_get or scheme_get_swagger_json, leaving the agent unsure what unique value this tool returns.

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 scheme_get. The description implies a simple getter but provides no context, prerequisites, or exclusions to help an agent select it correctly.

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?

With no annotations, the description carries the full load and does well: it discloses that the doc is built from *current* blocks (so it reflects live state), that unreachable webhooks are reported under x-nana800-broken-webhooks with reasons, and that secrets are masked for project readers. It does not state required permissions or error behavior, which keeps it below a 5.

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

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

A single front-loaded sentence with the artifact named first, followed by the content breakdown. Dense but every clause (fields read, response answers, broken-webhook reporting, secret masking) contributes information rather than restating the name.

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 describe the return value — and it does so thoroughly, including a non-obvious extension field and the masking behavior. Only the handling of an omitted scheme_id and failure modes are left unaddressed.

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?

Single parameter with 100% schema description coverage, including the env-var fallback, so the schema already does the work. The description says nothing about scheme_id, which is acceptable at this coverage level but adds no value.

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 artifact: 'Get the OpenAPI 3 document of the scheme webhooks', then enumerates exactly what the document contains (base URL, paths, methods, params, fields, response answers). This is unmistakably different from siblings like scheme_get or scheme_export, which deal with the scheme itself rather than a generated API spec.

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 can infer this is the tool for producing webhook API documentation. There is no explicit when-to-use statement, no mention of when to prefer scheme_export or scheme_get instead, and no stated prerequisites.

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?

No annotations are provided, so the description carries the full disclosure burden for a mutation tool. It never says whether the import replaces existing nodes, appends/merges, handles duplicates, is transactional, or what permissions are needed — all critical for an agent deciding whether to run it.

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

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

A single tight sentence with the action and source front-loaded, no filler. Its brevity is efficient rather than padded, though it borders on under-specification.

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 mutation/import tool with no annotations and no output schema, the description should at minimum say whether it appends vs replaces, what it returns, and what happens on conflicts. None of that is present, leaving key behavioral questions unanswered.

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%, covering both scheme_id (including the MCP_SCHEME_ID env fallback) and nodes_list. The description adds no format or validation detail beyond the schema, 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+resource+source ('Import nodes into a scheme from exported JSON data'), which clearly separates it from siblings like scheme_export and node_create_action. It does not name a sibling explicitly, so it stops short of the top score.

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?

'From exported JSON data' implies it is the counterpart to scheme_export, so the intended workflow is inferable. But there is no explicit when-to-use statement, no mention of required preconditions (target scheme existing, prior export), and no exclusion against creating nodes one-by-one with node_create_* tools.

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?

With no annotations, the description carries the full behavioral burden. It implies a read-only list operation but says nothing about pagination, ordering, result size, permissions, or what happens when the project has no schemes or the id is invalid.

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

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

A single, front-loaded sentence with no filler. It is efficient, though its brevity is close to under-specification given the missing behavioral context.

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 annotations and no output schema, the description should explain what the returned list contains (fields, shape, empty-result behavior). It supplies none of this, leaving an agent unable to predict the response.

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?

Only one parameter with 100% schema description coverage, so the schema already explains project_id and the environment-variable fallback. The description's 'in a project' aligns with the parameter but adds no syntax or format detail beyond it, making baseline 3 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?

The description states a specific verb ('Get list') and resource ('all schemes in a project'), scoped by project. It's clear what the tool does, though it doesn't explicitly position itself against related readers like scheme_get or project_list_by_payment_account.

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 versus alternatives such as scheme_get or node_list_by_scheme, no mention of prerequisites, and no note about the MCP_PROJECT_ID fallback behavior beyond what the schema says.

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?

No annotations are provided, so the description carries the full behavioral burden and does almost nothing with it. It doesn't say whether the delete is permanent or soft, whether child nodes/processes are cascaded, whether permissions are required, or what happens when the ID doesn't exist.

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

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

A single front-loaded sentence with zero waste and no filler. Its brevity is efficient, though it verges on under-specification for a destructive operation.

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 mutation tool with no annotations, no output schema, and no explanation of consequences or errors, the description is not complete enough. An agent calling this cannot predict side effects or failure modes from the definition alone.

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 with 100% schema description coverage, so the schema already explains scheme_process_id as the unique ID of the record to delete. The description adds no semantics beyond that, which meets the baseline for full schema coverage.

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 (delete) and resource (a scheme process record), which an agent can distinguish from siblings like scheme_delete or node_process_delete by resource type. It stops short of explicitly contrasting with those siblings, but the resource naming is unambiguous.

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 versus scheme_process_get or scheme_process_list_filtered, no mention of prerequisites, and no warning that the operation is irreversible. The agent must infer the entire usage context from the verb alone.

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?

No annotations are provided, so the description must carry the full behavioral burden. It does not disclose whether the operation is read-only, what permissions are needed, what happens if the scheme process ID doesn't exist, whether the response includes node states or execution metadata, or whether this is a live or historical execution view. The parenthetical 'workflow execution instance' adds minimal context but falls well short of what a no-annotation mutation/read tool should disclose.

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?

The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's simple one-parameter surface, though it is thin enough that it could have used one more sentence to improve clarity without becoming verbose.

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?

There is no output schema and no annotations, and the description does not compensate by explaining what 'details' include, whether node-level states are returned, or how this relates to sibling process tools. Given the complexity of the scheme/workflow domain and the crowded sibling list, this leaves the agent with substantial ambiguity about what will be returned and when to prefer this tool.

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 'scheme_process_id' is clearly documented in the schema as 'The unique ID of the scheme process'. The description adds no syntax, format, or validation details beyond what the schema provides, so baseline 3 applies for high schema coverage.

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 ('Get details of a specific scheme process') and clarifies with the parenthetical 'workflow execution instance'. However, it does not distinguish this tool from close siblings such as scheme_process_list_filtered or node_process_get, which is important given the crowded sibling set.

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 states what the tool does but offers no guidance on when to use it versus alternatives. There is no mention of when to choose this over scheme_process_list_filtered (for a list) or node_process_get (for a node-level process), and no prerequisites 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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses pagination and the cross-filter requirement, but does not mention read-only status, permissions, default page sizes, sorting, or return behavior.

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?

The description is two short sentences with no wasted text. The core purpose and the most important invocation constraint are front-loaded.

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 7-parameter list tool with no annotations and no output schema, the description covers the essentials but remains sparse. It does not explain the return structure, pagination defaults, or how this differs from related process-list 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?

Schema description coverage is 100%, so the baseline is 3. The description adds a meaningful constraint not expressed by the schema: at least one of scheme or project must be supplied, even though the schema lists no required parameters.

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

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

The description states a specific verb and resource: get a filtered list of scheme processes, clarified as workflow executions, with pagination. It is clear what the tool does, though it does not explicitly contrast itself with siblings such as scheme_process_get or node_process_list_filtered.

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?

It gives one concrete prerequisite: at least one of scheme or project is required. However, it does not explain when to choose this tool over alternatives like scheme_process_get or node_process_list_filtered, nor does it state exclusions.

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?

No annotations are provided, so the description carries the full behavioral burden. It says only that properties are updated, without disclosing whether the operation is a partial or full replacement, what happens to omitted fields, required permissions, or reversibility.

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?

The description is a single front-loaded sentence with no wasted text, but it is under-informative and grammatically awkward ('an existing scheme properties'). Conciseness is achieved at the cost of useful detail.

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 mutation tool with no annotations and no output schema, the description is too thin. It does not clarify partial-update semantics, permission requirements, or what a successful update returns, leaving key agent-relevant context unaddressed.

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 input schema, including the useful MCP_SCHEME_ID environment fallback for scheme_id. The description adds no meaning beyond 'properties', so the baseline of 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?

The description states a clear verb ('Update') and resource ('scheme'), making the core action identifiable. However, it does not differentiate this tool from siblings such as scheme_create or scheme_delete, and the vague phrase 'properties' leaves the set of updatable fields implicit.

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 like scheme_create, scheme_get, or scheme_delete. It also omits prerequisites, such as whether a scheme must exist or whether partial updates are allowed.

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