glim.sh

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds valuable behavioral details: the marketplace is parsed from the URL host, tracking junk is ignored, and format affects output structure. No 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?

The description is a single, well-structured paragraph that presents the main purpose first, then details about the URL and return fields. It is informative without unnecessary verbosity, though could be slightly more terse.

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?

Despite no output schema, the description thoroughly lists all major return fields (title, price, stock, etc.) and distinguishes text vs JSON format. Given the tool's complexity and two parameters, the description is complete enough for an agent to understand what to expect.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining that 'ref' must be a full URL carrying the marketplace and rejecting bare ASINs, and that 'format' controls whether offers[] and images[] are included. This adds practical guidance.

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 fetches Amazon product detail from a full product URL, listing specific returned fields (title, price, etc.) and implicitly distinguishes from glim_amazon_search by requiring a URL rather than search terms.

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 the URL should come from a glim_amazon_search 'url' field or any /dp/<ASIN> page URL, and that bare ASINs are rejected. It does not explicitly state when not to use this tool or mention alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by explaining default text output, JSON option, and client-side re-rank behavior for 'most_reviewed' sort, which is not covered by 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?

Extremely concise: two sentences with no wasted words. Front-loaded with the most important constraint (pass exactly one). Every sentence adds essential guidance.

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 9 parameters and no output schema, the description covers all key points: parameter selection, sort behavior, format options, TLD list, and links to sibling tool. No gaps remain for correct usage.

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%, baseline 3. The description adds critical meaning: mutual exclusivity of query and category_slug, client-side vs server-side sorting, and format differences (image_url only in json). This significantly aids correct invocation.

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 searches Amazon across multiple TLDs, returns specific fields, and distinguishes from the sibling tool glim_amazon_get for drill-down. The verb 'search' and resource 'Amazon' are specific.

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

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

Explicitly instructs to pass exactly one of query or category_slug, recommends pairing sort_by='most_reviewed' with min_reviews for trust-weighted results, and suggests using glim_amazon_get for further drill-down.

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?

Goes well beyond annotations by disclosing cost scaling (~$0.06 per 1,000 words standard, ~$0.60 premium), minimum fee, tier-specific max lengths, and the automatic premium-class analysis for texts under ~100 words. These behavioral details are not available from the readOnlyHint/idempotentHint annotations and are critical for cost-aware invocation.

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 dense paragraph with front-loaded purpose. Every sentence adds substantive information about output, use cases, tier differences, or pricing. It is longer than ideal, but the complexity of the tool warrants the detail; a more structured format (bullets) would improve skimmability.

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?

Without an output schema, the description fully explains return values: verdict, confidence, fractions, and segment breakdown. It covers constraints (max length, min length), tier-specific behavior, cost model, and practical usage guidance. No critical information about what the tool returns or how it behaves 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 baseline is 3. The overall description adds value by explaining the financial implications of the tier parameter and the short-text auto-upgrade to premium, which affects how the agent should set tier. It does not restate schema details, but it provides cost-based context that enriches parameter selection.

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 'Detect AI-generated text' and details the full output: an overall verdict (AI/human/mixed), confidence, fractions, and a segment-by-segment breakdown. This clearly states the tool's function and distinguishes it from sibling tools, which are all get/search operations for web platforms.

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

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

Explicitly states when to use: 'Use it to verify whether content (comments, articles, profiles) is AI-generated, or to check text before publishing to see which segments would trip AI detectors.' It also provides tier guidance (standard vs premium) with cost and accuracy differences, helping the agent choose the right mode.

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 and idempotentHint; the description adds behavioral detail on specific endpoint behaviors (e.g., returns metadata+README for repo, changed files for PRs) without contradicting 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?

The description is long and packed with detail, which is useful, but could be more concise by separating the general fetch purpose from the exhaustive list of URL patterns.

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

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

Given no output schema, the description covers return formats and behaviors for multiple endpoint types, making it fairly complete for a fetch tool.

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

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

Schema coverage is 100%; the description adds significant meaning to the 'ref' parameter by enumerating all supported URL patterns, going beyond the schema's brief description.

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 begins with a specific verb ('Fetch') and resource ('GitHub data from a single ref'), and lists distinct URL patterns that differentiate it from sibling tools like glim_github_search.

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 extensive guidance on various URL patterns and what they return, but does not explicitly state when to avoid this tool in favor of siblings like glim_github_search.

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 readOnly, openWorld, idempotent, non-destructive. Description adds details: returns compact text by default, query inference logic, limitations (e.g., not supported in code search). No 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?

Front-loaded with purpose and well-structured, but slightly verbose. Every sentence adds value; could be more terse or use bullet points but still effective.

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?

Covers all aspects: purpose, query syntax, parameter details, inference, limitations, return format. No output schema but description explains output is compact previews. Recommends sibling tool for full content.

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 100%, but description enriches each parameter with examples, warnings, and explanations beyond schema (e.g., query syntax, kind inference, repo scoping interaction).

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?

Clearly states the tool searches GitHub repositories, conversations, or code with full GitHub search syntax. Distinguishes from sibling glim_github_get (which retrieves full content) and other platform-specific search tools.

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

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

Provides explicit guidance for each kind: use minimal keywords for repos, one literal pattern for code, omit sort for conversations. Explains inference of kind from query and directs to glim_github_get for full content. Includes not-supported features in code search.

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 declare read-only, idempotent, non-destructive, so safety is clear. The description adds that posts return comments and subreddits/users return profile plus recent activity, but lacks specifics like subreddit listing behavior (sort, limit, pagination) or user activity scope. Adds some context beyond 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?

The description is a single sentence that efficiently covers three entity types and their return behavior. No filler or unnecessary words; every part adds value.

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

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

Given 11 parameters and no output schema, the description covers high-level behavior but omits details on subreddit/user responses (e.g., they include listings with sort/limit parameters) and pagination. Adequate for a basic understanding but incomplete for full context.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not elaborate on parameters beyond the schema; it only mentions return behavior for different ref types. No additional parameter meaning is provided.

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 specifies the verb 'Fetch' and the resource: Reddit post, subreddit, or user by ref. It distinguishes behavior among entity types: posts return comments, subreddits and users return profile metadata plus recent activity. This differentiates from sibling tools like glim_reddit_search.

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 usage when a ref is available but does not explicitly state when to use this tool versus alternatives like search. No when-not-to-use or exclusion criteria are provided, leaving the agent to infer context.

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

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context: results include top comments, default textual output, optional JSON format, and pagination via cursor. No 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?

Four concise, front-loaded sentences. Each sentence adds distinct value: main purpose, output format options, sibling tool reference, and pagination with docs link. No fluff.

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 search tool with 8 parameters and no output schema, the description sufficiently covers result content, output formats, pagination, and refers to docs for details. It also maps to sibling tools.

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

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

Schema provides full parameter descriptions (100% coverage). The description adds value by reinforcing default format 'text', explaining the cursor parameter usage, and noting that passing format='json' yields structured data.

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 searches Reddit posts and specifies that results include full post content and top comments. It distinguishes from the sibling tool glim_reddit_get, which is for a single post's comment tree.

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 advises using glim_reddit_get for deeper comment tree needs and implies that a single search often suffices. However, it does not explicitly state when not to use this tool.

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

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

The description goes well beyond the annotations, adding critical behavioral details: media URLs 'expire within hours - fetch promptly, never store', posts are returned 'newest-first', pagination uses 'before=<next_cursor>', and comment windows are limited. These are operational nuances that an agent needs to handle correctly, and they align with the readOnly/idempotent annotations without contradiction.

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 moderately long but information-dense. It front-loads the core purpose and then organizes details by channel refs, post refs, media URLs, and limitations. Every sentence contributes useful information, though it could be slightly more structured (e.g., bullet points) for easier skimming. Overall it's appropriately sized given the tool's complexity.

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 return values for both reference types, pagination, search, output formats, media expiry, and accessibility constraints. Since there is no output schema, the description effectively communicates what the agent can expect in the response. It is complete for a read-only fetch tool with rich annotations and a well-documented schema.

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

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

The schema already provides 100% description coverage for all 8 parameters, so the baseline is 3. The tool description adds meaningful interaction semantics: explaining that 'before' comes from 'next_cursor', that query searches within the channel's full history, and that 'format' trades off token usage vs. structured data. This adds value beyond the schema's per-parameter descriptions.

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

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

The description clearly states the tool's function: 'Fetch a public Telegram channel or post - no account or API key involved.' It distinguishes between channel refs and post refs, and explicitly contrasts with the sibling tool glim_telegram_search by focusing on fetching specific resources rather than searching. The verb+resource pattern is specific and 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?

The description provides clear context for when to use the tool: when you have a public channel or post reference. It also gives an exclusion: 'Only channels with a public web preview work... private channels and groups are not accessible.' However, it does not explicitly mention alternative tools like glim_telegram_search for discovery use cases, so it lacks explicit when-not-to-use guidance relative to siblings.

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

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

Annotations already mark the tool as readOnly, openWorld, idempotent, and non-destructive. The description adds valuable context about the 'semantic web index scoped to t.me' and the 'discovery' nature, warning that results may be limited. No contradiction; it goes beyond annotations by explaining the index scope and historical nature.

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 focused sentences: first states purpose and scope, second gives crucial usage guidance and sibling reference. No fluff, front-loaded with the verb and resource, and earns its place with actionable advice.

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 search tool with 3 parameters and no output schema, the description covers scope, limitations, and integration with glim_telegram_get. However, it doesn't specify the structure of returned results (e.g., whether it returns handles, channel names, or how many). Annotations and format parameter partially compensate, but a brief mention of result contents would improve completeness.

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

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

Input schema already provides 100% coverage with clear descriptions for query, kind, and format. The description adds context for the overall discovery purpose and relationship to get, but does not explain parameter semantics beyond what the schema already states. Schema carries the load, so a baseline of 3 is appropriate.

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

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

The description clearly states it 'Search Telegram' and details two specific discovery modes: channel directory lookup and indexed public post/channel pages. It distinguishes from siblings by noting this is a discovery tool, explicitly contrasting with glim_telegram_get for live posts/history.

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 guidance on when to use this tool ('find the right channel here') and when to use the alternative glim_telegram_get for live posts or in-channel search. The tip about Telegram's lack of global text search frames the tool as a discovery starting point.

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 non-destructive behavior. The description adds valuable context: default output format (compact human-readable), option for JSON, behavior of expand_urls (response growth warning), and details on what each ref type returns (thread context, recent tweets). No 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?

The description is concise (3 sentences) and front-loaded: first sentence states purpose and key capability, second details ref types, third explains output format and numeric id handling. 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 7 parameters with good schema descriptions and no output schema, the description covers the main return characteristics (tweet with thread, user with tweets, default vs JSON format). It lacks explicit details on the structure of the compact view, which would be helpful, but is still fairly complete for a get tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds usage context (e.g., 'prefer full URLs' for ref) and behavioral warnings (expand_urls impact), but the parameter schemas already describe each field well. The additional value is moderate.

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 fetches a tweet or user from a reference, distinguishing between tweet URLs (including handle-less /i/status/<id>) and profile URLs. It differentiates from sibling tools like glim_twitter_search by focusing on retrieval of specific items.

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 guidance on when to use the tool (fetch a tweet or user) and offers practical advice (prefer full URLs, numeric ids as quoted strings). It hints at alternatives through the expand_urls parameter description (suggesting glim_web_fetch for targeted crawls), but does not explicitly exclude other tools like glim_twitter_search.

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 read-only, idempotent, non-destructive behavior; description adds clarity on default output format and the effect of the format parameter. No 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?

Three targeted sentences, each adding unique value: action, format guidance, and cross-references. No redundancy.

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

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

Provides enough context for an agent to understand usage and output variability, but lacks explicit output structure details (mitigated by format options). Cursor pagination behavior is noted in schema but not in description.

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

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

Schema description coverage is 100% with detailed parameter descriptions. Description adds context on output format defaults and cross-references, but does not significantly expand on schema descriptions.

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

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

Clearly states 'Search Twitter/X' as the primary action, distinguishes from sibling tool glim_twitter_get for full thread context, and mentions output format options.

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

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

Explicitly advises when to use glim_twitter_get for thread context, references search operators documentation, and hints at format selection based on use case.

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, idempotentHint=true. The description adds critical behavioral details: auto-tier SSR handling, paywall detection, stealth profiles, outcome codes, truncation with download URL, and permanently unsupported targets. No contradictions 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?

The description is long but well-structured, front-loading the main action and outcome classification. Every sentence adds value, though some technical details (e.g., list of unsupported targets) could be condensed without losing clarity.

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?

Despite no output schema, the description fully documents return format (markdown with YAML frontmatter), outcome codes, truncation behavior, and unsupported targets. It covers edge cases and context needed for correct invocation, making it highly complete for a complex 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?

Input schema has 100% parameter coverage, but the description adds meaningful context: it clarifies that `json` format returns a structured SSR blob for specific sites, and `selector` scopes extraction. This goes beyond the schema's brief descriptions, earning a 4.

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 fetches a single web page and extracts clean content, with a specific verb ('Fetch') and resource ('web page'). It distinguishes from sibling tools (e.g., glim_reddit_get, glim_youtube_get) by focusing on arbitrary URLs rather than platform-specific endpoints.

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 extensive usage guidance: it lists supported and unsupported sites, outcome classification, truncation behavior, and when to use different formats. It implicitly distinguishes from siblings by covering general web fetching vs. platform-specific 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?

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context: semantic vs. exact matching, default compact text format, and the effect of format='json'. No 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?

Concise and well-structured: first sentence states purpose and output, then format options, then relation to sibling tool, then behavioral quirk. Every sentence adds value without 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?

Despite no output schema, description adequately explains return format (compact text with titles/URLs/excerpts; JSON with full data). Covers parameters, edge cases (no match), and provides usage context. Complete for a search tool.

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

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

Schema coverage is 100%, but the description adds meaning for each parameter: query's semantic nature, format output differences, exclude_domains with examples, include_domains example, and published_within_days usage tips (common values, caution about metadata). Significantly enhances schema.

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

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

The description clearly states it is a 'Semantic web search powered by Exa' and specifies returned data: titles, URLs, and top excerpt. It distinguishes from sibling tools like glim_web_fetch and other domain-specific searches.

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

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

Explicitly states when to use glim_web_fetch for full page content. Also explains semantic matching behavior: returns nearest neighbors even if no exact match, advising to judge relevance from excerpts rather than result count. Provides clear 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?

Adds significant context beyond annotations, including server-side cleaning (deduplication, stripping tags, timestamps), size reduction, inline vs download_url fallback for long videos, and origin fallback with double-API-call note. 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?

Single paragraph is front-loaded with purpose. Every sentence adds value, but could be more scannable with bullet points. Still efficient and well-structured.

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

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

For a 4-parameter tool with 100% schema coverage and no output schema, description covers return values (inline text or json with metadata and download_url), caching behavior, and fallback logic. Very complete.

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

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

Schema coverage is 100%, and description adds meaningful context for each parameter: ref (URL or ID), format (inline vs json with size limits), origin (fallback behavior), language_code (ISO code). Goes beyond schema descriptions.

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

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

The description clearly states it fetches a YouTube video transcript from a URL or ID, using specific verbs and resource. It distinguishes from sibling tools which are for other platforms (Amazon, GitHub, etc.).

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 clear context on when to use (fetching transcripts) and details on formats, origins, and caching. Does not explicitly mention when not to use or alternatives, but given siblings are for different platforms, it is adequate.

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