LocalTry AI CRM

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

Annotations already signal a non-read-only write tool, so the description is not required to restate mutation. It adds some useful context with 'authenticated business' and 'LocalTry domain rules and validation', but it does not disclose upsert semantics, overwrite behavior, or validation outcomes. The added context is positive but limited.

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

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

The description is a single, front-loaded sentence with no redundant filler. The final clause about LocalTry domain rules is slightly vague but not bloated, making it appropriately concise while still adding a hint of domain-specific behavior.

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 upsert operation with four parameters, an arbitrary values object, no output schema, and no param descriptions. The description does not explain the create/update decision, required parameter roles, validation rules, or return behavior, so an agent has too little context 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?

Schema description coverage is 0%, so the description carries the responsibility to explain parameters, but it mentions none of them. It does not clarify what 'values' should contain, what 'recordId' means for create vs update, what 'reason' is for, or how entityType selection works. The schema alone is left to carry all 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?

The description names a specific action ('Create or update') and a specific resource ('CRM record'), and distinguishes it from read-only siblings like search_crm. However, it does not clarify the condition that selects create vs update, or how this differs from other write tools, so it misses the top score.

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

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

No explicit guidance is given about when to use this tool versus alternatives, such as when to use search_crm for lookup before updating. The description only implies usage for CRM writes and does not mention when not to use it, how to choose between create and update, or any prerequisites.

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

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

Annotations only mark the operation as non-read-only and non-destructive. The description usefully adds the write-and-save behavior ('LocalTry writes and saves its tenant-scoped instruction') and the visibility outcome ('makes the agent available in Flow Studio'). No contradiction with 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 tightly written sentences, with the core purpose front-loaded and the behavioral detail in the second sentence. Every clause adds information; there is no boilerplate.

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

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

The description covers the creation flow and the final destination (Flow Studio), which is the key outcome an agent needs. However, there is no output schema and no mention of what the call returns, and optional parameters are left unexplained, making the context slightly incomplete for a 4-parameter creation 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?

With no schema-level descriptions, the description must carry parameter semantics. It clarifies that `duties` becomes the tenant-scoped instruction, and 'Create ... agent' implies `name`, but it gives no semantic help for `tagline` or `category` beyond their raw enum/default values. This only partially compensates for 0% schema coverage.

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

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

The description opens with a specific verb and resource: 'Create a reusable AI agent for the authenticated business.' It also names the deliverable (Flow Studio availability), which distinguishes it from sibling tools like create_or_update_crm_record or run_workflow. There is no ambiguity about what action the tool performs.

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 provides clear context for when to use the tool: whenever a reusable, tenant-scoped agent needs to be created for the current business. It does not explicitly contrast with alternatives or state when not to use it, 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful scoping: the activity is for the authenticated tenant and spans CRM actions, workflow runs, and workspace changes. It does not describe ordering, grouping, time window, or pagination behavior, but given the strong annotation coverage, a middle score 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?

The description is a single, front-loaded sentence that identifies the resource, the included activity types, and the tenant scope. There is no filler, redundancy, or restatement of the tool name or title.

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 one optional parameter, the description conveys the core purpose and scope. However, there is no output schema, and the description does not explain the return structure, define 'recent,' or clarify whether limit applies globally or per category. These gaps make the definition adequate but incomplete for an agent invoking it without additional 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?

There is one parameter, limit, and the description provides zero coverage for it. The schema supplies type, default, minimum, and maximum, so the parameter is not opaque, but the description does not clarify that limit applies to the number of returned activity items or how it interacts with the three activity categories. Because coverage is low and the description does not compensate, this is below baseline.

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

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

The description states the tool's function explicitly: 'Show recent CRM actions, workflow runs, and workspace changes for the authenticated tenant.' This identifies a specific resource and scope, distinguishing it from search_crm and get_workspace_overview. However, it does not explicitly name or contrast a sibling tool, so it stops short of full differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives such as search_crm, get_workspace_overview, or run_workflow. It states what the tool does but not when it is preferred, when it is not appropriate, or what conditions should route to a sibling 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 declare readOnlyHint=true and destructiveHint=false, and the description's 'Read' matches this. It adds value by enumerating what is returned: request, conversation, progress, questions, errors, and completed result, plus the 'latest' scoping. No contradiction with 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?

One sentence with no redundant words; the verb and resource are front-loaded, and the itemized result categories are compact. Every part of the 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 zero-parameter read-only status check with no output schema, the description provides enough to select and call it correctly: the exact request being read and the categories of information returned. It does not need to document return structure further because the description already lists the meaningful result contents.

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, and the empty input schema leaves nothing to document. The description's mention of the scope ('authenticated business's latest') is the only relevant semantic context, which is sufficient given there are no 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 names a specific verb ('Read') and a precise resource: the authenticated business's latest Customize Workspace request, including conversation, progress, questions, errors, and completed result. This clearly distinguishes it from siblings like request_workspace_customization (which creates a request) and get_workspace_overview (workspace-level view).

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 clear context: this is the status/result lookup for the most recent workspace customization flow, making it the natural counterpart to a prior request_workspace_customization call. It does not explicitly name alternatives or state when not to use it, so it falls just short of full routing guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds a meaningful behavioral guarantee: 'Secrets and raw database access are never returned.' This gives agents useful safety-relevant context beyond the annotations, though it does not describe the output shape or pagination 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 sentences with the primary action and resource front-loaded, followed by a list of contents and a safety exclusion. Minor redundancy exists between 'complete' and 'every registered,' but overall 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 zero-parameter overview tool with no output schema, the description provides the scope, content categories, and an important exclusion. It is sufficiently complete for an agent to understand what this tool returns and why it is safe, though a sentence about the result format would make it fully 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?

There are zero parameters, so the schema already covers all input concerns. The description adds useful context about the implicit scope ('authenticated business's'), satisfying the 0-params baseline of 4 without needing further parameter 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 states a specific verb ('Inspect') and a well-defined resource ('the authenticated business's complete LocalTry feature catalog'), then enumerates what that includes. It is clear and distinct from a generic 'overview' tautology, though it does not explicitly differentiate itself from siblings like list_workspace_versions or search_localtry_features.

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

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

The description implies this is the tool for a broad catalog inspection, but it gives no explicit guidance on when to use this versus siblings such as get_recent_activity, search_localtry_features, or get_workspace_customization_status. No alternative conditions or exclusions are 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the history is scoped to the authenticated tenant, but does not disclose behavioral details such as pagination via the limit parameter or ordering of returned versions. With annotations carrying the safety burden, this is acceptable but not enriched.

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 sentence with no filler words. It front-loads the primary action and object, and every word contributes meaning. This is an appropriately concise description for a simple list operation.

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

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

For a simple tool with one optional parameter, no required inputs, and no output schema, the description covers the core purpose and resource. The main gap is the lack of any mention of the limit parameter, but the schema supplies its constraints, so the overall context is nearly 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%, and the description does not mention the lone 'limit' parameter at all. Though the parameter name and constraints are self-explanatory to a degree, the description offers no compensation for the missing schema description, so the agent receives no explicit guidance on how limit affects the returned results.

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

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

The description uses a specific verb ('List') with a clear resource ('versioned customization history') and scope ('for the authenticated tenant'). This precisely distinguishes the tool from siblings like restore_workspace_version and get_workspace_customization_status, which perform different operations on related resources.

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

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

The description implies its use case (listing version history) but provides no explicit guidance on when to choose this tool over alternatives like restore_workspace_version or get_workspace_customization_status. The workflow context (e.g., 'use this before restoring a version') is left unstated, so usage is only implicitly derived from the tool's purpose.

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 indicate this is not read-only or destructive. The description adds useful behavioral context: the request is queued asynchronously, LocalTry owns the engineering work, and history/restore points are maintained. This goes beyond the structured fields and helps the agent predict what happens after the call.

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

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

The description is two sentences, front-loads the action, and every phrase adds information about scope or consequences. There is no redundant restatement of the tool name or properties.

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 annotations, the description covers the action and downstream ownership well. However, with no output schema it does not state what the caller receives (e.g., request ID or confirmation), and it misses the opportunity to point to get_workspace_customization_status for tracking the queued work.

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 0% schema description coverage, the description carries the burden for parameter meaning. It does add that 'request' is a plain-language text request, matching LocalTry's input, but it provides no examples or guidance on what makes a good request. The schema's min/max length constraints are still the main source of parameter detail.

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

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

The description opens with a specific verb, 'Submit', names the resource ('Customize Workspace builder'), and clarifies the input is a plain-language request. This clearly differentiates it from sibling tools like get_workspace_customization_status or restore_workspace_version.

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 explains that this mirrors the LocalTry 'Send request' action, but it gives no explicit guidance on when to choose this tool over siblings, nor any conditions or prerequisites. There is no mention of alternatives or when not to use it.

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

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

Annotations already declare destructiveHint=true, and the description is consistent with that, adding that the operation is gated on explicit approval and scoped to the authenticated tenant. It does not overstate safety or omit any behavioral contradictions.

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 contains the action, resource, scope, and prerequisite with no filler. Every phrase 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?

The tool is a destructive two-parameter action with no output schema, so the description should identify where versionId and approvalToken come from and the effect on the current workspace. It gives the approval prerequisite but leaves those operational details 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 0% and neither parameter is explained in the description. 'after explicit approval' vaguely points at approvalToken, but versionId's relationship to list_workspace_versions and the format/source of either value is absent.

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

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

The description uses a specific verb, 'Restore', and names the exact resource, 'an earlier workspace version', plus scope ('authenticated tenant') and prerequisite ('explicit approval'). This clearly distinguishes it from siblings such as list_workspace_versions, which only lists versions.

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 a clear prerequisite context: restore only after explicit approval, for the authenticated tenant. It does not name sibling alternatives or give a when-not-to-use clause, but the intent is unambiguous enough to route an agent.

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 (readOnlyHint=false, destructiveHint=true, openWorldHint=true) already signal mutation risk and an open capability set, so the bar for added value is met by the description's extra behavior: it 'verifies results' and 'asks for missing information instead of inventing it,' which sets accurate expectations about follow-up questions and honesty guarantees. It also adds the tenant-scoped constraint. No contradiction with annotations, though the destructiveHint is never echoed in prose.

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

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

Three sentences, each earning its place: core function, behavioral guarantees, and routing caveat. Front-loaded and free of fluff or schema repetition.

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

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

For an open-world dispatch tool with no output schema, the description covers the invocation contract, scope, verification behavior, and the search-first workflow. The main gaps are the undocumented history parameter and no account of return values, but both are minor given the tool's delegation model and the context signals provided.

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 the two parameters. It implies prompt is a natural-language request for a desired capability and hints that incomplete prompts will trigger clarification, but it never names or explains the history array or how it should be populated. Partial compensation at best.

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 pair: 'Use any AI-ready LocalTry feature' through the 'live capability registry,' and clarifies this is a generic dispatch tool where 'LocalTry chooses and executes its own tenant-scoped domain action.' It differentiates from the sibling search_localtry_features by instructing the agent to search first when unclear. Not a 5 because the concrete domain-action space is left open and no explicit contrast with the run_workflow sibling is drawn.

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

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

Gives one explicit routing rule: 'Search the feature registry first when the requested capability is unclear,' which points the agent to the relevant sibling search_localtry_features as a prerequisite step. The description implies this tool is the execution step that follows registry lookup, but it never states when to avoid this tool or how it compares to run_workflow. Useful but partial 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?

Annotations already carry destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds genuinely useful context beyond that: publishing and communication steps still enforce their own approvals, telling the agent that some workflow steps may not execute unconditionally. This is consistent with the annotations, not 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?

Two sentences and roughly 20 words, with the core action and scope front-loaded and a single valuable caveat following. Every sentence earns its place; there is no fluff or 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?

The description covers the core action and one behavioral nuance, which is adequate for a simple run command. However, for a destructive, open-world tool with an undocumented nested input parameter and no output schema, it leaves real gaps: what shape the input should take and what the call returns are both 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 0%, so the description bears the full burden of explaining parameters. It only implies that workflowId identifies the saved workflow; the `input` object — its structure, purpose, and how it maps to workflow inputs — is entirely unexplained. This is a meaningful gap for an agent preparing a call.

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?

"Run one saved workflow belonging to the authenticated tenant" states a specific verb (Run), a specific resource (saved workflow), and a scope constraint (authenticated tenant). This naturally distinguishes it from siblings like create_workflow_agent and run_localtry_command by resource type, though it does not name those alternatives 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 when-to-use or when-not-to-use guidance is provided, and no sibling is named as an alternative. The tenant scoping offers mild context, but the description never tells an agent how to choose between this tool and run_localtry_command or create_workflow_agent. The approval sentence is a behavioral note, not usage-routing guidance.

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

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

Annotations already signal read-only safety; the description adds concrete behavioral detail: queries are tenant-scoped, chosen by the server, and raw SQL/tenant identifiers are rejected. This goes beyond the annotations and helps the agent understand what input will be accepted.

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 first establishes purpose, the second adds an essential safety/input constraint. No filler or redundant restatement of annotations.

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

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

Adequate for a simple search tool, but incomplete for a 3-parameter schema with no output schema: it doesn't describe how `entityTypes` narrows the search or what the result set looks like. The safety constraint is useful, yet parameter semantics and return behavior remain under-specified.

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 property descriptions are absent (0% coverage), and the description only broadly constrains the query (no raw SQL, no tenant IDs). It says nothing about `limit` or `entityTypes`, relying on the agent to infer their meaning from names and 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?

States a specific verb ('Search'), resource ('authenticated business's CRM'), and scopes it to tenant-safe behavior. This clearly distinguishes it from create/write or workspace tools. No ambiguity about what action it performs.

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 that this is the tool for searching the authenticated business's CRM. It doesn't name sibling tools or formal exclusions, but the CRM resource and safe-query constraint give adequate context for selection.

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 destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: it queries the 'live' capability registry and promises 'without exposing secrets.' This gives the agent an important trust/security boundary.

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

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

The description is a single, front-loaded sentence that states the core purpose immediately. The long list of return types is slightly dense but each item is meaningful, and there is no filler or repetition of 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, the description does explain the categories of returned data and the no-secrets rule, which is helpful. However, it omits practical invocation details such as query syntax, kind value guidance, limit behavior, and response structure, leaving an agent with a moderate gap when calling 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 description coverage is 0%, so the description must compensate, but it does not directly explain the query, kind, or limit parameters. The mention of 'pages, actions, agents, integrations' loosely maps to the kind enum, but the agent is left to infer how to construct a valid query or how limit affects results.

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

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

The description uses 'Search' with a specific resource, 'the authenticated business's live LocalTry capability registry', and enumerates exactly what is returned. It clearly distinguishes this from sibling tools like search_crm (CRM records) and run_localtry_command (executing commands).

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 choosing an action' provides clear contextual timing, implying this tool is a discovery step. It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an agent to understand the intended slot in a workflow.

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