SAGOT

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

No annotations exist, so the description carries the full burden. It usefully discloses that closed alpha is the default registration state and that signedIn reflects session/credential validity, but it omits any auth requirements, whether the call is permitted pre-login, or other behavioral traits an agent would want before invoking 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 front-loaded sentence with the verb first and the two return concepts compactly parenthesized. Slightly dense, but no sentence is wasted.

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

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

With no output schema and no parameters, the description is the only source of return-value documentation. It names the two outputs but leaves their possible values vague (e.g., what 'registration availability' can be, what other fields accompany signedIn), so it is adequate but incomplete.

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 baseline of 4 applies. There is no parameter surface the description could or should explain.

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 (Read) and two concrete outputs: public registration availability and caller session/credential validity (signedIn). This is much more than a tautology, but it never distinguishes itself from siblings like account_me, which also report session information, so an agent must guess which to prefer.

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. With account_me and the platform_access_* siblings in scope, the agent is given nothing about when access_info is the right call versus those 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 burden and does well: it discloses an auth requirement (signed-in session) and a persistent side effect (records the version and time on the account). It omits whether re-acceptance is idempotent or what happens on a version mismatch, keeping 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?

Two sentences with zero waste; the auth precondition is front-loaded before the effect and the parameter source. Every clause earns its place.

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

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

For a single-parameter, 100%-covered tool with no output schema, the description supplies the needed auth context and side-effect disclosure. Minor gaps remain around idempotency and error behavior on invalid versions, but nothing blocks 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% and the sole parameter's meaning and maxLength are documented in the schema. The description only repeats the 'version from account.me termsVersion' pointer, adding no syntax or semantics beyond structured data, 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?

Names a specific verb ('accept') and the exact resources affected (Terms of Service, Data Processing Addendum, Privacy Notice), and the account_acceptTerms scope is clearly distinct from siblings like account_me or account_login. An agent can identify what this does 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?

Gives a concrete precondition ('Signed-in session only') and routes the agent to account.me for the correct termsVersion value. It stops short of stating when-not-to-use or what to do if a version is already accepted, so it is clear context without explicit 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 provided, the description carries the full burden and does so: it discloses the auth requirement (signed-in session), the two hard preconditions that cause refusal, and the destructive blast radius (removal from every workspace, session and API key revocation, account anonymisation). It also states a recovery-adjacent fact many tools omit — the email can register again.

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 tight sentences, no filler, with the access precondition front-loaded, the refusal conditions second, and the consequences last — a sensible priority order for an agent deciding whether it may call this at all.

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 and no annotations exist, so the description must cover safety, preconditions and effects itself, and it does. For a single-parameter self-delete tool, an agent has everything it needs to decide whether the call will succeed and what it will cost.

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?

One parameter at 100% schema coverage, so the schema already defines 'password' and its purpose. The description's 'after confirming your password' adds the confirmation semantics but no format or constraint detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource ('delete your own SAGOT account') and immediately constrains it to self-service via 'Signed-in session only', which separates it from admin-facing siblings like platform_accounts_suspend and workspaces_delete.

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 when/when-not: only for your own account, requires password confirmation, and refused while you own a workspace or hold a staff role. It even names the alternative path ('transfer ownership or delete it first'), routing the agent to members_transfer or workspaces_delete instead.

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 does not disclose whether a session/token is established, whether MFA is required, or any rate-limit/auth constraints, offering only the vague equivalency to "website, API and CLI."

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 are appropriately sized and front-loaded, but the content is under-specified rather than information-dense, so the brevity does not translate into efficient communication.

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 login tool with no output schema and no annotations, the description should at minimum explain what success returns (session/token) and that two-step authentication may be required. These omissions leave the agent without needed context.

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 only 33% (just the code parameter), and the description adds no parameter detail at all. It neither explains the email/password requirements nor compensates for the undocumented 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 opens with "SAGOT account.login," which merely restates the tool name rather than stating a specific verb and resource goal. It never explicitly says what the tool accomplishes or how it differs from siblings like account_register or account_logout.

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 claim that it uses "the same authorization and validation as website, API and CLI" weakly implies credentialed sign-in, but gives no when-to-use guidance, no prerequisites, and no contrast against account_register, account_logout, or account_me.

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. 'Uses the same authorization and validation as website, API and CLI' hints that standard auth applies, but says nothing about whether tokens/sessions are revoked server-side, scope of the logout (single session vs all devices), idempotency, or error behavior when not logged in. This is a significant gap for a state-mutating auth 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?

It is short and front-loaded, so it is not bloated. However, the second sentence is vague filler ('same authorization and validation as website, API and CLI') that occupies half the description without conveying actionable detail, so not every sentence earns its place.

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

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

For a no-param, no-annotation, no-output-schema tool, the description should at least describe the resulting state change and any failure modes. It leaves the agent guessing about what logout actually does to the session, making it incomplete for the operation it names.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter meaning is missing.

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 restates the tool name ('SAGOT account.logout') rather than explaining the operation, and the only additional sentence is about authorization parity, not purpose. An agent can infer logout semantics from the name, but the description itself contributes nothing beyond it. This is effectively a tautology.

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 indication of when to call this versus the obvious siblings account_login or platform_access_end, nor any prerequisite (must be authenticated, which session is ended). The name makes the general intent guessable, but the description provides no explicit usage guidance 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?

No annotations are provided, so the description must carry the full behavioral burden. It vaguely states that authorization and validation match the website, API, and CLI, which implies authentication, but it does not disclose whether the tool is read-only, what it returns, or any rate-limit/side-effect 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 short, but the first sentence 'SAGOT account.me' is a tautological restatement of the tool name and does not earn its place. The second sentence adds a small piece of context, but the overall structure is not front-loaded with useful purpose information.

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

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

For a simple, zero-parameter account endpoint, the description is still incomplete: it never says what the tool returns or when it should be used instead of related account tools. No output schema exists, so the description should at least explain the return context, but it does not.

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 input schema has zero parameters, so parameter semantics are not a concern here. Per the rubric, a parameterless tool receives a baseline of 4 because there is no schema-level meaning for the description to add.

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 says only 'SAGOT account.me', which essentially restates the tool name without a clear verb or resource outcome. It does not tell the agent that it returns the authenticated account's profile/details, nor does it distinguish the tool from siblings like access_info or usage_get.

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 guidance, no when-not-to-use condition, and no mention of alternatives among the many sibling tools. The only sentence about sharing authorization with website/API/CLI is not usage 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?

With no annotations, the description carries the burden. It discloses a precondition (requires signed-in session) and required authentication material (password plus current/recovery code), which is useful security context. However, it omits reversibility, consequences of disabling MFA, and token/session implications.

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 precondition is front-loaded before the authentication requirements. The final sentence about SAGOT staff is loosely related but adds minimal operational 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 2-param mutation with no annotations and no output schema, the description covers the core action and auth inputs but leaves gaps: consequences of disabling, error/rate-limit behavior, and whether the session is affected.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully explains that 'code' accepts a 'current code or recovery code' and 'password' is the user's password, but doesn't clarify format, length constraints, or which code types map to which sibling tool.

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 (disable) and resource (MFA / two-step sign-in) clearly. It's distinguishable from account_mfaEnable, account_mfaSetup, and account_mfaRecoveryCodes by naming the disable action, though it doesn't explicitly contrast with those siblings.

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

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

The phrase 'Signed-in session only' implies a precondition for use but doesn't compare against alternatives or state when not to use. The SAGOT staff sentence is vague context rather than actionable 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?

With no annotations, the description carries the full burden and does well: it discloses the auth requirement, that ten one-time recovery codes are returned exactly once and must be stored, and that sign-in behavior changes going forward. It omits failure modes (e.g. calling when MFA is already on) and whether the operation is idempotent.

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, each carrying distinct information: precondition, action, return value, and downstream consequence. The trailing '(account.login code)' is slightly cryptic but does convey the future sign-in requirement without padding.

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

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

With no output schema and no annotations, the description successfully covers the precondition, the one-time recovery-code return, and the resulting sign-in change. It could still cross-reference account_mfaRecoveryCodes or note behavior when MFA is already enabled, but nothing critical for correct invocation 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?

Schema coverage is 0%, so the description must compensate, and it does: the single parameter is identified as a 6-digit code from the authenticator app, giving origin and format beyond the schema's bare minLength/maxLength bounds. It does not explain the 20-character upper bound, which suggests codes may include non-digit characters.

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: confirm an authenticator code to turn two-step sign-in on. The sequencing against account_mfaSetup is implied by 'confirm a 6-digit code', but no sibling tool is named explicitly, so differentiation is inferred rather than stated.

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

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

Provides a real precondition ('Signed-in session only'), which tells the agent when the call is valid. However, it never states when not to use it (e.g. already enabled) or points to account_mfaSetup / account_mfaDisable / account_mfaRecoveryCodes as the alternatives for adjacent steps in the flow.

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 two key behaviors: authentication requirement (signed-in session) and that a current code must be confirmed. It also states the destructive nature ('replace all recovery codes' implies old codes are invalidated) and the return value ('Returns the 10 new codes once'). This is strong for a tool with no annotations.

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

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

Two sentences, front-loaded with the precondition, then the effect and return. Every word earns its place with no redundancy.

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

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

Given no annotations and no output schema, the description provides necessary context: session requirement, confirmation step, destructive replacement, and return format. It doesn't mention rate limits or error conditions, but for a simple 1-param tool this is largely 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 coverage is 0%, so the description must compensate. It does so by explaining that the 'code' parameter is a current recovery code that must be confirmed before replacement. It doesn't specify format or length (schema handles that), but adds essential semantic meaning about what the parameter represents.

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: 'replace all recovery codes'. This is unambiguous and clearly distinguished from sibling MFA tools (mfaSetup, mfaEnable, mfaDisable) which handle different lifecycle stages. An agent can tell exactly what this operation does.

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

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

Explicitly states the precondition 'Signed-in session only' and 'after confirming a current code', giving clear context for when this tool applies. It doesn't name alternatives or exclusions, but given the distinct MFA siblings, the condition is sufficient.

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 well: it discloses the auth requirement (signed-in session), that a password is re-confirmed, that the call returns a fresh authenticator secret and otpauth:// URI, and crucially that no state changes until a later confirmation. It omits error/re-issue behavior if MFA is already enabled, which keeps it from 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?

Two tight sentences with zero filler; the prerequisite and the non-committal nature of the call are front-loaded before the return details. Every clause 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?

No output schema exists, so the description correctly explains the return payload (secret + otpauth:// URI to scan as QR) and the follow-up step needed to finish. The only gap is what happens on repeat calls when MFA is already enabled.

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 single password parameter has 0% schema description coverage, so the description must compensate — and it does by explaining the password is used to confirm/re-authenticate the signed-in user before issuing a secret. It adds real meaning beyond the bare 'password' string field, though it doesn't state length or validation constraints.

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 ('start turning on two-step sign-in' / MFA setup) and explicitly frames the two-step flow, naming account_mfaEnable as the step that actually commits the change. An agent can distinguish this from account_mfaEnable, account_mfaDisable, and account_mfaRecoveryCodes 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?

'Signed-in session only' gives an explicit prerequisite, and the closing sentence tells the agent this call alone does not complete enrollment — account.mfaEnable must confirm a code. It doesn't state when not to call it (e.g. if MFA is already enabled), so it falls short of full alternative/exclusion 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 carries the full behavioral burden, and it does not meet it. It hints that validation matches other surfaces, but omits critical traits: whether the account is immediately active, whether verification email is sent, whether the caller is logged in afterwards, rate limits, and what happens with the invitation tokens.

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 short and front-loaded, but one of the two sentences is a redundant restatement of the tool name and the other is a vague parity claim, so the brevity comes from omission rather than efficiency.

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 6-parameter account-creation mutation with no annotations, no output schema, and sparse schema descriptions, the description is far too thin. An agent cannot tell what the call returns, what happens on success, or how invitation tokens change behavior.

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

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

Schema description coverage is only 17% (just acceptTerms), yet the description adds nothing about name, email, password constraints, or the two invitation token parameters. Name/email/password are largely self-evident, but the invitation flows are undocumented in both schema and description, so it fails to compensate for the low 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 essentially restates the tool name ("account.register") as "SAGOT account.register", which is a tautology rather than a stated verb+resource. It never says plainly that this creates a new user account. The only added information is a note about parity with other surfaces.

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

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

There is no when-to-use guidance and no differentiation from close siblings such as account_login, members_invite, waitlist_join, or account_acceptTerms. The sentence about sharing authorization/validation with website, API and CLI is a consistency note, not an instruction on when to select this tool.

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. 'Uses the same authorization and validation as website, API and CLI' gestures at auth but never states what authorization is required, how results are paginated, 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 two sentences are short and front-loaded, but this is under-specification rather than genuine conciseness; the second sentence spends words on a vague comparison instead 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 paginated list tool with no annotations and no output schema, the description should explain pagination behavior and the workspace scoping requirement. It does neither, leaving the definition materially incomplete 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 0%, so the description should compensate for the three undocumented parameters, yet it says nothing about workspaceId, limit, or cursor. The parameter names are somewhat self-explanatory, but the description adds no meaning whatsoever.

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 is essentially a tautology: 'SAGOT actions.list' restates the tool name without saying what an action is or what listing them returns. It never distinguishes this from the sibling actions_reconcile, so an agent cannot tell the two apart.

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 conditions, and no mention of the sibling actions_reconcile or when that alternative would be preferred. The agent is left to guess 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?

With no annotations, the description carries the full behavioral burden, and it does disclose one important trait: the call does not repeat the business write, so it is safe from duplication concerns. It says nothing about authentication, rate limits, or whether reconciliation can alter stored action state on the owning system.

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, and the core purpose is front-loaded ahead of the behavioral caveat. It is efficient, though arguably terse to the point of under-specification rather than optimally scoped.

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 0% parameter coverage, the description should be doing much more. It omits what a reconcile call returns, what happens to the action's status afterwards, and when the tool should be preferred over siblings — significant gaps for an unfamiliar, jargon-heavy 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 0%, and the description adds nothing about the two parameters. An agent cannot tell from the description whether 'id' identifies the action, the uncertain operation, or a reconciliation record, nor what 'workspaceId' scopes.

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 object ('Query the owning system about an uncertain action'), which clearly separates it from the read-listing sibling actions_list. However, it never defines what an 'action' or an 'uncertain action' is, leaving the domain concept 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?

Usage is only implied: an agent must infer that this is called when an action's outcome is unknown. No alternative tool (e.g. actions_list) is named, and no precondition for when reconciliation is warranted is stated.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It mentions that authorization and validation match other interfaces, but does not specify required permissions, side effects, failure modes, or what happens on creation, making it minimally informative.

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 very short but under-specified rather than concise. The first sentence merely labels the operation and the second adds vague context, so neither sentence earns its place in guiding an agent.

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 complex mutation tool with a nested required persona object, no annotations, and no output schema. The description is entirely inadequate, omitting purpose, parameter semantics, return behavior, and usage context.

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

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

Schema description coverage is 0%, and the description adds no parameter meaning at all. It does not explain workspaceId, the persona object, or any of the many nested fields, leaving the schema as the only source despite lacking descriptions.

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 'SAGOT agents.create' but does not explicitly say it creates an agent; it largely restates the tool name. It provides no differentiation from sibling tools like agents_save or agents_publish, leaving the actual purpose inferred only from the name.

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, what prerequisites exist, or how it differs from alternatives such as agents_save. The description offers only a vague authorization note, leaving the agent to infer everything else.

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. It only vaguely asserts parity of 'authorization and validation' with other surfaces, without naming the required permission, what happens on a missing or unauthorized id, or whether the read has side effects.

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 short and front-loaded with no padding, but the first sentence is pure name restatement and the second is low-information. Brevity here reflects under-specification 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?

No annotations, no output schema, and no parameter documentation leave the agent with almost nothing to work from. For a simple get-by-id tool the bar is low, but this description still falls well short of 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 description coverage is 0% and both required parameters (workspaceId, id) are bare UUID strings. The description adds no meaning — it never explains that id identifies the agent or that workspaceId scopes the lookup.

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 essentially restates the tool name ('SAGOT agents.get') without stating the action or resource in plain terms. An agent must infer that it retrieves a single agent, and nothing distinguishes it from siblings like agents_list or agents_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?

There is no when-to-use guidance, no mention of when to prefer this over agents_list, and no prerequisites or exclusions. The only hint ('same authorization as website, API and CLI') says nothing about selecting this tool.

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, yet "same authorization and validation as website, API and CLI" is a vague assurance rather than a disclosure of required permissions, scoping, pagination behavior, or ordering. It hints that auth is uniform across surfaces but never states what that auth actually requires.

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 text is short, but brevity here reflects under-specification rather than conciseness: neither sentence earns its place by telling the agent anything actionable. The "same authorization as website/API/CLI" claim is front-loaded but empty of decision 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?

A paginated list tool with a required workspaceId, a cursor, a limit, no annotations, and no output schema leaves the agent without any of the context needed to call it correctly or interpret results. The description supplies none of this.

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

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

Schema description coverage is 0% and the description mentions no parameters at all, leaving limit (default 50, max 100), cursor (pagination token) and the required workspaceId entirely undocumented in prose. For a 3-parameter tool with zero coverage, the description should compensate, and it does not.

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?

"SAGOT agents.list" mostly restates the tool name and adds no plain-language statement of what the tool does (retrieve a paginated list of agents in a workspace). "SAGOT" is unexplained vendor jargon that gives an agent no additional signal, and nothing distinguishes it from siblings like agents_get or agents_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?

There is no guidance on when to use this tool versus agents_get (single agent) or the other agents_* tools, nor any mention of prerequisites or pagination workflow. The reader must infer everything 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?

With no annotations, the description carries the full burden of behavioral disclosure, but it only states that authorization and validation match website, API, and CLI. It does not disclose whether pausing is reversible, what happens to active calls or sessions, or what the operation returns. It adds some context about auth consistency but leaves the core behavior unexplained.

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 very short, but it is under-specified rather than concise: the first sentence repeats the tool name, and the second discusses auth parity instead of the operation's effect. It is front-loaded with a tautology rather than the information an agent needs.

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-style tool with no annotations, no output schema, and 0% parameter description coverage, the description is severely lacking. It does not explain what pause does, how it affects agents, or what the required UUIDs identify. The single auth note is insufficient to complete the picture.

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 has two required UUID parameters, workspaceId and id, with zero description coverage. The description does not mention either parameter, so it provides no semantic meaning beyond the schema's bare types. The agent is left to guess whether 'id' refers to the agent, a call, or another entity.

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 restates the tool name as 'SAGOT agents.pause' but does not explain what pausing an agent means or what effect it has. It is essentially a tautology, offering no specific verb-plus-resource explanation beyond the identifier itself. No sibling differentiation is provided.

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 agents_pause versus other agent lifecycle tools such as agents_retire, agents_rollback, or agents_save. The statement about shared authorization and validation does not tell an agent when this operation is appropriate. No exclusions or alternatives 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the effect semantics ('Active calls keep their original snapshot'), which is real information beyond the name, but omits permission requirements, idempotency/retry behavior, and what happens if revision is stale.

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

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

Two sentences, zero filler, with the core action front-loaded and the side-effect scoping second. Nothing to trim.

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 state-mutating publish operation with no annotations, no output schema, and three undocumented required parameters, the description leaves major gaps: what 'validated' requires, what the operation changes on the agent, and the consequences of a revision mismatch.

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

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

Schema description coverage is 0% and the description never mentions id, revision, or workspaceId. The revision parameter in particular looks like an optimistic-concurrency guard, but the description adds no meaning about what value it must match or what happens on mismatch.

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 ('Publish a validated draft') and scopes the effect ('for new calls'), which lets an agent distinguish it from agents_save or agents_rollback without opening the schema. It stops short of naming those siblings explicitly, so the differentiation is inferential rather than stated.

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

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

The phrase 'a validated draft' implies the prerequisite ordering (draft must exist and pass validation, i.e. agents_test/agents_save before agents_publish), but no alternative tool is named and no when-not-to-use condition is given. Usage is implied rather than spelled out.

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 it barely delivers. It implies authorization and validation are required (a small useful hint), but discloses nothing about whether retirement is reversible, destructive, what state changes occur, or any rate/permission constraints for what is clearly a lifecycle 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?

The text is short but under-specified rather than concise. The opening 'SAGOT agents.retire' is a redundant restatement of the tool name, and the second sentence contributes almost no actionable information.

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

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

For a mutation tool with three undocumented required parameters, no annotations, and no output schema, the description is wholly inadequate. An agent has no basis for calling this correctly or predicting its effect.

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?

All three required parameters (workspaceId, id, version) have 0% schema description coverage, and the description adds no meaning for any of them. The version parameter in particular is unexplained, even though it likely implies optimistic concurrency semantics that an agent must understand.

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 only restates the tool name via 'agents.retire' without explaining what retiring an agent actually does (permanent removal? deprecation? archival?). With siblings like agents_pause, agents_rollback, and agents_save in the same family, an agent cannot tell when retire is the correct operation versus these alternatives.

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 is provided at all. The single statement about shared authorization/validation says nothing about the conditions that select this tool over the sibling lifecycle operations.

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. It does add real behavioral context by scoping the effect to 'new calls' only, implying in-flight/existing calls are untouched and existing versions are not deleted. It still omits permissions, reversibility, and whether the target version must be a specific prior publish, so the disclosure is useful but partial.

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 sentence, front-loaded with the behavioral effect and free of padding. It is efficient, though the extreme terseness is what drives the gaps elsewhere rather than serving as a model of completeness.

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 mutating tool with no annotations, no output schema, and three undocumented required parameters is described in a single nine-word sentence. An agent still cannot tell which id to supply, what permissions are needed, or what happens on success, so the description is well short of what this tool needs.

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?

Three required parameters, all UUIDs, with 0% schema description coverage and no annotation help. The description only hints at the meaning of 'version' (a previously published version); it says nothing about 'id' (presumably the agent) or 'workspaceId', so the two other parameters remain opaque.

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 concrete effect — redirecting new calls to a previously published version — which identifies the verb (roll back) and the resource (agent/version) well enough that an agent can act. It does not, however, contrast itself with close siblings such as agents_publish or agents_save, so sibling differentiation is left to the reader.

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 stated prerequisites (e.g. the version must already be published), and no alternative named. The agent is left to infer that this is the revert path and that agents_publish is the forward path.

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 present, so the description carries the full behavioral burden. The only behavioral claim is that it uses the same authorization and validation as website, API, and CLI, which is vague and does not explain mutation effects, revision/concurrency behavior, permissions required, or what happens to omitted persona fields. This is insufficient for a write-style tool with a large nested payload.

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 short and front-loaded, but brevity here reflects under-specification rather than useful conciseness. Every sentence should earn its place, and the authorization note does not meaningfully help an agent call the tool correctly. The size is not the problem; the lack of substantive content is.

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 a high-complexity nested input schema, four required parameters, no annotations, and no output schema. The description does not explain the save semantics, persona structure, revision handling, or how this differs from related agent lifecycle tools. It is completely inadequate for safe and 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 0%, and the description mentions no parameters at all. The agent receives four required top-level parameters, including a complex nested persona object and an integer revision, with no description-based guidance on their meaning or expected usage. The description does not compensate for the missing schema documentation.

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 essentially restates the tool name as "SAGOT agents.save" and adds only that it uses the same authorization and validation as other surfaces. It does not state what is being saved, what the save operation does relative to agents_create or agents_publish, or what entity is affected. This is close to tautology rather than a clear verb-plus-resource purpose.

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 agents_save versus agents_create, agents_publish, agents_rollback, or any other sibling tool. The note about website, API, and CLI authorization does not tell an agent when this MCP tool is appropriate. No conditions, alternatives, or exclusions are provided.

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 largely drops it. It never states whether validation is synchronous, idempotent, or side-effect-free, whether it consumes credits or places any real call, or what happens on a failing validation. For a tool whose name suggests executing a test, the absence of any safety or side-effect disclosure is a significant gap.

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 with the purpose stated first and the disambiguation second; nothing is padded. It is efficiently sized for the small amount of information it actually conveys.

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 three required parameters, no annotations, and no output schema, the description is the only source of behavioral and return information, and it omits both. An agent cannot tell what a successful validation returns, whether failures are surfaced as errors or results, or how to act on the outcome.

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

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

Schema description coverage is 0% across three required parameters (workspaceId, id, revision), and the description explains none of them. The phrase 'the current draft' loosely gestures at the id/revision pair but gives no guidance on which revision must be supplied or whether the draft must already be saved, so the schema remains undocumented from both sources.

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 verb ('validate') but the resource is referred to only as 'the current draft', never naming agents or the draft artifact, so the agent must infer scope from the tool name. The clarifying sentence 'this is configuration validation, not a voice-quality score' usefully narrows what kind of validation is performed, but it does not distinguish this from close siblings such as agents_save or agents_publish.

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?

'Use a draft SIP call to hear the result' implies the tool is meant for pre-publish validation of a draft, which is a real usage hint. However, it never states when to call this versus agents_save, agents_publish, or lines_test, nor any prerequisite (e.g., an existing draft revision must be saved first), leaving routing largely 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, and it delivers almost nothing. 'Same authorization and validation as website, API and CLI' gestures at auth semantics but never states what permissions are required or whether the deletion is permanent or recoverable.

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 short, but this is under-specification rather than conciseness. The only content-bearing claim (authorization parity) is vague, and the namespaced prefix wastes the valuable opening clause.

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 destructive operation with no annotations, no output schema, and 0% parameter documentation needs a description that explains permissions, irreversibility, and required identifiers. This one supplies none of that, leaving the definition inadequate 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 0% and the description says nothing about 'id' or 'workspaceId'. An agent must infer scope and format entirely from the schema patterns, with no added meaning from the text.

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 largely restates the tool name with a namespaced form ('SAGOT artifacts.delete'), which is a tautology rather than an explanation. It never says what an artifact is, what deleting one does, or how it differs from siblings like artifacts_export.

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, no prerequisites, and no alternatives are named. The single sentence about authorization parity with 'website, API and CLI' is not usage guidance; an agent gets no signal about when this tool is the right choice.

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, yet 'Uses the same authorization and validation as website, API and CLI' is the only trait disclosed and it is left undefined. Nothing is said about what the export returns, whether it consumes quota, whether it is idempotent, or what happens on a missing/inaccessible artifact.

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 text is short, but its brevity comes from under-specification rather than economy; the opening clause is redundant with the tool name while the substantive clause is vague. No front-loaded statement of what the tool produces.

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 tool with 0% parameter coverage, no annotations and no output schema, the description should explain the id/workspace pair and the export result. Instead it says only that auth and validation mirror other surfaces, leaving the agent unable to call the tool correctly with confidence.

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

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

Schema description coverage is 0% for two required parameters (id, workspaceId), so the description must compensate and instead says nothing at all about them — not even that id identifies the artifact to export or that workspaceId scopes it. Agents get no disambiguation between the two UUID 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?

"SAGOT artifacts.export" merely restates the tool name with a namespace prefix and never says what an export actually does — download a file, stream bytes, produce a URL, or return a job handle. The agent cannot tell artifacts_export apart from artifacts_delete or from the many other sibling export/list tools on the basis of this text.

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 or when-not-to-use guidance and no named alternative among the ~100 siblings. The only contextual hint is that authorization/validation matches the website, API and CLI — useful for parity reasoning but not a usage rule.

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 substantial work: it declares the auth requirement (signed-in session), the privilege ceiling ('never admin, never more than your role'), workspace scoping, and a return value (redirectTo). It omits what denying actually does (no-op vs. revoke) and whether a prior grant is superseded.

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 dense sentence that front-loads the precondition and then the two outcomes, then the return value. It is efficient, though the em-dash parenthetical makes the privilege-boundary clause slightly harder to parse than necessary.

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 a nested request object, the description covers the essentials (auth, privilege limits, return redirect). It is still incomplete: the deny path's side effects, error behavior for invalid client_id/redirect_uri, and the meaning of the nested request fields are 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 only 33% – workspaceId is documented in the schema, while the eight nested fields of the 'request' object are undocumented anywhere. The description adds useful meaning for workspaceId (required to allow) and for scope ('the listed scopes'), but leaves the OAuth-style request payload opaque, so it only partially compensates for the coverage gap.

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 verb pair (allow/deny) and a specific resource (an AI assistant's request to use SAGOT), and it distinguishes itself from neighboring tools like assistants_revoke, assistants_list, and assistants_preview. An agent can tell exactly what this tool does 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?

It gives a clear precondition ('Signed-in session only') and states the condition under which workspaceId is supplied ('allow (with a workspaceId)' implied by the schema's 'required to allow'). It does not name an alternative tool (e.g., assistants_revoke for undoing a grant) or state when to deny rather than skip the call, so it falls short of full when/when-not 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?

With no annotations, the description carries the load and discloses key non-obvious traits: the secret is returned only once, it requires a signed-in session, and signing in through the client does not pin users to a workspace. It omits failure modes and any rate/limit behavior, but the one-time-secret warning is the critical fact.

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-loads the authentication constraint, then the action, then the caveat, in three tight sentences with no filler. Every sentence carries a distinct fact.

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, and the description does note what is returned (the secret, once) and the workspace-selection behavior. For a 2-parameter, no-annotation mutation tool this is largely sufficient, though return-shape detail and parameter detail remain thin.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It partially does via the example redirect URI, but the 'name' parameter is never explained and there is no guidance on the redirectUris array (count limits, format expectations), leaving half the surface undocumented.

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 (create) plus resource (OAuth client ID and secret for an assistant) with a concrete example consumer (Gemini Enterprise). An agent can distinguish this from the sibling clients tools (assistants_clients_list, assistants_clients_revoke) without opening their schemas.

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?

States the authentication prerequisite ('Signed-in session only') and gives a concrete use case (an assistant such as Gemini Enterprise that asks for credentials). It does not name exclusions or route to alternatives like assistants_clients_list for reviewing existing clients, so it stops short of 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 burden. It usefully adds the auth requirement ('Signed-in session only') and the shape of what is returned (client IDs plus redirect addresses), which is genuine value beyond structured fields. It stops short of disclosing pagination, ordering, or whether revoked clients appear, which a full-burden description should cover.

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 whose first clause is the call-precondition and whose second names the returned entities. Every word earns its place with no padding.

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 listing tool with no output schema, the description covers the essential questions: the auth scope and the content of the listing. Minor gaps around result size, ordering, or pagination keep it from being fully complete, but nothing critical to invoking it 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter schema for the description to duplicate or compensate for, and nothing is left ambiguous about inputs.

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 (list) applied to a precise resource: 'OAuth client IDs you created for assistants, with their redirect addresses.' An agent can distinguish this from assistants_clients_create and assistants_clients_revoke purely from the description without opening a 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?

The phrase 'Signed-in session only' communicates a real precondition that affects whether the tool can be called at all. However, it never frames usage relative to the sibling create/revoke tools or states when an agent should reach for this listing versus other assistants endpoints, so guidance remains implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does disclose the key consequence: assistants using the client can no longer sign in or refresh tokens. It also names the auth requirement. It stops short of stating reversibility or whether existing tokens are invalidated immediately versus at expiry.

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 precondition front-loaded and zero filler. Every clause earns its place.

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

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

For a one-parameter revoke with no annotations and no output schema, the description covers purpose, precondition, and the downstream effect. It is nearly complete; the missing pieces are how to find the ID and whether revocation is reversible.

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

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

Schema description coverage is 0%, so the single 'id' parameter is undocumented structurally. The description partially compensates by identifying it as the OAuth client ID the caller created, but adds no format, source, or lookup detail for actually obtaining that ID.

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 (revoke) and resource (an OAuth client ID), and scopes it with 'you created'. It distinguishes itself from the nearby assistants_revoke and credentials_revoke by naming the exact object being revoked, so an agent can select it 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?

The 'Signed-in session only' line gives a precondition and 'you created' implies a scope, but there is no explicit when-to-use-vs-alternatives guidance and no pointer to assistants_clients_list for resolving the ID. Usage is implied rather than stated.

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

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

With no annotations and no output schema, the description carries the full burden and does disclose two useful things: the auth requirement (signed-in session only) and the shape of each returned record. It says nothing about ordering, volume/limits, or whether revoked or expired assistants appear — gaps that matter for a listing endpoint.

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 dense sentence with the access constraint front-loaded before the resource description. Every clause earns its place, though the colon-and-comma construction is slightly compressed for readability.

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 no-parameter, no-annotation list tool with no output schema, the description covers what is listed and what each item contains, which is close to sufficient. Missing only ordering/completeness notes about the result set, a minor gap for a tool this simple.

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 has nothing to explain and the baseline is 4. The description correctly adds no parameter chatter, and the field list it provides describes output rather than input.

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 (list) and a specific resource (AI assistants connected to your account through OAuth), plus the fields each entry carries (workspace, scopes, connected/last-used timestamps). It largely distinguishes itself from siblings like assistants_clients_list or assistants_authorize, 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?

"Signed-in session only" implies the prerequisite and the context in which the call is valid, which is real guidance. However, it never says when to prefer this over assistants_clients_list, assistants_preview, or assistants_revoke, nor what it excludes — usage must be inferred.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return contents (assistant name, return address, scopes in plain words, problems) and implies a read-only validation. It doesn't state failure modes beyond 'the problem with the request', but that is sufficient for a check 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?

One well-formed sentence that front-loads the action and enumerates what the tool returns. No waste.

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 tool with no output schema, the description covers what the tool does, when to use it, and what it returns. It could mention error handling or authentication requirements, but it is adequate.

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

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

Schema description coverage is 0%, so the description must compensate. The description names the main fields returned and the input is a single 'request' object whose subfields are documented in the schema. It doesn't explain every subfield, but it covers the essential semantics of the request check.

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: 'Check an OAuth authorization request from an AI assistant'. It clearly distinguishes this from siblings like assistants_authorize or assistants_list by describing the pre-consent check and the return contents.

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

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

The phrase 'before consent' gives clear context for when to use the tool. It does not explicitly name alternatives like assistants_authorize, but the timing cue ('before consent') is a strong usage signal.

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 well: it discloses the auth requirement ("signed-in session only"), the immediate effect ("access and refresh tokens stop working immediately"), and the reversibility posture ("must ask again to reconnect"). It omits error behavior and what happens to in-flight work, but the core consequences of a destructive action are covered.

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 clauses with the precondition front-loaded ahead of the action and its effect. No filler, though the second sentence is a semicolon run-on that could be tightened.

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 mutation with no annotations and no output schema, the description covers the auth precondition, the immediate token effect, and the reconnect requirement. Missing only edge-case behavior such as errors on unknown ids or treatment of active sessions.

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 single id parameter has 0% schema description coverage and the description never explicitly names or explains it. However, "disconnect an AI assistant" implicitly maps the id to the target assistant, which is fairly unambiguous for a single required UUID parameter.

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+resource ("disconnect an AI assistant") that clearly conveys a revocation operation. It does not explicitly name the neighboring tool (assistants_clients_revoke) or contrast with assistants_authorize, so sibling differentiation is left 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?

"Signed-in session only" gives an important precondition for use, but there is no guidance on when to choose this over assistants_authorize, assistants_clients_revoke, or assistants_list. Usage is implied by the resource name rather than stated.

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

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

With no annotations, the description carries the full burden and does well: it discloses the auth constraint (human session only, not API key/assistant), the state gate (awaiting_approval), that eligibility is re-validated, and the side effect (the call is queued). It stops short of describing what queued means operationally or whether the action 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?

One dense sentence with the most important constraint (human session only) front-loaded in the parenthetical, followed by the state precondition and the resulting effect. No filler, though the parenthetical slightly interrupts the flow of the primary action.

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 2-parameter mutation with no annotations and no output schema, the description supplies the auth model, the state precondition, the re-validation behavior, and the outcome. What it lacks is parameter-level clarification and any statement of the response, but the core invocation requirements are 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 description coverage is 0% for both id and workspaceId, so the schema provides no meaning, and the description does not compensate. It refers to 'a call' and an implicit workspace context but never explains which parameter is the call identifier versus the workspace scope, or the UUID format expectations.

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 (approve), a specific resource (a call an AI assistant asked for), and the exact precondition state (status awaiting_approval). An agent can distinguish this from calls_decline, calls_cancel, and calls_create without inspecting other tools.

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

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

Gives clear preconditions for use: the caller must be a signed-in person (not an API key or assistant) and the call must be in awaiting_approval status. It does not explicitly name the alternative (calls_decline) or restate the condition that would route an agent there, which is the only gap.

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 one genuinely useful behavior: on a finished call it cancels the scheduled retry rather than the call. However it omits other key traits — whether an active call is hung up or merely flagged, whether cancellation is reversible, and any permission requirements.

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

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

Two sentences, zero filler, and the primary action leads with the edge-case clarification following it. Nothing is wasted.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the core action and one edge case but leaves return behavior, permission requirements, and parameter meaning undocumented. 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?

The schema has 0% description coverage on two required parameters (id, workspaceId), and the description does not compensate at all — it never mentions the call identifier or workspace scoping, so an agent must infer both from the schema's UUID patterns alone.

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 (Cancel) and resource (queued or active call) with clear scope, and the second sentence pins down a non-obvious edge case. It is distinguishable from siblings like campaigns_cancel and calls_get, though it never explicitly names them.

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

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

There is no guidance on when to use this versus alternatives (e.g. campaigns_cancel, or waiting for a call to finish), no prerequisites, and no statement about when cancelling is inappropriate or irreversible. Usage is only implied by the tool name and the state 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 so richly: alpha test-number limitation, OAuth/assistantCallApproval gating, resulting awaiting_approval status, the fact nothing dials until human approval, the 24-hour auto-cancel, and the returned approvalUrl the assistant must relay. This is exactly the beyond-schema behavioral context an agent needs.

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 the core action, then layered with the necessary approval behavior. It is fairly long but nearly every sentence carries distinct, non-redundant information; the approval sentence is dense but justified.

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, mutation-style tool with no output schema and no annotations, the description covers the async/approval lifecycle well (including the approvalUrl return), but leaves the non-obvious parameters and the general return shape unexplained, so it is only adequately 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 only 14% (only `task` is documented), so the description must compensate for the other six parameters — and it does not. It restates `task`'s intent but says nothing about draft, lineId, agentId, contactId, workspaceId, or the required idempotencyKey.

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 ('Queue one call with an agent to a contact') and immediately routes the agent to reads via 'Then read the result with calls.get', distinguishing it from the calls_get/calls_list siblings. The scope is unambiguous 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?

Clear context for when to use it (single call to a contact, result read afterward via calls.get) plus the conditions under which the approval flow triggers. It does not explicitly exclude bulk alternatives like campaigns_start, so it falls just short of full alternative routing.

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 to lean on, the description still carries real behavioral weight: it discloses the auth requirement (signed-in session) and two concrete side effects — the call is canceled and its reserved budget is released. It omits reversibility, idempotency, and error behavior, keeping 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?

Two tight sentences with the scoping/auth constraint front-loaded, followed immediately by the action and its consequences. Every clause earns its place; nothing is padded.

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-param mutation with no annotations and no output schema, the description covers the auth gate and the operation's effects adequately, but leaves the parameter meanings and the result of a decline undeclared. It is minimally sufficient rather than 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 0% for both required parameters (id, workspaceId), so the description must compensate and does not. It never explains what 'id' identifies versus 'workspaceId', nor the expected UUID formats, leaving both params semantically opaque.

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?

Names a specific verb ('decline') and resource ('a call an AI assistant asked for'), which cleanly separates it from calls_approve and calls_cancel by describing the approval-workflow context. It does not name any sibling explicitly, 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?

The phrase 'Signed-in session only' establishes an auth prerequisite, and the framing implies this is the rejection half of an assistant-requested-call approval flow. It never states when-not to use it or points to calls_approve/calls_cancel as alternatives, so guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the full burden. "Uses the same authorization and validation as website, API and CLI" vaguely implies consistent access control but discloses nothing actionable — no required scopes, no error behavior, no statement of what is returned or whether the read has side effects.

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 short but for the wrong reason: it is under-specified rather than efficiently worded. The single substantive sentence is about internal authorization plumbing, which is not the information an agent needs 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?

With no annotations, no output schema, 0% parameter coverage, and two required identifiers, the definition supplies none of the context needed to call this tool correctly. Neither inputs, outputs, nor scope are 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?

Both required parameters (id, workspaceId) have 0% schema description coverage, and the description says nothing about them — not their format, scope, or relationship. The description fails to compensate for the schema gap, leaving the agent to infer that both UUIDs are required lookups.

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?

"SAGOT calls.get" essentially restates the tool identifier without stating in prose what the tool does — retrieve a single call record. It names the resource implicitly but gives no verb+outcome, so an agent cannot distinguish it from calls_list or calls_recording from the text alone.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to the obvious alternative calls_list for listing vs fetching a single call. The only sentence present is about authorization parity with other surfaces, which does not help select the tool.

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 vaguely states that authorization and validation match the website, API, and CLI, but does not disclose whether this is read-only, how pagination works, what permissions are required, 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 short but mostly under-specified: the first sentence only restates the tool name, and the second adds little actionable structure. Brevity here reflects missing information rather than efficient communication.

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 paginated list tool with 3 undocumented parameters, no annotations, and no output schema, the description is far too thin. It omits purpose, usage context, parameter meaning, and behavioral details an agent needs to invoke 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 schema has 3 parameters with 0% description coverage, and the description provides no explanation of workspaceId, limit, cursor, defaults, or pagination semantics. It fails to compensate for the schema gap.

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 says "SAGOT calls.list," which essentially restates the tool name and implies a list operation, but gives no scope, return content, or distinction from siblings like calls_get or calls_create. An agent cannot tell what is listed or why it matters.

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 alternatives, and no prerequisites are provided. The only sentence about authorization and validation does not help an agent choose this tool over calls_get or other sibling calls 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 burden and does disclose meaningful behavior: auth requirement (same bearer credential), that it returns a URL rather than the audio itself, the Ogg format, and the 'no audio for older calls' edge case. It stops short of describing the response shape (e.g. availability flag) or error behavior when no recording exists.

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

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

Purpose is front-loaded in the first sentence, followed by operational detail and the edge case. No filler, though the semicolon-joined middle sentence is dense.

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 two-param, no-output-schema tool, the description covers the return concept, format, and the unrecorded case. Minor omissions around the exact response structure are acceptable given there is no output 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 0%, so the description must compensate, but it never explains what 'id' or 'workspaceId' refer to. An agent must infer that 'id' is the call id. The gap is not closed despite only two 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?

States a specific verb + resource: 'Get recording availability and authenticated audio URL.' An agent can distinguish this from calls_get/calls_list because it names the recording artifact specifically.

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 how to consume the result (fetch URL with bearer credential, --output file) and notes the unrecorded edge case, but never says when to choose this over calls_get or other call tools. Usage is implied by the workflow rather than routed explicitly.

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 must fully disclose behavior. It only notes that authorization and validation match the website, API, and CLI, but omits critical specifics: whether cancellation is permanent/destructive, what happens to in-progress calls, required permissions, or side effects. This is insufficient for a mutation 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?

Very brief but under-specified rather than concise; the cryptic 'SAGOT' prefix wastes space and the auth/validation sentence is not front-loaded for the primary task. Two sentences do not adequately structure the necessary information.

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

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

For a campaign-cancellation mutation with no annotations and no output schema, the description should explain the effect and prerequisites. It gives only a cross-surface auth note, leaving key 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 0%, so the description must clarify the two required parameters (id, workspaceId). The description mentions neither, leaving their meaning and expected values entirely to the bare schema types.

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 is essentially a restatement of the tool name ('campaigns.cancel') with an unexplained prefix 'SAGOT'. It does not state what cancellation entails or distinguish it from sibling operations like campaigns_pause or campaigns_resume. Only a minimal verb+resource repetition is present.

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 tool versus campaigns_pause, campaigns_resume, or other campaign lifecycle tools. The note about shared authorization/validation across surfaces is not usage 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 carries the full burden. It hints that authorization and validation mirror the website/API/CLI, but never states which permissions are required, what validation is applied, or whether this is a read-only lookup — leaving the agent to infer the entire safety profile.

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 text is short, but the opening sentence is pure filler that duplicates the name, and the second sentence is vague boilerplate. Brevity here reflects under-specification rather than disciplined front-loading of useful information.

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

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

For a lookup tool with two undocumented required parameters, no annotations, and no output schema, the description supplies essentially none of what an agent needs: not the return shape, not the auth/permission requirements in concrete terms, not the failure modes. It is inadequate for the tool's 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?

Both required parameters (workspaceId, id) have 0% schema description coverage, and the description adds nothing about what they identify or how they relate. The only meaning available comes from raw type/format keywords in the schema, which the description fails 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?

The first sentence, 'SAGOT campaigns.get', merely restates the tool name and namespace without saying what the operation does (presumably fetch a single campaign by ID). It gives no distinction from siblings like campaigns_list or campaigns_preview, so an agent cannot tell what resource or scope this 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 call this versus campaigns_list, campaigns_preview, or any other sibling, and no stated preconditions. The only context offered ('same authorization and validation as website, API and CLI') is about consistency, not about when to select this tool.

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 it does almost nothing. Saying it 'uses the same authorization and validation as website, API and CLI' gestures at auth but names no concrete requirement, permission scope, pagination behavior, or error semantics.

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 short and front-loaded, but the brevity is under-specification rather than conciseness: the 'SAGOT' prefix and the website/API/CLI clause consume space without conveying actionable information.

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

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

For a three-parameter list tool with no annotations, no output schema, and zero schema descriptions, the definition should at minimum explain the required workspaceId and cursor-based pagination. It explains none of this.

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

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

Schema description coverage is 0% across three parameters, so the schema documents nothing. The description also says nothing about workspaceId being required or about limit/cursor pagination semantics, leaving the agent to infer it all from raw types and constraints.

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 essentially restates the name as 'campaigns.list' and adds only the opaque token 'SAGOT'. It never states plainly that this returns a paginated list of campaigns, nor distinguishes it from siblings like campaigns_get, campaigns_preview, or campaigns_cancel.

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 call this versus campaigns_get (single campaign) or campaigns_preview. No prerequisites, scope, or exclusions are provided.

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 and provides none. A pause is a state-changing, potentially reversible operation; the description says nothing about reversibility, authentication requirements beyond 'same as website/API/CLI', side effects on in-flight calls, or rate limits.

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?

Only one sentence, and it is front-loaded with a tautological identifier rather than the essential information. It is under-specified, not concise — the brevity removes needed content rather than waste.

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 two required parameters, no annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It provides no return behavior, no preconditions, and no error cases.

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

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

Schema description coverage is 0%, so the description must compensate, but it adds no meaning for 'id' or 'workspaceId' beyond the schema's UUID format. It does not clarify that 'id' is the campaign ID or what happens if the campaign is not in a pausable state.

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 the tool via 'campaigns.pause' but never states in plain language what it does — pause a running campaign — nor what state change results. It is essentially a restatement of the name plus a note about authorization, which is a tautology rather than a purpose statement.

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 the numerous sibling tools like campaigns_cancel, campaigns_resume, campaigns_start, or agents_pause. The agent must infer that 'pause' is distinct from 'cancel', which is a critical distinction the description omits.

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 does disclose the most important behavioral trait for this tool — that it performs no dialing/no side effects — which is genuinely useful given the neighboring start/pause/cancel tools. However, it says nothing about permissions, cost implications of the reserved amount, or whether repeated calls are idempotent.

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; the key outputs and the no-dialing caveat are packed into one clause. Nothing could be cut without losing information.

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

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

With no annotations, no output schema, and undocumented parameters, the description should work harder. It usefully previews the shape of the response (eligibility, exclusions, reserved cost), which partially compensates for the missing output schema, but the two required identifiers that scope the preview remain 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?

There are 2 required parameters with 0% schema description coverage, so the description is the only possible source of meaning and it offers none. It never explains that 'id' identifies the campaign to preview or what the 'workspaceId' scoping implies, leaving both UUIDs semantically opaque.

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?

Names a specific verb ('Inspect') and enumerates concrete outputs (eligible contacts, exclusion reasons, maximum reserved cost), which distinguishes it from siblings like campaigns_get and campaigns_list. It implies a per-campaign dry-run but never explicitly says it previews a campaign identified by 'id', so an agent must infer the resource being inspected.

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

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

The phrase 'without dialing' implicitly routes the agent here instead of campaigns_start when the goal is to validate a run before executing it, but the alternative is never named and no explicit when/when-not condition is stated. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full behavioral burden. It gestures at authorization ("same authorization and validation as website, API and CLI") but never states required permissions, whether the campaign must be paused first, whether the action is idempotent, or what state change occurs — all critical for a mutating 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 short (two sentences), but the first is a tautology and the second is about authorization rather than the action, so neither is front-loaded toward what the tool does. Size is appropriate, content placement is not.

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-parameter mutating tool with no annotations, no output schema, and undocumented params, the description omits prerequisites, side effects, and expected result. The lone authorization note is too vague to close those 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 description coverage is 0%: both required UUIDs (id, workspaceId) have format/pattern but no prose. The description adds nothing to explain what the campaign id vs workspace id mean or how they relate, so it fails to compensate for the coverage gap.

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?

"SAGOT campaigns.resume" effectively restates the tool name rather than describing the action; it never says a resume continues a previously paused campaign or how that differs from campaigns_start, campaigns_pause, or campaigns_cancel. The only added sentence concerns authorization, not purpose.

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

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

There is no when-to-use guidance and no mention of alternatives, even though the sibling list contains campaigns_start, campaigns_pause, and campaigns_cancel that an agent must choose between. The authorization sentence does not help select this tool.

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 only vaguely states that authorization and validation match other interfaces, without specifying required permissions, create-vs-update semantics, validation rules, side effects, or idempotency behavior 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?

The text is short, but its brevity comes from omission rather than efficient structure. It is front-loaded with the tool name and a vague compatibility statement, leaving the agent with no actionable information.

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

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

For a mutation tool with no annotations, no output schema, 8 parameters, and 0% schema description coverage, the description is completely inadequate. It omits what is saved, required inputs, update semantics, validation behavior, and any lifecycle context.

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

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

Schema description coverage is 0% across 8 parameters, including 5 required fields, and the description adds no parameter meaning whatsoever. It does not explain id, revision, lineId, contactIds, budgetCentavos, or any other field.

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 essentially restates the tool name as 'SAGOT campaigns.save' and never says what saving a campaign actually does, such as creating or updating it. It does not distinguish this tool from siblings like campaigns_start, campaigns_pause, or campaigns_preview, so the purpose remains tautological.

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 campaigns_save versus campaigns_start, campaigns_resume, campaigns_cancel, or other campaign lifecycle tools. The note about matching authorization and validation on other surfaces does not tell an agent when this operation 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 disclosure burden, yet it never says what starting does, whether it is reversible, whether it triggers outbound activity or billing, or what happens if the campaign is already running. The note about matching website/API/CLI authorization hints at auth requirements but is too vague to be actionable.

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 text is short and front-loaded, but "SAGOT" is unexplained internal jargon and the second sentence spends its budget on an authorization claim rather than on the operation itself. It is concise without being informative.

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 mutating campaign lifecycle tool with no annotations, no output schema, and zero parameter documentation, so the description should carry far more weight than it does. It omits preconditions, side effects, idempotency, and the relationship to pause/resume/cancel, leaving the definition materially incomplete.

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

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

Schema description coverage is 0% for two required UUID parameters (id and workspaceId), and the description adds nothing about their meaning, source, or format. An agent must infer that id is the campaign identifier and workspaceId scopes it, with no confirmation from either the description or 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?

"SAGOT campaigns.start" essentially restates the tool name without explaining what starting a campaign actually does (launch dialing, transition state, etc.). It is a tautology of the identifier rather than a specific verb+resource description, and it does not distinguish itself from siblings like campaigns_resume, campaigns_pause, or campaigns_preview.

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 call this versus campaigns_resume, campaigns_pause, campaigns_preview, or campaigns_cancel. The only context given is that authorization/validation matches the website, API and CLI, which does not tell an agent which situation selects this tool.

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: it enumerates exactly what is destroyed (contact, activity history, recordings, transcripts, outcomes, numbers, action/handoff content) versus retained (time, status, duration, cost), states the operation is permanent, and defines preconditions (no active call, no unresolved action). The doNotCall fingerprint semantics — one-way, prevents future calls/answers, always kept after opt-out — are disclosed rather than hidden.

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 dense sentences, front-loaded with the action and its destructiveness before the caveats. Given this is an irreversible destructive operation, every clause (refusals, retained fields, doNotCall) 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?

No annotations and no output schema, so the description must supply the entire behavioral contract — and it covers destruction scope, retention, preconditions, irreversibility and the doNotCall side effect. Nothing material an agent needs to invoke this safely 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?

Schema coverage is 75%, so the schema documents most parameters, but the description still adds meaning: it frames id vs destination as an either/or, explains destination covers non-contact inbound callers, and expands doNotCall beyond the schema's one-line note into its actual effect. workspaceId is left unremarked but is self-evident.

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 ('permanently erase one person's personal data') plus the two addressing modes (contact id or phone number/destination) and the edge case of non-contact inbound callers. An agent can distinguish it from contacts_suppress, contacts_update and contacts_export without opening a 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 use case ('data-subject erasure requests'), an audience constraint ('Admins'), a sequencing directive ('download the audit first if you need to answer an access request'), and the refusal conditions. It stops short of naming the nearest alternative, contacts_suppress, so the choice between erasure and suppression is left 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 burden and does disclose real behavioral traits: the export is logged (audit side effect) and it is non-destructive to recordings and deleted content. It omits permission requirements, whether the export is synchronous, and any size/rate constraints, but the side-effect and negative-guarantee disclosure is meaningful.

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

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

Two tight sentences with the core purpose front-loaded and the clarifying constraint second. No filler; every clause 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?

No output schema exists, so the description should convey what the snapshot actually contains, but "retained evidence" and "audit snapshot" remain vague about the exported payload. Combined with 0% parameter documentation, the definition is adequate but leaves gaps for a 3-param export 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 0%, so the description must compensate. It implicitly documents the format parameter ("Markdown or structured JSON"), but adds nothing about the id vs workspaceId distinction or their expected values, leaving two required parameters unexplained.

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 (Export) and resource (the contact's retained evidence) plus the output forms (Markdown or JSON audit snapshot), which is far more specific than siblings like contacts_erase or contacts_history. It does not explicitly name which sibling to prefer for adjacent tasks (e.g., contacts_history, artifacts_export), 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?

The description provides negative scoping ("does not create recordings or recover deleted content"), which implicitly tells the agent when this tool is not appropriate. However, it never states when to use this over contacts_history or artifacts_export, leaving usage largely inferred.

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

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

No annotations are provided, so the description carries the full burden. 'Review' implies a read operation and 'Missing or deleted evidence is labeled' is a genuinely useful disclosure about return content, but it never states read-only/non-destructive behavior, retention scope, pagination, or permission requirements.

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

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

Two tight sentences, front-loaded with the resource and scope; the evidence-labeling note follows logically. No filler.

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

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

For a read tool with no annotations, no output schema, and no parameter descriptions, the definition covers the 'what' adequately but leaves return shape, ordering, pagination, and read-only guarantees 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 0%, so the description must compensate. It does convey that one parameter scopes to a single contact and the other to 'this workspace', which is the meaning of both parameters, but adds no format or lookup guidance for the UUIDs.

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 ('Review ... history ... for one contact') with a clear scope of what is aggregated (calls, conversations, outcomes, actions, follow-ups). It is distinguishable from contacts_list/contacts_export by being a single-contact history view, though it never names those siblings explicitly, which keeps it out of 5 territory.

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

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

The phrase 'for one contact' implies the use case but the description gives no explicit when-to-use, when-not-to-use, or alternative (e.g. contacts_list for browsing, contacts_export for bulk). An agent has to infer routing on its own.

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 it fails. Saying behavior matches "website, API and CLI" is circular and does not disclose what authorization is required, whether existing contacts are overwritten or duplicated, what happens on partial failure, or any rate limits.

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, but brevity here reflects under-specification rather than conciseness. The one substantive sentence is front-loaded after a redundant restatement of 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?

A bulk-mutation tool with no annotations, no output schema, and 0% parameter documentation needs far more: what is created/overwritten, validation failure semantics, and batch size behavior. None of that is present.

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

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

Schema description coverage is 0% for two required parameters, including a nested 500-item contact array with fields like destination, source, externalRef and eligibility that are entirely undocumented. The description adds no meaning for workspaceId or the contact object shape, so it does not compensate for the coverage gap.

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?

"SAGOT contacts.import" merely restates the tool name, and the only other sentence talks about authorization/validation parity rather than what the tool actually does. An agent learns nothing about the operation (bulk create contacts? upsert? merge?) beyond the verb implied by the name.

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

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

No when-to-use guidance at all. With siblings like contacts_update, contacts_erase, contacts_suppress and contacts_list, the description gives no condition for choosing import over those alternatives, nor any prerequisite or limit 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 alludes to authorization and validation equivalence but names no required scopes, permissions, rate limits, or pagination behavior, and never states that this is a read-only listing 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?

Two short sentences with no padding, but the first merely echoes the identifier and the second is only marginally informative, so the size reflects under-specification rather than disciplined brevity.

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 three-parameter listing tool with no annotations, no output schema, and no parameter documentation needs the description to cover pagination, filters, and return shape; none of these appear. The definition is far too thin for what an agent must know 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?

Schema description coverage is 0% across three parameters, so the description must compensate for limit, cursor and workspaceId — and it adds nothing at all about any of them. The schema's own defaults (limit 50, max 100) and cursor UUID format carry all available meaning.

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?

"SAGOT contacts.list" is essentially the tool name restated in dotted-path form; the description never says in prose that it lists contacts, what is returned, or what scope it covers. No differentiation from siblings like contacts_history, contacts_export or contacts_import, which all touch the same resource.

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 only guidance is "Uses the same authorization and validation as website, API and CLI," which speaks to auth parity, not to when this tool should be chosen over contacts_history, contacts_export, or contacts_update. No when-to-use or when-not-to-use condition is 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?

With no annotations the description carries the full behavioral burden. It usefully discloses that the suppression is 'permanent', a key irreversible trait, but says nothing about required permissions, whether it can be reversed, or what happens to already-scheduled calls. That partial disclosure lands at a 3.

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; the permanence caveat is included efficiently. It is perhaps too thin for a mutation tool, but there is no wasted wording.

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 permanent mutation with no annotations, no output schema and three fully undocumented required parameters, the description is too sparse. It omits the reason requirement, authorization needs, and the effect on existing/queued calls.

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

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

Schema description coverage is 0% and the description names none of the three required parameters. In particular the mandatory 'reason' field (1-200 chars) is never hinted at, so the description does not compensate for the undocumented 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 (suppress), resource (contact) and scope (from new calls in this workspace), so an agent can tell what it does. It does not differentiate itself from similar siblings such as contacts_erase or contacts_update, which is the only thing keeping it from 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?

The use case is only weakly implied by 'suppress ... from new calls'. There is no explicit when-to-use, no when-not-to-use, and no mention of the plausible alternative siblings (contacts_erase for deletion, contacts_update for editing), which is a real gap given how many contact tools 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure, and it fails. 'Uses the same authorization and validation as website, API and CLI' is a non-actionable assertion that does not say who can call it, what gets mutated, how the required revision field governs concurrency/conflict, 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?

It is short, but brevity here reflects under-specification rather than conciseness. Both sentences are near-zero-information, so there is no waste to trim but also nothing that earns its place for a 6-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 6 required parameters, no annotations, no output schema, and zero schema coverage, the description supplies nothing an agent needs to call it correctly. It is completely inadequate relative to the tool's 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?

All 6 parameters are required with 0% schema description coverage, so the description must compensate and does not. It mentions no parameter at all. Critical semantics are left unexplained: that 'revision' implies optimistic concurrency (so a stale value fails), and what 'source' and 'eligibility' mean as free-text 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 is essentially a restatement of the tool name ('contacts.update' -> contacts_update), which is a tautology. It never states what is actually updated, what fields are affected, or how this differs from siblings like contacts_suppress, contacts_erase, or contacts_import. The 'SAGOT' prefix carries no meaning for an 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?

There is no guidance on when to use this tool versus alternatives. With siblings such as contacts_erase, contacts_suppress, contacts_import, and contacts_history, the agent has no basis for routing. No exclusions, prerequisites, or context are provided.

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, and it delivers very little. It asserts parity of "authorization and validation" with website/API/CLI but says nothing about what is created, whether the secret is shown once, what permissions the caller needs, or whether the operation 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?

Two short sentences with no padding, and the operation identifier leads. It is appropriately sized but only because it says almost nothing; the brevity reflects under-specification 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?

For a mutation tool with three required parameters, no annotations, no output schema, and 0% schema coverage, the description should at minimum explain what a credential is and what the caller gets back. It leaves the agent without enough context to call the tool confidently.

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

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

Schema description coverage is 0% across three required parameters (workspaceId, name, scopes), and the description compensates with zero parameter information. It never explains that scopes accepts read/configure/publish/call/admin, nor what the credential name is used for, so nothing is added beyond the raw 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?

"SAGOT credentials.create" is a dotted-path restatement of the tool name, not an explanation. It never says what a credential is (API key, token, service account?) or how it relates to the sibling credentials_list and credentials_revoke, so an agent gains nothing beyond the identifier it already has.

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 prerequisites, and no mention of the sibling operations (credentials_list, credentials_revoke) that a caller would need to distinguish this from. The only contextual hint is that authorization/validation matches website, API and CLI, which is a permissions remark rather than usage 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?

With no annotations, the description must carry full behavioral disclosure. It mentions that authorization and validation match the website/API/CLI, which weakly implies an authenticated read, but never states whether this is read-only, whether it paginates, whether it returns secrets, or what happens on missing/invalid workspace. That leaves key behavioral traits undisclosed.

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 very short and front-loaded, which is good, but the brevity is under-specification rather than deliberate conciseness. Two terse sentences that mostly restate the name and assert parity with other interfaces without adding actionable 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 credentials-listing tool with no annotations, no output schema, and 0% schema description coverage, the description is drastically incomplete. It omits what is listed, the response shape, pagination, error behavior, and permission requirements, leaving the agent unable to safely and correctly invoke the 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 coverage is 0% and there is a single required parameter (workspaceId). The description gives no meaning to it, its format, or the scope implied by supplying a workspace. An agent has to rely solely on the parameter name and JSON Schema constraints, with no textual elaboration.

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 'SAGOT credentials.list' is essentially a name restatement with a namespace prefix, not a stated purpose. It does not explain that this lists credential records, what kind of credentials, or how it differs from credentials_create or credentials_revoke. The verb+resource is only inferable from the tool name itself.

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 guidance or mention of alternatives. One could infer that a 'list' operation is separate from create/revoke, but the description never states that, nor does it mention prerequisites like required permissions beyond a vague 'same authorization as website, API and CLI'.

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 states only that authorization/validation matches other surfaces, which is vague; it omits whether revocation is permanent, what happens to tokens already issued, error conditions, or rate limits.

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 and not bloated. However, the second sentence about website/API/CLI parity does not earn its place because it conveys no actionable information about invoking the 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?

This is a destructive mutation with no annotations, no output schema, and zero parameter documentation. The description discloses nothing about irreversibility, required permissions, or outcome, so an agent lacks the information needed to call it safely.

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?

Both parameters have UUID formats but 0% schema description coverage, so the description is the only place meaning could be added. It says nothing about what 'id' identifies (the credential) or how workspaceId scopes the operation, leaving the caller to infer.

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 is essentially the tool name restated ('SAGOT credentials.revoke'), a dotted identifier rather than a statement of what the tool does. It never says it revokes a specific credential or what a revoked credential becomes; the second sentence adds no purpose information.

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 indication of when to call this versus credentials_create, credentials_list, or similar revoke tools like invitations_revoke or members_revoke. The only context given ('same authorization and validation as website, API and CLI') is not usage 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?

With no annotations, the description carries the full behavioral burden, and "same authorization and validation as website, API and CLI" is near-vacuous — it does not specify what permissions are needed, that the operation is read-only, how pagination behaves, or what is returned. The cursor/limit schema hints at pagination but the description never explains 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?

It is short, but brevity here is under-specification rather than conciseness: the second sentence conveys almost no actionable information, and the opaque "SAGOT" prefix wastes the highest-value position. Two sentences that carry this little content are not earning their place.

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

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

For a paginated list tool with a required UUID scope parameter, no annotations, and no output schema, the description should at minimum explain pagination and what is listed. None of that is present, so an agent lacks what it needs to invoke this 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?

Three parameters exist with 0% schema description coverage, and the description mentions none of them — not the required workspaceId, nor the limit bounds, nor the cursor's role in paging. It neither documents parameters nor compensates for the empty schema, leaving the agent to infer everything.

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?

"SAGOT events.list" largely restates the tool name via a dotted namespace, and "SAGOT" is never defined, so the agent cannot tell what an "event" is or what domain this covers. The only other sentence is about authorization, not purpose, and it does nothing to distinguish this from the sibling events_replay.

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 events_replay or the many other *_list siblings, and no prerequisites or exclusions. The authorization sentence is context about how it behaves, not guidance on when to select 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, the description carries the full behavioral burden, and it discloses only that this retries an event with its original ID. It does not state whether the operation is idempotent, whether it can duplicate deliveries, what permissions are required, or what happens on a successful versus failed replay.

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 front-loaded sentence with no filler or repetition. It is efficient, though its brevity reflects under-specification rather than tightly packed information.

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

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

For a mutation tool with two required parameters, no annotations, no output schema, and zero schema coverage, the description is too thin. It omits workspaceId semantics, expected outcomes, error behavior, and any routing to sibling tools like events_list.

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

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

Schema description coverage is 0%, so the description must compensate, but it only clarifies the 'id' parameter as the original event ID. It never mentions workspaceId, leaving one of the two required UUID parameters with no semantic explanation beyond its name.

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 verb+resource ('Retry delivery of this event') and is clearly distinct from the sibling events_list, which lists rather than replays. The only weakness is that 'this event' is deictic and does not explicitly frame the operation as a mutation of an existing event by ID.

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 statement, no when-not condition, and no named alternative such as events_list for inspecting events before replaying. The retry framing implies the trigger is a previously failed delivery, but the agent is left to infer that entirely.

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. 'Uses the same authorization and validation as website, API and CLI' gestures at auth but never states what permissions are required, and it is silent on pagination behavior despite limit/cursor parameters.

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 no padding, so it is efficient in form. However, brevity here reflects under-specification rather than disciplined editing, and the 'SAGOT handoffs.list' prefix is redundant with the tool 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?

With no output schema, no annotations, and zero parameter documentation, the description would need to explain return shape and pagination to be usable. It does neither, leaving the agent without enough information to invoke the tool confidently.

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

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

Schema description coverage is 0% for three parameters (workspaceId, limit, cursor), and the description adds nothing about any of them. The agent gets no explanation of the workspace scoping requirement or cursor-based pagination semantics from either source.

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 only restates the tool name as 'SAGOT handoffs.list' with no verb or resource explanation of what a handoff is or what listing one returns. An agent cannot distinguish what this tool does beyond decoding the identifier, and no sibling differentiation (e.g., vs handoffs_update) is offered.

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, what prerequisites apply, or which alternatives exist. The only usage-adjacent claim is that authorization/validation match other surfaces, which does not tell the agent when this tool is the right choice.

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 behavioral burden. It hints at a mutation ('uses the same authorization and validation') but does not disclose that the tool modifies an existing handoff, whether the change is destructive or reversible, what concurrency/revision semantics apply, or what a status transition means. The claim that it uses 'the same authorization and validation as website, API and CLI' is unverifiable and adds no actionable 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 no wasted words, but the brevity is achieved by omitting essential information rather than by disciplined editing. Front-loading the tool name in dotted notation is not useful to an agent.

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 required-parameter mutation with 0% schema coverage, no annotations, and no output schema, the description is essentially empty. It omits the resource meaning, the mutation semantics, the concurrency model implied by 'revision', and the status enum purpose.

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

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

Schema description coverage is 0% across all five required parameters, so the description must compensate and it does not. It never mentions id, workspaceId, revision, status, or owner, nor explains the optimistic-concurrency role of 'revision' or the allowed status enum values.

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 says 'SAGOT handoffs.update' which only restates the tool name in a dotted form. It never states what a handoff is or what updating one does, nor does it enumerate the updateable fields (status, owner) that the schema requires. Compared to siblings like handoffs_list, an agent cannot distinguish the semantics beyond the obvious CRUD verb.

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 call this tool versus alternatives, no preconditions beyond the vague authorization note, and no mention of what a handoff lifecycle looks like. The single sentence about matching website/API/CLI validation gives no decision criteria.

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, yet it never states that this is a destructive/irreversible operation, what data is removed, whether calls or credentials are affected, or what permissions are required. "Same authorization and validation as website, API and CLI" gestures at an auth model but specifies nothing concrete.

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 short and not padded, but half of it (the namespace restatement) earns no place and the remaining sentence is vague rather than front-loading the actual effect of the call.

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 two-parameter mutation with no annotations, no output schema, and 0% schema coverage, the description supplies none of the information an agent needs: effect, reversibility, authorization requirements, or parameter meaning.

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

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

Schema description coverage is 0% and the description adds no parameter detail at all — it does not clarify whether "id" is the integration ID, a connection ID, or a credential ID, nor why workspaceId is required alongside it. Only the parameter names themselves provide any signal.

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?

"SAGOT integrations.disconnect" merely restates the tool name and its namespace; it never says what disconnecting actually does (tear down an OAuth connection, revoke tokens, delete stored config). The second sentence describes parity of authorization, not purpose. An agent cannot distinguish this from integrations_save/test/get on intent alone.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as integrations_save (reconnect) or integrations_test. The only hint is that authorization behaves like the website/API/CLI, which is not a usage condition.

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. The claim that it 'uses the same authorization and validation as website, API and CLI' gestures at auth behavior but never states what permissions are required, what errors can occur, or what is returned, leaving the agent with no actionable behavioral detail.

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 short, but length is not earned: the first sentence repeats the tool name and the second is uninformative filler about authorization. Neither sentence helps an agent understand or invoke the 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 required-parameter lookup tool with no annotations and no output schema, the description is completely inadequate. It omits what an integration is, what a successful response contains, and any error or not-found behavior.

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

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

Schema description coverage is 0% and the description adds nothing about the two required parameters. It never explains that 'id' must be an integration UUID or that 'workspaceId' scopes the lookup, so the agent gets no semantics beyond the raw JSON Schema types.

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 essentially restates the tool name ('SAGOT integrations.get') without saying what an integration is or what 'get' retrieves. It never distinguishes this from siblings like integrations_list, integrations_test, or integrations_save; the only added sentence concerns authorization, not purpose.

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

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

No when-to-use guidance at all. There is no mention of prerequisites, when to prefer integrations_get over integrations_list, or when a different tool is appropriate. The statement about authorization parity with website/API/CLI tells the agent nothing about selecting this tool.

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