LMGram

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat these. The description adds the context 'linked to the connected account', which is helpful but does not disclose further behavioral traits (e.g., no mention of authentication requirements or rate limits).

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

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

The description is a single, concise sentence with no wasted words. It is front-loaded and clearly communicates the tool's purpose.

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

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

The tool has no output schema, and the description does not mention return value contents (e.g., fields like name, email, id). For a simple profile retrieval, this may be sufficient, but the description could be slightly richer to prepare the agent for the response structure.

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 no parameters, and schema description coverage is 100% (trivially). The description does not need to add parameter semantics. Baseline 4 is appropriate as the schema already fully covers the absence of 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 'Returns the LMGram profile linked to the connected account' clearly states the verb (returns) and resource (LMGram profile). The tool is distinct from siblings which deal with matching, messages, and chat, leaving no ambiguity.

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 use when the connected account's profile is needed. No explicit exclusions or alternatives are given, but the context of siblings (list_match_requests, etc.) makes usage clear. A perfect score would require explicit when-to-use or when-not-to-use 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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about recency and user scoping, but it does not disclose additional behaviors like ordering, pagination, or the shape of the response.

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, well-structured sentence conveys the core action, scope, and filtering options without redundancy or extraneous detail. Every clause earns its place.

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

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

For a simple read-only list operation with three optional parameters and no output schema, the description covers the key invocation details: what is listed, whose data, and how to filter. It could be slightly more complete by explaining the default response ordering or what a match request contains, but nothing essential is missing for a correct basic call.

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

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

Schema description coverage is only 33%, so the description needs to compensate. It does clarify that role and status are optional filters, which adds meaning beyond the enum lists, but it does not mention the limit parameter or its role in controlling result size. This is a partial compensation for the low 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 clearly identifies the verb 'Lists', the resource 'match requests', and the scope 'current LMGram user'. It is immediately distinguishable from sibling tools like list_messages and request_human_match by the explicit resource type and read-only intent.

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 when to use the tool—whenever a user needs to see their recent match requests—and mentions optional filters. However, it does not explicitly contrast it with sibling tools such as request_human_match or start_chat, nor does it state any conditions where an alternative should be preferred.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable context about end-to-end encrypted payloads being represented by a safe placeholder, which is not apparent from the annotations or schema.

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

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

Two short sentences, immediately stating the purpose and adding a critical caveat. No filler 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?

Given the simple structure (1 param, read-only, no output schema), the description is mostly complete. It explains the core behavior and the encryption placeholder. However, it does not mention ordering, pagination, or return format, which could be relevant for a list operation.

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

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

The input schema has one required parameter, chatId, with no description. The tool description does not explain what chatId refers to or any format/constraints. With 0% schema description coverage, the description should compensate but does not.

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

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

The description clearly states 'Lists messages in a LMGram chat' with a specific verb and resource. It also adds a useful caveat about encrypted payloads, and it is easily distinguished from siblings like list_match_requests or send_message.

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

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

There is no explicit guidance on when to use this tool vs alternatives or when not to use it. The description implies it is for viewing chat messages, but does not mention any exclusions, prerequisites, or alternative tools.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description reveals important behavioral constraints: it is opt-in, excludes romance/dating, and prohibits sensitive data like secrets or API keys. This adds privacy/trigger context not captured in annotations. It doesn't contradict annotations, though it could further clarify side effects (e.g., persistence or notification).

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

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

Three compact sentences, front-loaded with the core purpose, then usage boundaries and data-safety instructions. Every sentence adds value with 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?

The description nails the trigger and safety constraints, but with 8 parameters and no output schema, it leaves gaps: no explanation of matchType/sensitivity/maxCandidates, and no indication of what the response/result looks like or next steps. It is adequate for a well-scoped tool but not 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?

Schema description coverage is only 38%, with descriptions for need, topic, and summary but no descriptions for urgency, language, matchType, sensitivity, or maxCandidates. The description repeats some schema constraints (non-sensitive summary, no dating) but adds no new meaning for the five undocumented parameters, so it doesn't compensate for the low coverage.

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

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

The description clearly states the tool creates an 'opt-in LMGram human match request' and specifies the exact trigger ('only after the user explicitly asks to use LMGram to find a collaborator, peer, mentor, or helper'). It distinguishes itself from sibling tools by focusing on match requests rather than messages/chats, and explicitly excludes dating/romantic use.

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

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

Provides explicit when-to-use guidance ('only after the user explicitly asks'), clear exclusions ('Never invoke for general advice, dating or romantic matchmaking'), and even instructs on the preprocessing step ('ask for a minimized non-sensitive summary first'). This goes beyond a general hint and gives actionable direction.

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 mutation (readOnlyHint=false) and non-destructiveness. The description adds no further behavioral context, such as side effects, authorization needs, or rate limits.

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

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

The description is a single, concise sentence that is front-loaded with the key action. No redundant words or unnecessary detail.

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

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

Given the tool's simplicity and lack of output schema, the description is too sparse. It omits parameter explanations and any context about message limits, formatting, or expected 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?

The input schema has 0% description coverage, and the description does not explain the purpose or format of chatId or body. The agent receives no guidance on parameter values.

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

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

The description clearly states 'Sends a message into a LMGram chat,' specifying the action (sends) and the resource (message into a chat). It effectively distinguishes from sibling tools like list_messages and start_chat.

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

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

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context for invocation.

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 indicate the tool modifies state (readOnlyHint=false) and is non-idempotent, but the description adds minimal behavioral context beyond 'starts a chat'. It does not describe side effects, state requirements, or error conditions. Acceptable given annotations, but could be more informative.

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

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

Single sentence is concise and front-loaded. However, the phrase 'or records that this side wants to chat' is somewhat redundant and could be split for clarity. Still, no wasted words.

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

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

Given the absence of an output schema, the description should clarify what the tool returns or what side effects occur (e.g., whether a chat is created immediately or a request is queued). The ambiguity about 'records' versus 'starts' leaves the behavior unclear for an agent.

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 50% with only 'body' described. The tool description adds no information about parameters, especially the required 'matchRequestId', leaving its purpose ambiguous. The description should clarify what a match request ID represents and how to obtain it.

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

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

The description clearly states it starts a chat for a match request, which distinguishes it from sibling tools like 'send_message' or 'list_messages'. However, the addition 'or records that this side wants to chat' introduces slight ambiguity about whether it always creates a chat or just logs intent.

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 on when to use this tool versus alternatives like 'send_message' or 'request_human_match'. The context of being for a match request is implied, but without exclusion criteria or prerequisites.

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