Kinde MCP by usefulapi

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

Annotations only supply destructiveHint=true, leaving the description to explain the effect. It does add real value: 'Reversible by removing them' tells the agent the change can be undone via a sibling operation, and the operation is described as additive membership rather than a destructive overwrite. It does not mention idempotency, duplicate handling, or error behavior, keeping 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 sentences plus the endpoint, all front-loaded with the action and its optionality; nothing is redundant or 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-parameter mutation with no output schema, the description covers purpose, optional payload, reversibility and the underlying endpoint. It is close to complete, lacking only failure/duplicate semantics, which is a minor gap.

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

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

Schema description coverage is 100%, so id, roles, permissions and org_code are all documented in the schema itself. The description only restates that roles and permissions are optional, adding no format or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Add existing users to an organization') plus the optional role/permission payload, which lets an agent place it against list_organization_users and create_organization. It does not explicitly differentiate from the sibling grant_user_role_in_organization, 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?

'Add existing users' implies the prerequisite that the users must already exist in Kinde, and the mention of optional roles/permissions hints at when to use the richer variant. But there is no explicit when-not guidance or pointer to the granular grant_* siblings, so usage is only implied.

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

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

The only annotation is destructiveHint=true, and the description adds nothing about side effects, idempotency, duplicate-name behavior, or whether the new organization's id is returned. Notably it does not address the annotation's implication of a destructive operation for what is described as an additive create, leaving the agent with an unresolved tension.

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

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

Two short sentences, front-loaded with the action and resource. The endpoint reference is mildly redundant but harmless and compact.

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 three-parameter create with a fully described schema and no output schema, the essential call information is present. However, nothing is said about permission requirements, failure modes (e.g., name collisions), or what the successful response yields, which an agent would want before invoking a mutation.

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

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

Schema description coverage is 100%, so name, external_id, and feature_flags are already fully documented in the schema, including the nested flag-override object. The description adds no format or constraint detail beyond that, so the baseline 3 applies.

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

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

The description states a clear verb+resource (create a new organization), parenthetically clarifies the domain term as 'tenant', and even cites the backing endpoint POST /api/v1/organization. It distinguishes itself from read-oriented siblings (get_organization, list_organizations) by the 'create' verb, 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?

There is no guidance on when to use this versus kinde_add_users_to_organization or the other create_* siblings, no stated prerequisites (scopes, auth, plan limits), and no exclusions. The agent must infer usage entirely from the verb.

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

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

Annotations already declare destructiveHint=true, so the safety profile is covered structurally. The description adds no behavioral context beyond that: it does not say what happens if the key already exists, whether the call is idempotent, what auth is 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?

Two short, front-loaded sentences with no filler. The trailing 'Kinde: POST /api/v1/permissions' is mildly redundant with the name/title but is cheap and 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?

For a simple 3-parameter create tool with full schema coverage and no output schema, this is minimally adequate. However, it omits any mention of duplicate-key behavior or state effects, which matters given the destructiveHint annotation.

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

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

Schema description coverage is 100%, so key, name, and description are fully documented in the schema (including the note that key is used in tokens). The description adds nothing about these parameters, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Create a permission'), explains what the entity is for ('that roles and users can hold'), and appends the backing endpoint. It is clearly distinguishable from siblings such as kinde_create_role and kinde_list_permissions, though it does not explicitly call out those neighbors.

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

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

There is no guidance on when to use this tool versus alternatives like kinde_grant_user_permission_in_organization, nor any stated prerequisites or exclusions. Usage is only loosely implied by the tool name and verb.

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

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

Annotations only supply destructiveHint=true, so the description carries most of the burden. It discloses nothing about key/name uniqueness constraints, permission requirements, behavior on duplicate keys, or reversibility — all material for a create tool. The REST path is stated but adds little behavioral insight.

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

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

Two short sentences with the purpose front-loaded and no filler. The trailing 'Kinde: POST /api/v1/roles' is API trivia rather than agent-relevant guidance, but it is brief enough not to be a real cost.

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

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

There is no output schema, so the description should ideally say what the call returns (e.g., the created role's id/key) and whether the operation is idempotent. For a simple 4-param create the core purpose is covered, but the return side is a real gap.

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

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

Schema description coverage is 100%, so each of the four parameters is already documented in the schema. The description adds no extra meaning about required fields, key format, or default-role semantics; baseline 3 applies.

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

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

States a specific verb and resource ('Create a role') plus the downstream purpose ('can then be granted to users'), which distinguishes it from read-oriented siblings like kinde_list_roles. It does not explicitly contrast with the closest sibling, kinde_create_permission, but the resource noun is unambiguous.

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

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

There is no when-to-use guidance beyond the bare purpose statement. The phrase 'can then be granted to users' hints at a workflow order with kinde_grant_user_role_in_organization, but no alternatives, prerequisites, or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and the description's 'GET' framing is consistent with that. It adds genuinely useful return-shape information (client id and login URLs) since no output schema exists, but says nothing about not-found/error behavior or auth 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?

Front-loaded with the action and resource in the first sentence, and the return fields come immediately after. The trailing 'Kinde: GET /api/v1/applications/{application_id}' line is largely redundant restatement, a minor 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 one-parameter read tool with a readOnly annotation and no output schema, the description covers the purpose, the retrieval key, and the notable response fields. Only error/not-found semantics are absent, which is a small gap at this complexity.

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

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

Schema description coverage is 100% and the single parameter is fully documented in the schema, so the baseline is 3. The description's 'by id' adds no syntax or format detail beyond what the schema already conveys.

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 (fetch), resource (application), and retrieval mode (single, by id), which distinguishes it from the sibling kinde_list_applications without naming it. It also names the payload contents. It stops short of explicitly contrasting with the list sibling, so it isn't 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?

Uses 'single ... by id' which implies the tool is for fetching one known application rather than enumerating, but never states when to prefer this over kinde_list_applications or what to do if the id is unknown. Usage is inferable, not stated.

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

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

readOnlyHint=true already declares this a safe read; the description adds the returned fields and the operational framing ('cheap', credentials/audience check), which is genuine value beyond the annotation. No mention of auth scope requirements or caching, keeping it just under 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, zero waste, with the identity/scope stated first and the endpoint path last. 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?

With no output schema and no parameters, the description compensates by naming the returned fields (name, industry, timezone) and the endpoint. Nothing an agent needs to call this correctly 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 there is nothing for the description to disambiguate — baseline 4 applies. The description correctly implies no input is needed.

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 (Fetch) and resource (the Kinde business this token belongs to) plus the fields returned (name, industry, timezone). The 'this token belongs to' scoping cleanly distinguishes it from siblings like kinde_get_organization or kinde_get_application.

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 clear usage context — 'A cheap way to confirm the credentials and audience are right' — framing it as a validation/diagnostic call. It stops short of naming explicit alternatives or when-not-to-use conditions, so it is not a full 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?

The readOnlyHint=true annotation already establishes this is a safe read, so the description is not carrying the full burden. It adds the HTTP verb/path (GET /api/v1/organization), which corroborates read-only behavior, but says nothing about not-found errors, auth/permission requirements, or whether the call is scoped to the caller's environment.

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, front-loaded sentences with no padding; the core action leads. The trailing 'Kinde: GET /api/v1/organization' is mildly redundant for an agent that never makes raw HTTP calls, which keeps it from a perfect score.

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

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

For a one-parameter read tool with full schema coverage and readOnlyHint annotations, the definition supplies everything needed to invoke it correctly. Absent an output schema, it would help to hint at what an organization object contains, but that gap is minor for this complexity level.

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

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

Schema description coverage is 100% and the single org_code parameter is documented in the schema with an example. The description only restates 'by its org code' without adding format, case-sensitivity, or validation guidance, so baseline 3 applies.

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

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

States a specific verb (Fetch) and resource (a single organization) plus the identifier type (org code), which distinguishes it from kinde_list_organizations. However, it never names the sibling retrieval tools it competes with, so differentiation relies on the agent inferring that 'single' means 'not the list variant.'

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: 'single organization by its org code' suggests the lookup case versus the list case. There is no explicit when-to-use statement, no mention of what to do if the code is unknown, and no reference to alternatives like kinde_list_organizations.

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

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

Annotations already establish readOnlyHint=true, so the safety profile is covered. The description adds the useful behavioral note that the result can be expanded with organizations and identities, but says nothing about auth requirements, missing-user errors, or response shape.

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, the purpose and optional expansion are front-loaded, and the trailing API endpoint mapping is short and useful for tracing. 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 two-parameter read tool with full schema coverage and no output schema, the description is nearly sufficient; it could better describe what the response contains when expanded, 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 description coverage is 100%, so both parameters (user_id, expand) are already documented. The description's mention of 'organizations and identities' mirrors the schema's 'e.g. organizations,identities' and adds no new syntax or constraint, so the baseline 3 applies.

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

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

States a precise verb+resource ('Fetch a single user by id') and the scope ('single') implicitly separates it from the sibling kinde_list_users. An agent can identify the target 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?

Use is only implied: 'single user by id' suggests the one-record lookup as opposed to the list variants, but there is no explicit when-to-use or when-not-to-use guidance and no sibling is named.

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

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

The readOnlyHint=true annotation already tells the agent this is a safe read, lowering the disclosure bar. The description adds only the underlying Kinde endpoint path; it says nothing about pagination, result caps, or how empty results are represented. Useful traceability context, but not rich 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?

Two short sentences, front-loaded with the action and scope, with zero filler. The trailing endpoint path is slightly redundant for an agent that already knows the tool name, but it is compact and harmless.

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

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

For a read-only, two-parameter list tool with full schema coverage and a safety annotation, the essentials are covered. With no output schema, however, the description never indicates the shape of the returned permission data or whether the list can be paginated or truncated, which is a modest but real gap.

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

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

Schema description coverage is 100%, so both user_id and org_code are already documented in the schema. The description conveys only that one user and one organization are involved, adding no format, identifier-style, or defaulting detail beyond the structured fields. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description gives a specific verb+resource+scope: 'list the permissions one user holds in one organization.' This is unambiguous and separates it from broad permission-listing siblings like kinde_list_permissions. It does not, however, explicitly contrast itself with its near-twin kinde_get_user_roles_in_organization, 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?

Usage is only implied by the scope wording ('one user ... one organization'). There is no statement of when to prefer this over kinde_get_user_roles_in_organization or kinde_list_permissions, and no prerequisites such as required scopes or org membership. Adequate but with a clear routing gap given the crowded sibling set.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the description only needs to add context, and it does add that the result is scoped to a single user/organization pair. However it says nothing about return shape, pagination, or what happens if the user is not in the organization.

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, both earning their place: the first carries the meaning and scope, the second gives the underlying endpoint for developers. The endpoint reference is marginally redundant but not wasteful.

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

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

With no output schema, the description should ideally sketch what a role entry looks like (id, key, name) and whether the list is ever empty. Annotations cover the safety profile and the schema covers the inputs, so the definition is usable but leaves the return contract undefined.

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

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

Schema coverage is 100% and both parameters are documented there, so the baseline is 3. The REST path template restates how org_code and user_id slot into the resource hierarchy, which is mildly reinforcing but adds no syntax or format detail beyond the schema.

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

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

States a specific verb (List) and resource (roles held by one user in one organization), and the plain-language gloss 'what can this person do here?' pins down the scope precisely. It does not explicitly name the near sibling kinde_get_user_permissions_in_organization, so the roles-vs-permissions boundary is left to inference from the tool 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?

The gloss clarifies the intent of the call, which implies when to reach for it, but there is no explicit when-not guidance and no pointer to the sibling that returns permissions instead. A user asking 'what can this person do here?' may need both tools and the description does not say so.

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

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

Annotations already declare destructiveHint=true, so the safety profile is partly covered; the description adds the useful nuance that the grant is reversible and the exact backend endpoint. However, 'reversible' sits in tension with destructiveHint=true and is offered without explanation (no note on duplicate grants, idempotency, or required scopes), so the added behavioral context is thin rather than contradictory.

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 fragments, zero padding, with purpose leading and the endpoint mapping trailing. Minor deduction for the slight title/verb mismatch ('Give' vs 'Grant') and the terse 'Kinde:' prefix, which reads like an addressing artifact rather than prose.

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, no-output-schema mutation tool this is close to sufficient: purpose, reversibility, and endpoint are all present. What is missing is the failure/duplicate behavior and any permission prerequisites, which an agent would need before calling it in an edge case.

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 all three parameters carry descriptions, so the schema does the heavy lifting. The description restates the three inputs only through the endpoint template (org_code, user_id, permission_id) and adds no format, lookup, or constraint detail beyond that.

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 (give/grant) plus the exact resource pair (one user, one permission, one organization), and the REST endpoint mapping confirms the scope. It implicitly separates itself from kinde_grant_user_role_in_organization by naming 'permission' rather than 'role', but never names or contrasts that sibling explicitly.

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

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

Usage is only implied: an agent can infer this is the write-side counterpart to kinde_get_user_permissions_in_organization, but the description never says when to grant a permission vs. a role, nor what prerequisites (scopes, role membership) must exist first. The word 'Reversible' hints at an undo path but does not name the revoke 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?

Annotations already flag destructiveHint=true, so the bar is lower, and the description earns credit by disclosing reversibility and the underlying endpoint (POST .../roles). It still omits whether the call is idempotent if the role is already granted and whether org membership or permissions are required.

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: the purpose and scope come first, the undo path second, the raw endpoint last. Nothing is redundant.

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

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

With no output schema and annotations carrying the safety profile, the description covers what an agent needs to invoke it: purpose, singular scope, and rollback path. Minor gaps are the absence of prerequisite/org-membership conditions and collision behavior.

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

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

Schema description coverage is 100% and all three required ids are documented in the schema, so the baseline is 3. The description adds no format, lookup, or validation detail for org_code/user_id/role_id beyond the schema.

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

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

States a specific verb ('Give') plus resource ('a role') plus explicit scope ('one user ... one organization'), which cleanly separates it from kinde_grant_user_permission_in_organization and from the bulk kinde_add_users_to_organization. An agent can pick this 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?

Names the exact inverse operation (kinde_revoke_user_role_in_organization), which tells the agent how to undo the call, and the singular scope signals when this is preferred over the plural add-users sibling. It stops short of explicit when-not-to-use or prerequisite conditions.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description adds only the 'token audiences' domain framing and echoes the REST verb/path (GET /api/v1/apis), which is effectively a restatement of the name. No pagination, result ordering, auth scope, or result-shape behavior is disclosed.

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, purpose front-loaded with no filler. The second sentence (endpoint echo) is near-redundant but costs almost nothing.

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

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

For a zero-parameter list tool with no output schema, the description covers what the resource is but says nothing about the return payload, default limits, or pagination behavior. Adequate as a minimum-viable listing definition, but an agent cannot predict the response shape without calling it.

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

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

The tool takes zero parameters, so per the baseline there is nothing for the description to disambiguate. Schema coverage is 100% and the empty object is self-explanatory.

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 concrete verb+resource ('List the APIs registered as token audiences'), and the resource is clearly distinct from the sibling list_* tools (organizations, users, roles, permissions, applications). It stops short of naming an alternative or scope limits, but the purpose is unambiguous.

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

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

No when-to-use, when-not-to-use, or alternative is given. The agent must infer from the name alone that this is the tool for enumerating token-audience API registrations versus, say, list_applications.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds only a light detail (results carry application types) and maps to the underlying REST endpoint GET /api/v1/applications, but says nothing about result size, ordering defaults, or pagination 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 with the purpose front-loaded; nothing is padded. The second sentence is endpoint metadata rather than invocation guidance, but it costs almost nothing to include.

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 simple read-only list tool with full schema coverage, so the description is nearly adequate. However, with no output schema, it could say more about the shape of returned application objects (fields beyond 'types') and about paging, which the agent must infer from next_token.

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 all three parameters (sort, page_size, next_token) are fully documented in the schema itself. The description adds no parameter syntax or format detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb ('List') and resource ('applications registered in the business'), plus what each entry includes ('with their types'). It is clearly distinguishable from the singular sibling kinde_get_application, though it does not differentiate itself from the other list_* tools beyond the resource 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 over kinde_get_application (single lookup) or how it relates to the other list endpoints. Pagination semantics (next_token) exist in the schema but the description never mentions paging behavior or iteration.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered by structured data. The description adds that values are returned alongside flags and maps to the underlying endpoint, but says nothing about pagination, ordering, or result size.

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 tight sentence that front-loads the action and scope, followed by the endpoint mapping. The endpoint string is marginally redundant but useful for traceability; nothing else 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 simple read-only list tool this is close to sufficient, but with no output schema the description should say more about what the returned flags look like. 'with their values' is the only hint about the response shape.

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

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

The tool takes zero parameters, so the baseline is 4. There is no parameter information the description needs to supply, and it correctly avoids inventing any.

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 resource (feature flags) with an explicit scope qualifier, 'set at the environment level,' which separates it from the sibling kinde_list_organization_feature_flags. It stops short of naming that sibling, so the differentiation is inferred from scope 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 'environment level' scope implies when this tool applies versus the organization-level variant, but there is no explicit when/when-not statement or named alternative. Usage is left to be inferred from the scope phrase.

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

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

Annotations already declare readOnlyHint=true, so the safe-read posture is covered. The description adds one useful behavioral nuance — that these are overrides scoped to a single organization rather than all flags — plus the underlying endpoint, but says nothing about pagination, ordering, or how overrides differ from inherited values.

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

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

Two short sentences, front-loaded with the purpose and followed by the endpoint reference. Nothing is padded or redundant.

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

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

For a single-parameter, read-only list tool this is nearly sufficient: the scope and endpoint are clear and the annotations cover safety. The only omission is any hint about the shape of the returned flag list, which matters slightly since no output schema exists.

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

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

With 100% schema description coverage and a single parameter (org_code) already documented in the schema, the description adds no syntax, format, or sourcing detail beyond it. Baseline 3 applies because the schema carries the parameter burden.

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

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

States a specific verb and resource ("List the feature-flag overrides set for one organization") and scopes it to a single org, which implicitly separates it from the environment-level sibling kinde_list_environment_feature_flags. It stops short of naming that sibling explicitly, so differentiation requires the agent to infer from the "one organization" vs environment wording.

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

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

Usage is implied by "overrides set for one organization" and by the required org_code, but there is no explicit statement of when to reach for this tool instead of kinde_list_environment_feature_flags or any prerequisite/auth guidance. The agent must infer the org-scoped-vs-environment-scoped distinction.

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

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

readOnlyHint=true already establishes this as a safe read, so the bar is lower, but the description adds almost nothing behavioral beyond that. The 'Kinde: GET /api/v1/organizations' line is provenance, not disclosure — no mention of pagination behavior, result limits, or authentication 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 short sentences with no padding and the core action front-loaded. The trailing endpoint reference is arguably filler for an agent choosing a tool, but it costs little space.

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

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

For a simple read-only list tool with full schema coverage this is close to sufficient, but with no output schema the description could reasonably sketch the returned shape and the paged/non-paged nature implied by next_token. It leaves that entirely to inference.

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

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

Schema description coverage is 100%, so sort, page_size, and next_token are already fully documented in the schema; baseline is 3. The description adds no syntax, default, or usage hints for these parameters, so it neither helps nor hurts.

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

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

States a specific verb and resource ('List the organizations') and adds a useful terminology mapping by equating organizations with 'tenants'. It does not name or contrast any sibling such as kinde_get_organization or kinde_list_organization_users, so the agent must infer the distinction from the verb 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, when-not-to-use, or alternative guidance. Nothing tells the agent whether this is the entry point for browsing all orgs versus calling kinde_get_organization for a known id, nor when to page with next_token.

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

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

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the GET endpoint and the filterable behavior, but says nothing about pagination semantics (next_token/page_size) or result ordering, which matters for a list tool.

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

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

A single front-loaded sentence carrying the purpose and filters, followed by an endpoint reference. The endpoint string is mildly redundant but useful for API-aware agents, and there is 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?

With no output schema, the description does not need to explain return values, and it is a read-only list with full schema coverage. It is complete for correct invocation, with pagination behavior the only meaningful omission.

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

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

Schema description coverage is 100%, so every parameter including sort, roles, permissions, page_size and next_token is already documented in the schema. The description only echoes the two filter parameters, adding no syntax or format detail beyond the schema, so baseline 3 applies.

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

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

The description names a specific verb (list) and resource (users of one organization) and scopes it to a single org, which naturally separates it from the sibling kinde_list_users. It does not explicitly name the sibling it differs from, so it stops just short of full differentiation.

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

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

It states the optional filtering dimensions (permissions, roles), which implies when the tool is useful, but gives no explicit when-to-use/when-not guidance or alternatives such as kinde_get_user_roles_in_organization for per-user lookups. 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?

readOnlyHint=true already establishes that this is a safe read, so the bar is lower, but the description adds almost nothing behavioral: no mention that results are paginated via next_token, no indication of permission/auth requirements, and no note about ordering defaults. Only the tenant-wide '(business)' scope is a mild addition.

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, purpose front-loaded, nothing superfluous. The endpoint reference is compact metadata rather than padding, and there is no filler prose.

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

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

With no output schema, the description could reasonably say more about what a permission record contains and how paging should be driven, but the parameters are fully self-documented. It is adequate but minimal for a tenant-wide list endpoint.

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 all three optional parameters (sort, page_size, next_token) are documented in the schema with ranges and semantics, so the baseline of 3 applies. The description adds no extra meaning about parameter behavior or defaults.

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

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

States a specific verb+resource ('List the permissions defined in the business') and even names the backing endpoint, so the agent knows exactly what is returned. It does not explicitly distinguish itself from close siblings such as kinde_list_role_permissions or kinde_list_organization_users, 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 gives no when-to-use guidance, no prerequisites, and no pointer to alternatives like kinde_list_role_permissions for role-scoped permissions. Usage is only implied by the verb '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?

readOnlyHint=true already establishes this as a safe read. The description adds the underlying REST endpoint (GET /api/v1/roles/{role_id}/permissions), which is mild extra context, but says nothing about pagination behavior despite page_size/next_token parameters. With annotations covering safety, this is adequately but not richly disclosed.

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

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

Two short sentences, front-loaded with the operation and followed by the endpoint mapping. The endpoint sentence is mild redundancy but not wasteful; 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?

With no output schema and full parameter documentation in the schema, the description is roughly sufficient for a simple read-only list operation. It does not explain the returned collection shape or how paging tokens behave, leaving minor 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 100% – role_id, page_size and next_token are all documented in the schema. The description adds no meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb and resource with scope: 'List the permissions attached to one role.' The scoping phrase 'attached to one role' implicitly separates it from the sibling kinde_list_permissions, though no sibling is named 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?

No indication of when to choose this over kinde_list_permissions (global permission list) or kinde_get_user_permissions_in_organization. The scope phrase hints at usage but there is no explicit when/when-not guidance or prerequisite information.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying endpoint (GET /api/v1/roles), but says nothing about pagination behavior despite a next_token parameter, nor about ordering or result volume. Given annotation coverage, a 3 is appropriate.

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

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

Two short sentences, front-loaded with the purpose, with the endpoint reference tacked on as compact provenance. Nothing is wasted and nothing important is buried.

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

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

For a read-only list tool with full schema coverage and readOnlyHint already set, the description covers what is needed. The one gap is pagination semantics and result shape, which an agent must infer from next_token in the schema since no output schema exists.

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

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

Schema description coverage is 100%, so all three parameters (sort, page_size, next_token) are already documented in the schema. The description adds no syntax, default, or usage nuance beyond that, so baseline 3 applies.

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

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

States a clear verb+resource ('List the roles') and scopes it to roles defined in the business, which distinguishes it from per-user/per-org role listings like kinde_get_user_roles_in_organization. However, it does not explicitly name or contrast with those siblings, so differentiation is left to inference.

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

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

No when-to-use, when-not-to-use, or alternative routing guidance is given. An agent reading this cannot tell from the description alone whether to use it versus kinde_list_role_permissions or kinde_get_user_roles_in_organization; the only hint is the phrase 'defined in the business'.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description reinforces this by exposing the underlying GET endpoint, but says nothing about pagination behavior, default page size, or result ordering — all relevant for a cursor-paginated list.

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, purpose front-loaded, no filler. The endpoint reference is of marginal value but compact enough not to dilute the definition.

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 simple list tool with fully documented params and no output schema, so little is needed. However, the cursor-pagination workflow (how to iterate with next_token) and what the response contains are left entirely to the schema, leaving a modest gap.

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

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

Schema description coverage is 100%, so the schema already documents sort, page_size, and next_token thoroughly. The description adds no parameter meaning beyond that, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('List marketing subscribers'), and the API path confirms the resource is the subscribers collection. It's clear what the tool does, though it offers no differentiation from siblings — not strictly needed here since it is the only subscriber-listing tool.

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 mention of alternatives such as kinde_list_users for a different entity. The agent gets no routing help beyond the name.

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

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

Annotations already declare readOnlyHint=true, so the read-only safety profile is known. The description adds the underlying API endpoint 'Kinde: GET /api/v1/users' and the business scope, but discloses no additional behavioral traits such as pagination behavior, rate limits, or authentication 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 short sentences with the core purpose front-loaded and zero wasted words. The optional filter note and endpoint reference are compact and non-redundant.

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

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

For a simple list tool with five optional, fully described parameters and no output schema, the description covers the basic purpose and filtering. It does not mention pagination or result shape, but the schema's next_token and page_size parameters provide enough for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters thoroughly. The description only restates that email and user_id are optional narrowing filters, adding no syntax, format, or behavior beyond what the schema provides. Baseline 3 is appropriate.

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

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

States a specific verb ('List'), resource ('users'), and scope ('in the business'), plus optional filters. It implicitly differentiates from kinde_list_organization_users and kinde_get_user via the business-wide scope, but does not explicitly name or contrast 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 'optionally narrowed by email or user id' describes parameter usage, not when to choose this tool over alternatives. There is no explicit guidance on when to use it versus kinde_list_organization_users, kinde_get_user, or other list tools.

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