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

No annotations provided, so description carries full burden. Only mentions auth requirement. No disclosure of side effects, success/error behavior, or limits. Schema provides maxLength but description adds no behavioral context.

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

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

Very concise single sentence, suitable for simple action. However includes HTTP method and auth key which may be noise. Could be more structured but not overly verbose.

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

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

No output schema, partial parameter descriptions, no annotations. Missing response format, explanation of request_id, and body structure beyond schema. Incomplete for a mutation 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?

Description does not elaborate on parameters. Schema coverage is 50% (only body has description). request_id lacks description, and description does not compensate.

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?

Description clearly states it adds a comment to a request thread, with verb 'Add' and resource 'comment'. Implicitly distinguishes from siblings like delete_comment and edit_comment but could be more explicit.

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?

Only mentions 'Authenticated users only' as prerequisite. No guidance on when to use vs alternatives like list_request_events or other comment operations. Missing when-not-to-use.

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

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

No annotations, so description carries full burden. It discloses that it's a status change without pipeline trigger and admin-only. But lacks details on side effects, reversibility, error scenarios, 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?

Three sentences, front-loaded with endpoint and auth info. Every sentence adds value with no redundancy.

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

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

Covers core purpose and distinguishes from fulfill, but lacks parameter explanations and output details. Given no output schema, tool is simple but completeness is adequate.

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

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

The description adds no meaning to parameters; request_id and body (with expected_version, comment) are not explained. Schema coverage is 50% but property descriptions are missing in schema too, so description does not compensate.

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 approves a dataset request, specifies it's a pure status change without pipeline trigger, and differentiates from the fulfill endpoint. The verb 'approve' is specific and the scope (admin-only) is explicit.

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

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

It explains when to use (approve a request) and notes that actual dataset creation is done via fulfill. It mentions admin-only prerequisite. However, no explicit exclusions for other sibling tools like reject or in-progress.

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?

Given no annotations, the description effectively discloses that this is a read-only GET operation, requires matching clerk_id for auth, and returns a specific response format. It is transparent about the behavior, though it could mention potential error conditions or rate limits.

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

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

The description is concise, front-loading the purpose and method, followed by auth and return details. Every sentence adds value, and it is well-structured without unnecessary 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?

The description covers the endpoint, auth requirement, return format with possible reasons, and practical context (save dialog). Given it is a simple check with no output schema, it provides sufficient information for an agent to use 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?

With schema coverage at 0%, the description adds meaning: it indicates that 'user_id' is the clerk_id that must match the caller, and 'slug' is the slug being checked. However, it does not specify constraints like slug format or allowed characters, leaving some ambiguity.

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 purpose: 'Check whether a slug is available for the current user'. It specifies the HTTP method (GET), endpoint, and distinguishes itself as a slug-availability probe used in save dialogs, which is distinct from any sibling 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?

The description provides context on when to use this tool (for checking slug availability in the save dialog) and includes an auth requirement (clerk_id must match caller). However, it does not explicitly mention when not to use it or suggest alternative tools, though no direct alternative exists.

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 notes it's a GET request (public, streaming CSV) and lists current limitations (narrow v1). However, it does not explicitly confirm it's read-only or idempotent. With no annotations, the description partially addresses behavioral traits but lacks full transparency.

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, two sentences plus a line, with the primary purpose front-loaded. Every sentence adds value, including the limitation note and reference to preview endpoint.

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 or annotations, the description sufficiently explains the endpoint, its purpose, and constraints. It could mention response format or error handling but is adequate for a straightforward download 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 60% coverage (3 of 5 params have descriptions). The description adds no extra parameter meaning beyond the schema. It does not compensate for missing descriptions of provider and dataset.

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 downloads a composed join as CSV, specifying HTTP method, public availability, and limitations (single join, no computed columns, no filters). It distinguishes itself from sibling tools like compose_preview.

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

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

The description explains that this tool mirrors the shape of POST /compose/preview, enabling users to preview then download without tweaking parameters. It implies the preview endpoint is an alternative but 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?

With no annotations, the description fully discloses behavioral traits: the preflight cardinality check logic, including thresholds, refusal conditions, warnings, and row capping. This provides comprehensive transparency about what the tool does beyond its basic function.

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, starting with the HTTP method and summary, then explaining the join constraint, and finally detailing preflight behavior. It is well-structured without unnecessary fluff, though slightly more precision could improve it.

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 complexity (nested parameters, no output schema), the description covers purpose, usage, and behavioral transparency but omits return format, error specifics beyond cardinality, and detailed parameter semantics. It is partially complete but leaves gaps for an AI agent to fully understand 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?

The description does not explain the individual parameters (e.g., provider, dataset, body fields like key, source_column, join_column, select). With only 33% schema description coverage, the description should compensate but only provides high-level context about single joins and cardinality, lacking parameter-level details.

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 'Preview a compose/join without saving it' and 'Execute a single-join preview', specifying the HTTP method and auth. It distinguishes from saving by explicitly noting 'without saving', making the purpose 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 explicitly advises using one join spec per request to avoid cardinality risk, implying users should vet each join in isolation. It provides clear guidance on when to use the tool but does not name sibling alternatives like compose_download_csv, so it's slightly below perfect.

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

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

With no annotations, the description carries full burden. It effectively discloses the atomic transaction behavior and rollback guarantee, which are critical safety traits. However, it omits response details and error conditions beyond the rollback.

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 succinct, consisting of a few sentences without fluff. It front-loads the key purpose and atomicity. Minor improvement could remove class reference ('see :class:UserViewCreate') which is not helpful to an AI agent.

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

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

Despite complex input and no output schema, the description does not mention return values, error responses, or authentication details beyond the inline endpoint line. For a tool with nested objects, more context on expected behavior and success/failure indicators is needed.

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 1 complex parameter (body) with many properties, but schema description coverage is indicated as 100% (likely meaning schema fully defines structure). The description adds value by noting that 'release_note' comes from the request body, but does not elaborate on other fields. Baseline 3 is appropriate as schema is rich.

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 explicitly states the action: 'Create a view and publish 1.0.0 atomically'. It clearly identifies the verb (create and publish) and resource (view), and distinguishes itself from siblings like create_view and publish_view by highlighting atomicity.

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 (when atomicity is desired to avoid orphan drafts) but does not explicitly contrast with separate create-then-publish workflow. Sibling tools exist (create_view, publish_view), but no guidance is provided on when to use this vs. those.

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?

Without annotations, the description fully discloses behavioral traits: caps on inline_data (1000 rows/512KB, truncation with truncated flag), per-user soft cap (100 drafts per origin, 429 error), idempotency within 60 seconds using SHA256, and creates a private standalone figure.

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 well-structured with a header and bullet points for behavior, front-loading the purpose. It is not overly verbose, but could be slightly more concise by removing the HTTP method and auth line since that is structural.

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 complexity (5 nested parameters, no output schema), the description covers key behaviors like creation, limits, and idempotency. It lacks details on the response format (e.g., draft id) and does not explain all parameters in depth, but overall it is sufficiently complete 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?

The input schema has no descriptions for individual properties, but the tool description adds context for inline_data (capping and truncation) and origin (per-origin cap). However, other parameters like viz_spec and transform_config lack explanation, though they are somewhat self-explanatory.

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

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

The description explicitly states the tool creates a snapshot draft figure on the authenticated user's profile, with a specific verb ('Create') and resource ('draft figure'), and distinguishes from siblings by specifying it's for external clients with rendered data.

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 a clear context for when to use this tool (external clients with rendered data wanting to hand off to the figure editor) but does not explicitly state when not to use it or mention alternatives. However, no direct sibling create tool exists, so this is adequate.

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

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

With no annotations, the description discloses key behaviors: auth, default draft status, slug uniqueness per creator, and rejection of reserved slugs. However, it omits details on conflict handling (e.g., if slug taken) and response format.

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, 45 words, front-loaded with endpoint and auth. No redundant information. Efficient and clear.

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

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

Given no annotations or output schema, the description is adequate but incomplete: it explains creation behavior but does not mention return value, error responses, or idempotency. This is a gap for a 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?

Schema coverage is high (all 1 parameter body is described), so baseline is 3. The description adds context on slug constraints and draft default, but does not elaborate on parameters like dataset_provider or config. Minimal added value beyond 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?

Clearly states the tool creates a user view via POST endpoint, with specific constraints (slugs unique per creator, default draft, reserved slugs rejection). Distinguishes from siblings like create_and_publish_view or get_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?

Specifies auth requirement (Bearer OPENDATA_API_KEY) and default draft behavior, but does not explicitly state when to use this tool vs alternatives like create_and_publish_view. Guidance is implied (draft vs publish) but lacks explicit when-not or alternative references.

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

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

No annotations provided, so description carries full burden. It discloses the use of DuckDB, loading parquet files, and restriction to SELECT. Auth is mentioned. Could include more on error handling or result structure, but covers key traits.

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?

Description is short and front-loaded. However, it contains redundancy (first sentence repeats the second). Generally efficient.

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

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

No output schema exists, and description does not explain return values or error handling. The response_format parameter hints at output types but lacks elaboration. Moderate completeness for a query 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 baseline is 3. Description adds context for the 'sql' parameter (table notation) but no additional meaning for params, timeout_ms, row_limit, response_format, or view.

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?

Description clearly states the verb (Execute SQL query) and resource (across multiple datasets). It specifies table notation and only SELECT statements, distinguishing it from sibling tools like sql_query_v1_datasets__provider___dataset__query_post.

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 table notation and allowed statements (SELECT only). However, it does not explicitly compare to alternative tools or mention when not to use it, missing a full guideline.

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?

Discloses soft-delete behavior (sets deleted_at) and authorization requirements. In absence of annotations, this is good but could mention visibility changes or reversibility.

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 containing all essential info: method, path, auth, action, behavior, restrictions. No superfluous text.

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 delete operation with two required params and no output schema. Could mention response format or error cases, but core info is present.

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

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

Schema has 0% description coverage; description only implies parameters via path syntax. Adds minimal meaning beyond the schema, but the path hints at their roles.

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 HTTP method, path, and that it performs a soft-delete of a comment, distinguishing it from siblings like add_comment and edit_comment.

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?

Specifies 'Author or admin only,' indicating required role. While it doesn't explicitly list when not to use, the context of siblings provides implicit 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?

Only indicates deletion and auth method. No details about side effects (e.g., cascade deletions), irreversibility, or error conditions. With no annotations, description provides minimal behavioral insight.

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

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

Extremely concise single sentence with HTTP method and auth. No wasted words, but may be too brief at the cost of missing critical information.

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

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

Simple delete tool with no output schema and no annotations. Description does not cover return values, error handling, or prerequisites. Incomplete for an agent to use robustly.

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 description does not explain clerk_id or slug. Agent cannot infer what these parameters represent without additional context.

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?

Description explicitly states 'Delete a user view', with HTTP DELETE method and path. Distinguishes from sibling tools like create_view, update_view, get_view, 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?

No guidance on when to use this tool vs alternatives, no prerequisites or ownership requirements mentioned. Agent has to infer use case from tool name and 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?

With no annotations provided, the description carries full burden. It discloses that authentication is required, uses hybrid search with relevance sorting, has a smaller default limit (5), and has no pagination. It does not mention rate limits or potential side effects, but for a read-only discovery tool, these are less critical. Overall, it provides adequate behavioral expectations.

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 and well-structured. It opens with the general purpose, then provides a bulleted list of key differences. Every sentence adds value, and there is no redundancy 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 has 7 parameters and no output schema, the description gives a good overview of what is returned (enriched metadata including columns, canonical questions, methodology, quality scores). It does not detail the exact response structure, but for a discovery tool, this level of completeness is sufficient. The lack of output schema is compensated by the description's summary.

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

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

All 7 parameters have descriptions in the input schema (100% coverage), so the schema already defines the parameters. The description adds overall context (e.g., default limit of 5) but does not elaborate on individual parameter semantics beyond what the schema provides. Thus, a baseline score 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 the tool's purpose: 'Discover datasets optimized for LLM agents' and specifies the enriched metadata returned (columns, canonical questions, methodology, quality scores). It also explicitly distinguishes itself from the sibling tool search_datasets_v1_search_get, making its unique role evident.

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 explicit guidance on when to use this tool vs alternatives, including a bulleted list of key differences from /search, notes on authentication requirements, and a directive to 'use /search for browsing' when pagination is needed. This gives clear context for tool 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?

No annotations provided; description states 'Sets edited_at' which discloses a side effect. However, it does not mention idempotency, safety (mutation), or other behavioral traits, leaving gaps.

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

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

Very concise with three sentences. Includes path and auth info at start, which is helpful but not critical. 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?

Lacks details on response format, how to construct the body, and full effect of the mutation. With 3 params and no output schema, the description is insufficient for an agent to fully understand 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 33% (only body has a description). The tool description does not add meaning to request_id, event_id, or the nested body field beyond what the schema provides. It fails to compensate for the low coverage.

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

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

Description clearly states 'Edit Comment' and specifies verb (edit) and resource (comment). Adds constraints like 'Author or admin only' and 'Sets edited_at'. Distinguishes from siblings like add_comment and delete_comment.

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 notes that only author or admin can use this tool, providing a clear access condition. Implicitly differentiates from add_comment and delete_comment by stating 'edit' as the action.

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 discloses that the tool is public, uses GET, exports only configuration (not data), and returns dataset.yaml format. Since no annotations are provided, these details are essential and well-covered. It does not mention rate limits or error cases, but for a simple read operation, this is sufficient.

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 well-structured, starting with the HTTP method and path, then explaining output and use cases. It is front-loaded with purpose and uses bullet points for readability. It could be slightly more concise, but every sentence 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?

The description covers the main aspects: what it does, the output format, use cases, and a note on what it does not export. Without an output schema or annotations, it provides enough context for an agent to understand the tool's function and limitations.

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 two parameters (provider, dataset) with no descriptions, and the tool description shows them in the URL path but does not add explicit meaning or constraints. Given zero schema coverage, the description partially compensates by indicating their role, but could provide more context (e.g., expected format or examples).

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 purpose: export dataset configuration as YAML. It identifies the specific resource (dataset configuration) and distinguishes itself from sibling tools like get_dataset_by_path or get_dataset_meta by focusing on YAML export for re-import.

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 when to use the tool, listing use cases like backup, migration, and sharing. It also mentions where the output can be re-imported (sync command or POST /datasets). However, it doesn't explicitly state when not to use it or compare with alternatives, which would raise it to 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?

With no annotations, the description carries the burden. It discloses that it's a PUT with OAuth, idempotent, and returns current count. This adds transparency, though side effects or error conditions are not covered.

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

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

The description is two short sentences with no fluff. It front-loads the HTTP method and auth, then the action and key behavioral trait (idempotency).

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 parameter and no output schema, the description adequately covers the action, auth, and idempotency. However, it does not specify what 'current count' refers to or mention any prerequisites.

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 elaborate on the clerk_id parameter beyond mentioning its name. It fails to compensate for the schema's lack of explanation.

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 'Follow a user' and mentions the specific resource (clerk_id). It also notes idempotency, distinguishing it from sibling tools like unfollow_user or get_follow_status.

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 (to follow a user) but provides no explicit guidance on when to use this tool vs alternatives like list_following or unfollow_user. Idempotency is mentioned but not contextualized.

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

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

No annotations are provided, so the description should disclose behavioral traits. It states the action (fulfill by linking) but lacks details on side effects, prerequisites (e.g., request existence, user permissions beyond admin), or error conditions. The POST method implies mutation but is not explicit.

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 plus auth info, which is concise. However, it is minimal and could include more detail without being verbose. It is not padded but is under-specified.

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 complexity (no output schema, 2 parameters, nested body), the description is incomplete. It does not mention the response format, success indication, or what happens after fulfillment (e.g., request status change). For a mutation tool, this is insufficient.

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 only 50% schema description coverage (body has a generic description, request_id has none), the description adds no parameter meaning. It does not explain what dataset_id, complexity_tag, expected_version, or comment represent, leaving the agent to guess.

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 fulfills a dataset request by linking it to a created dataset with the verb 'fulfill' and resource 'dataset request'. It distinguishes from siblings like submit_request or reject_request by focusing on the fulfillment action after dataset creation.

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 specifies 'Admin-only', indicating who should use it. However, it does not contrast with siblings (e.g., approve_request, reject_request) or provide when-to-use vs alternatives. The usage context is implied but not explicit.

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

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

With no annotations provided, the description adequately discloses behavior: it is a GET endpoint requiring authentication, returns flags. It does not mention rate limits or side effects, but for a read-only operation, this is sufficient.

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?

Description is succinct: two sentences plus an authentication note. No redundant words, front-loaded with key info. Perfectly concise.

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 output schema, description explains it returns flags about engagement. This is complete for a simple tool. Could mention flag format, but not critical.

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 no parameters (0 params, 100% coverage). Per guidelines, baseline is 4. Description adds no param info, but none is needed.

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

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

The description clearly states the tool's purpose: 'Get user activation signals for SSR branching' and explains it returns flags about user engagement with the platform. It distinguishes itself from siblings like get_feed or get_recommendations by specifying SSR use case.

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 mentions it's 'Used by SSR to decide which components to render' and specifies authentication requirements (Clerk). It does not explicitly state alternatives or when not to use, but the context is clear enough for an AI 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?

With no annotations, the description must disclose behavioral traits. It only states it's a public GET request. It fails to explain what 'bridges' or 'betweenness centrality' entail, whether results are ordered, or if the limit parameter implies pagination. The description is insufficient for an agent to understand side effects or data retrieval behavior.

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

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

The description is extremely concise (one line) and front-loads the HTTP method and visibility. However, the brevity sacrifices informative content. It earns a high score for conciseness but not for completeness.

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

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

Given the tool's single parameter and lack of annotations or output schema, the description should explain core concepts like 'bridges' and 'centrality' and clarify that this is a list endpoint. Without these, an agent cannot confidently decide to use this tool over others.

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 add meaning beyond the schema. However, it does not mention the 'limit' parameter at all, leaving the agent to infer its purpose solely from the schema's type and constraints (integer, 1-100). This is insufficient.

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 action ('Get'), the resource ('top bridge datasets'), and the specific metric ('by betweenness centrality'). It uniquely distinguishes this tool from sibling tools like 'get_communities' or 'get_neighbors' by specifying a graph centrality measure.

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. The 'public' label hints at accessibility, but there is no mention of prerequisites, limitations, or scenarios where this tool is preferred over similar graph-analytics endpoints.

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

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

With no annotations, description covers read-only nature (GET), public access, and sort fallback behavior. Adds value beyond schema by explaining public access and sort details. Does not address error handling 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?

Reasonably concise with a clear header line, one explanatory sentence, and formatted sort options. Front-loaded with purpose. Could be slightly more structured but adequate.

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?

Describes return as metadata and paginated dataset list, but lacks details on error responses, default pagination limits, or output structure. No output schema exists, so more detail would be beneficial.

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 covers 75% of parameters with descriptions. Description adds value by explaining sort options and fallback behavior for 'queries' sort, which is not fully captured in schema 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?

Description clearly states the verb 'Get', resource 'category with datasets', and specifies it's paginated. It distinguishes from sibling 'list_all_categories_v1_categories_get' by focusing on a specific category's details.

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 notes no authentication required and public endpoint. Describes sort options and default behavior. However, does not explicitly contrast with sibling tools or state when not to use.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions 'public' and the return content (top datasets, topics), but does not disclose idempotency, pagination, rate limits, or sorting behavior. The description is insufficient for a read operation.

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

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

The description is extremely concise, using a single line that includes the HTTP method and path. It has no unnecessary words, but the inclusion of the path may be redundant given the tool name. It could be more informative without sacrificing conciseness.

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 minimal inputs, so the description needs to cover response structure and usage details. It fails to explain pagination, sorting, or how to interpret the community listing. It is incomplete for a listing endpoint.

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

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

The input schema has one parameter (limit) with 0% description coverage. The description does not mention this parameter or add any meaning beyond the schema, failing to compensate for the gap. It should explain that limit controls the number of communities returned.

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 'Get community listing with top datasets and dominant topics,' which is a specific verb-resource combination. Among sibling tools, it is distinct from get_community_datasets (which targets a specific community) and get_bridges (graph bridges), so differentiation is clear.

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 includes '(public)' indicating accessibility, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Usage context is implied as a general listing endpoint, but no direct guidance is given.

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

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

The description adds a 'public' tag, hinting at open access, and states ordering by importance. However, no annotations are provided, leaving the tool's safety profile unconfirmed. It doesn't mention that this is a read-only operation (though GET implies it), nor does it disclose behavior like pagination, rate limits, or what happens if community_id is invalid. Some behavioral context is given, but not enough to fully compensate for missing 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 concise in one sentence but includes some redundancy (the HTTP method and 'public' tag are arguably unnecessary for an AI agent). It front-loads the key operation. Minor improvement could remove the HTTP prefix.

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 and no annotations, the description should cover return format, pagination, and authentication. It only mentions ordering and public access. Without output schema, the agent knows little about the response. This is incomplete for a tool that is likely used in data retrieval workflows.

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 explain parameters. The description only mentions community_id implicitly via the URL path but does not describe limit or offset parameters. It fails to add meaning beyond the schema structure. For a tool with 3 parameters and no schema descriptions, this is insufficient.

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?

Description explicitly states 'List datasets in a graph community, ordered by importance.' It uses a specific verb (list) and resource (datasets in a community), with ordering detail. This clearly distinguishes it from sibling tools like get_communities (which lists communities) or get_related_datasets (which lists related datasets for a given dataset).

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?

Description implies usage when needing datasets in a community, but provides no guidance on when not to use it or how it compares to alternatives like get_related_datasets or get_entity_datasets. No exclusions or prerequisites are mentioned. With many sibling tools, this is a moderate gap.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool returns events in reverse chronological order and lists event types (enrichment, ingestion, schema changes). This adds behavioral context beyond the schema. However, it does not mention pagination, rate limits, or any potential side effects, though being a read-only GET makes that less critical.

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 extremely concise—two sentences—and front-loads the endpoint, purpose, and event types. Every sentence adds value with no redundancy.

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

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

For a simple activity fetch tool with no output schema, the description covers the key aspects: what events are returned and their order. However, it omits how the 'limit' parameter affects results (e.g., default, max). Given the absence of output schema, a bit more detail on the response structure 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?

Schema description coverage is only 33% (only 'limit' has a description). The description does not add meaning for the 'provider' or 'dataset' parameters beyond what the schema provides. Since coverage is low, the description should compensate but does not. Baseline score of 3 is appropriate as the schema already defines types and constraints.

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

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

The description clearly states the tool's purpose: 'Get recent activity events for a dataset.' It specifies the HTTP method, path, and that it returns system events (enrichment, ingestion, schema changes) in reverse chronological order. This is a specific verb-resource pair that distinguishes it from sibling dataset tools like get_dataset_meta or get_dataset_sources.

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 explicitly says 'Used for the activity feed on dataset pages,' which gives a clear usage scenario. However, it does not mention when not to use this tool or provide alternatives among the many sibling tools. No exclusion criteria or context for differentiation is given.

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

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

With no annotations, the description successfully discloses key behaviors: public access, pagination (limit, offset, cursor), format selection priority, file attachment downloads with size guard, and response format options. It could be improved by noting error handling or rate limits, but overall is fairly transparent.

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 front-loaded with the main purpose but becomes verbose. The trailing ellipsis indicates incompleteness, and some details (like format enumeration) could be more concise. It is adequate but not optimal.

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 18 parameters and no output schema, the description covers core behaviors but leaves some gaps: the truncated ending suggests missing content, and it does not describe typical response structure beyond format. It is reasonably complete for a complex tool but not fully satisfactory.

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 78%, so baseline is 3. The description adds minimal parameter-specific insight beyond the schema (e.g., format selection priority and download behavior). It does not significantly enhance understanding of each parameter.

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

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

The description clearly states the tool retrieves dataset data or subdataset list for a given provider/dataset. It specifically mentions flat vs hierarchical datasets and notes that metadata is available via a separate endpoint, distinguishing it from sibling tools like get_dataset_meta.

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

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

It explains when to use this tool for data retrieval and mentions an alternative for metadata. However, it does not explicitly state when not to use it or provide clear exclusion criteria compared to other data query tools (e.g., sql_query or cross_dataset_query).

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?

Discloses return of full value list up to 1000 for low-cardinality columns, but doesn't specify behavior for high-cardinality columns, auth requirements (beyond 'public'), or error cases. With no annotations, more detail would be beneficial.

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 concise sentences, first stating purpose, second adding a key behavioral detail. No wasted words, front-loaded with core information.

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

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

No output schema, so description must cover return values. It does mention the value list, but omits details on what 'detailed statistics' include. Lacks pagination info. Still mostly complete for a straightforward retrieval 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?

Parameters (provider, dataset, column_name) are self-explanatory from names, but schema coverage is 0% and description adds no additional constraints or format details. Baseline 3 for adequate but minimal value.

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 it retrieves detailed statistics for a single column, with specific mention of returning value list for low-cardinality columns. Distinguishes from sibling tools like get_dataset_columns and get_dataset_stats.

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 over alternatives. Siblings exist for listing columns or dataset stats, but description doesn't compare or set usage context. Only implies public access.

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

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

With no annotations, the description carries the full burden. It discloses the HTTP method (GET), public access, use of sampling for efficiency on large datasets, and view-related behavior (computed/joined columns). These are useful behavioral traits beyond the obvious.

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 and well-structured: it starts with the purpose, lists returns, mentions sampling, and explains view behavior in three short paragraphs. Every sentence adds value, and there is 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?

Despite lacking an output schema, the description lists all key return fields (column names, types, distinct counts, value distributions, row count). It also covers edge cases (view active, default_view, sampling) and is complete for its simple read operation.

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

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

Schema description coverage is low (33%), but the description adds meaning for the view parameter, explaining its purpose and special value 'all'. The provider and dataset parameters are implied by the tool name and path, so the description provides sufficient context for an AI agent.

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 'Get Dataset Columns — Get column metadata and statistics for a dataset.' It specifically lists the returned data: column names, types, distinct counts, value distributions, and row count. This clearly differentiates from sibling tools like get_dataset_column_detail, which returns details for a single column.

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 when to use the view parameter and the behavior with active views, including using default_view or 'all' for raw columns. It provides clear context but does not explicitly state when not to use the tool or contrast with alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses it is a public GET request and returns metadata about schema, views, and query capabilities. However, it lacks details on error handling, authentication, or side effects. Since it is a read-only operation, the description is adequate but not rich.

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 extremely concise: two sentences that efficiently convey the endpoint type, public status, what it returns, and how to use it. No redundant information.

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

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

Given the absence of an output schema, the description partially compensates by mentioning what metadata is returned (schema, views, query capabilities). However, it does not describe the response structure or format, leaving some ambiguity 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?

The input schema has two string parameters (provider, dataset) with 0% description coverage. The tool description does not explain the meaning or format of these parameters beyond the URL path pattern. This is insufficient for an agent to know how to provide valid 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 it gets dataset metadata without data, listing specific return values (schema, views, query capabilities). It distinguishes itself from sibling tools that fetch actual data (e.g., get_dataset_by_path) or specific components (e.g., get_dataset_columns), making the purpose unmistakable.

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 says to use this endpoint to understand dataset structure before fetching data, providing clear context. However, it does not explicitly state when not to use it or mention alternatives, though the usage hint is strong.

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?

Without annotations, the description carries the burden and discloses that the output format varies by dataset type (multi-source, aggregator, single-source) and that the endpoint is public. This adds behavioral context beyond just saying 'list sources'.

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: a single introductory line followed by three bullet points for output cases. Every sentence provides unique value without redundancy or 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 covers the return value variations for different dataset types and states the endpoint is public. It is sufficiently complete for a simple two-parameter retrieval tool, though error conditions or edge cases are not mentioned.

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 two parameters (provider, dataset) with 0% description coverage. The tool description only mentions them in the HTTP path without any additional explanation, validation rules, or examples. It adds minimal meaning beyond the schema.

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

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

The description clearly states it lists all source URLs for a dataset, distinguishing it from sibling tools like get_dataset_by_path or get_dataset_meta. It details three output formats for multi-source, aggregator, and single-source datasets, making the purpose precise.

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 the tool is used to retrieve dataset sources, but it does not specify when to prefer it over other dataset-related tools or when not to use it. No explicit when/when-not guidance or alternatives are provided.

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

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

With no annotations, the description should disclose behavior like idempotency, data freshness, or error responses. It only notes the endpoint is 'public', but lacks details on rate limits, required permissions, or what happens if parameters are invalid.

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 embedding the URL and purpose. It is front-loaded with the method and path, but could be more structured by separating endpoint info from a clearer explanation of the returned statistics.

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 lacks information about the returned statistics (e.g., which metrics are included) and does not clarify the distinction from sibling tools like get_dataset_meta or get_platform_stats. Given the absence of an output schema, more details are needed for 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?

Schema coverage is 0%, and the description only implicitly maps provider and dataset via the URL path. It adds no further explanation of valid values, formatting, or constraints compared to the schema.

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

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

The description states the HTTP method, resource path, and states it returns graph-computed statistics, clearly identifying the action on a specific dataset. However, it does not differentiate from sibling tools like get_platform_stats or get_provider_stats.

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 get_dataset_meta or get_dataset_activity. There is no mention of prerequisites or exclusion criteria.

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

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

Without annotations, the description carries the burden. It mentions the endpoint is public and includes content details, but does not disclose error behavior, rate limits, or authentication requirements. The GET verb implies read-only operation.

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

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

The description is three sentences, each adding value: endpoint and publicity, purpose, and included details. It is clear but could be slightly more concise by omitting the redundant endpoint example.

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 adequately describes what the response contains (alias definitions, column projections, lookup configurations). It lacks error handling details, but for a simple GET, it is fairly 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?

Input schema has zero description coverage, and the tool description adds no explanation of the parameters (provider, dataset, name). Their meaning is partially inferable from the endpoint path, but the description does not clarify them.

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 retrieves detailed configuration for a specific dataset view, listing what it includes (alias definitions, column projections, lookup configurations). It distinguishes from sibling tools like list_dataset_views by focusing on a specific 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?

No guidance is provided on when to use this tool versus alternatives such as get_view_v1_views__name__get or list_dataset_views. The description does not mention prerequisites or context where this tool is 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?

The description notes the endpoint is GET and public, but lacks details on pagination, rate limits, error handling, or any side effects. Annotations are absent, so the description should compensate but does not.

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

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

The description is very concise (single line) but lacks structure. It includes the HTTP method and path, which is helpful, but could be better organized with separate sections.

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 two required parameters with no enums or output schema, the description is insufficient. It does not explain the expected IDs, possible entity types, or the response format, leaving the agent underinformed.

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 adds no meaning to the parameters. It does not explain valid values for entity_type or format of entity_id, which are critical for 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 retrieves datasets referencing a specific entity. It distinguishes from sibling tools like get_community_datasets and get_provider_datasets. However, it could be more precise about what 'referencing' means in graph context.

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 like get_community_datasets or list_datasets. There is no mention of prerequisites or typical scenarios.

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?

Despite no annotations, the description fully discloses authentication requirement (Clerk), pagination mechanism (cursor), and behavior of feed types (e.g., 'people' returns empty, 'merged' coerced). This exceeds expectations.

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 well-structured with sections for feed types and pagination, and it is front-loaded. It is slightly lengthy but each sentence 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?

No output schema exists, but the description adequately explains the return value (dataset updates, paginated with next_cursor) and covers authentication, feed behaviors, and pagination. It is complete for a retrieval 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% with good descriptions. The description adds extra context beyond schema, such as the coercion behavior of 'merged' type and that 'people' returns empty, enhancing parameter understanding.

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 defines the tool as retrieving a user activity feed with updates from followed providers, listing feed types and their current status. It distinguishes itself from similar sibling tools like get_dataset_activity and get_user_activity.

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 when to use the feed, including limitations (e.g., 'people' feed not available) and pagination. It provides context but does not explicitly contrast with 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?

No annotations are provided, and the description fails to disclose behavioral traits such as authentication requirements, rate limits, default ordering, or pagination behavior. The term 'public' hints at minimal access control but lacks detail.

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

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

The description is very concise, front-loading the key purpose and HTTP method. However, it is perhaps too terse, omitting important context that could be included without significant bloat.

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 and the simplicity of the tool (feed list with pagination), the description lacks essential context like default limit values, ordering, or handling of the 'since' parameter. It leaves the agent to infer too much from the schema alone.

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 3 parameters with only 33% description coverage (since has a description). The tool description adds no additional meaning to the parameters, leaving limit and offset undefined in terms of purpose or expected 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 the tool returns the activity feed of followed users, including the HTTP method and path for specificity. It distinguishes itself from similar tools like get_user_activity by specifying 'followed users', making the purpose 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 implies usage for retrieving a feed of followed users but provides no explicit guidance on when to use this tool over alternatives (e.g., get_user_activity, get_feed_v1_me_feed_get). No when-not-to-use or alternative tool references are given.

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

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

With no annotations provided, the description fully covers behavioral traits: public vs private access, 404 for non-owners, optional auth, and is_liked_by_me reflecting user status. It does not mention rate limits or side effects, but for a read-only tool this is sufficient.

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 well-structured with sections for return details, visibility, and authentication. It is concise and front-loaded with the core purpose, with every sentence adding 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 the tool's simplicity (one parameter, no output schema), the description completely covers return fields, visibility rules, and auth behavior. No obvious gaps exist.

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 only parameter figure_id has no description in the schema (0% coverage). The description says 'by UUID' implying a format, but no detailed format or constraints are given. It adds minimal value beyond the parameter name and type.

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 'Get a figure by its UUID.' The verb 'get' and resource 'figure' are specific, and the use of UUID distinguishes it from list endpoints like list_figures.

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 visibility rules and authentication needs, providing clear context on when the tool returns data and for whom. However, it does not explicitly contrast with siblings like list_figures or create_draft_figure.

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

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

No annotations are provided, and the description is minimal. It mentions the endpoint is public but does not disclose behavior beyond that, such as whether it returns a boolean, any rate limits, or authentication requirements.

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

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

The description is extremely concise with one sentence, front-loading the key information. It is efficient but could benefit from slightly more detail without losing conciseness.

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 (one parameter, no output schema), the description adequately covers the purpose and basic behavior. It does not describe the response format or errors, but for a simple status check, this may be sufficient.

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 only parameter 'clerk_id' has no schema description (0% coverage). The description implies it is the user whose follow status is checked, adding some semantic meaning beyond the type 'string'. However, it does not fully compensate for the missing schema 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 clearly states the action (GET), resource (follow-status), and outcome (return whether caller is following clerk_id). It distinguishes from siblings like follow_user, unfollow_user, list_followers, list_following.

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 purpose is implied: to check follow status. However, there is no explicit guidance on when to use this versus siblings (e.g., whether to use this before following) or any conditional 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?

No annotations are provided. The description only repeats the endpoint and action, omitting behavioral traits like side effects, authentication (though 'public' is in the endpoint but not description), 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 extremely concise, one sentence with clear front-loading. Every word serves a purpose with no redundancy.

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

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

Given zero parameters and no output schema, the description is minimally adequate. However, it fails to add context like expected response format or usage tips, which would benefit an AI 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?

The input schema is empty with 0 parameters. The description does not need to add parameter detail, as there are none. Per calibration rules, 0 parameters warrant a baseline of 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 the tool retrieves graph health and sync status, with a specific verb and resource. Among siblings, no other tool targets health, making it distinct.

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

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

No guidance on when to use this tool versus alternatives or when not to use it. The description lacks context for appropriate invocation scenarios.

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

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

No annotations are provided, so the description must cover behavioral traits. It only states it's a public GET, but does not disclose behavior like result format, pagination, or effect of parameters like max_hops. For a tool with no annotations, this is insufficient.

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 with no fluff, including the endpoint and method. It is concise, though could be expanded slightly to add more value without sacrificing brevity.

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

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

For a tool with five parameters involving graph traversal and no output schema, the description is too bare. It does not explain 'multi-hop join paths' or what the results look like, leaving the agent underinformed.

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

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

Schema coverage is 0%, meaning no parameter descriptions in the schema. The description adds no information about parameters (e.g., what max_hops or min_confidence do). It fails to compensate for the lack of 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 the action ('discover multi-hop join paths') and resource (from a dataset), and indicates it's a public GET endpoint. It distinguishes the tool from siblings like get_neighbors or get_related, though not 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 guidance on when to use this tool versus alternatives such as get_neighbors or get_schema_graph. No exclusions or prerequisites are mentioned.

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 notes 'public' but does not explicitly state whether the operation is read-only or discuss side effects. With no annotations, the description fails to disclose behavioral traits like authentication, rate limits, or data mutability.

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 is concise and directly states the endpoint and purpose. However, it could benefit from a bit more structure, but it is not overly verbose.

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 four parameters, no output schema, and no annotations, the description is minimal. It lacks details on output format, error handling, or parameter interaction, making it incomplete 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?

Schema coverage is only 25% (only edge_types has a description). The description adds no parameter semantics beyond the schema; it does not clarify provider, dataset, or limit usage.

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 action ('Get Neighbors') and the resource ('direct 1-hop connections from a dataset'). It is specific and distinguishes from sibling tools like get_related which likely returns different relationships.

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 such as get_related or get_schema_graph. There is no mention of prerequisites or context for usage.

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

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

No annotations are provided, so the description must carry behavioral transparency. It accurately conveys the read-only nature and scope, but omits details such as rate limits, caching policy, or data freshness, which would benefit an agent in a high-stakes context.

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 front-loads the endpoint and public tag, then concisely states the purpose and included statistics. No redundant information.

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

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

Given no output schema and zero parameters, the description sufficiently covers what the tool does and what data it returns (providers, datasets, rows). It does not detail the response structure, but the examples give a reasonable expectation.

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

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

The input schema has zero parameters, so the description cannot add parameter semantics beyond the schema. Baseline score of 4 is appropriate as no parameters exist.

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?

Description clearly states the tool retrieves platform-wide aggregate statistics, including specific examples (total providers, datasets, rows). It uses a distinct verb and resource, and is easily distinguishable from sibling tools that focus on provider- or dataset-specific stats.

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?

Description marks the endpoint as public ('(public)'), providing context on accessibility. However, it does not explicitly state when to use this tool versus alternatives like get_provider_stats or get_dataset_stats, which are present among 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?

With no annotations, the description carries the full burden. It mentions 'GET' and 'public' but fails to disclose any behavioral traits like response format, error handling, or rate limits. It does not contradict annotations because none exist, but it is insufficient.

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 no waste, though the first sentence largely restates the tool's name. It is efficient but could be more front-loaded with the core 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?

Given one parameter and no output schema, the description explains the input adequately but does not specify what the returned metadata contains (e.g., fields, structure). It is minimally complete for a simple read operation.

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

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

Schema coverage is 100% and the description repeats the schema's parameter description ('Provider slug'). The description adds no extra meaning beyond the schema, meeting the baseline for high 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 it gets enriched metadata for all datasets in a provider, using a specific verb and resource. It distinguishes from siblings like 'get_provider_enriched' by specifying 'metadata' and 'all datasets'.

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 such as 'get_provider_enriched' or 'discover_datasets'. The description only states what it does, leaving usage context implied.

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

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

No annotations provided, so the description must disclose all behavioral traits. It mentions the endpoint is public and includes enriched metadata when available, but does not detail errors, rate limits, or what happens if enrichment is absent. This is insufficient for a read endpoint.

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

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

The description is concise with two sentences covering endpoint, publicity, and purpose. No unnecessary words, though the endpoint string could be omitted as it is captured in 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?

For a simple one-parameter GET tool without output schema, the description is adequate. However, it does not explain what 'enriched' means or hint at the response structure, leaving some ambiguity.

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% with a clear description for the single parameter. The description adds no additional meaning beyond what the schema already provides, so baseline 3 is appropriate.

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

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

The description clearly states the tool fetches enhanced provider details with AI-enriched metadata. It uses specific verb 'Get' and resource 'provider enriched', distinguishing it from siblings like get_provider_v1_providers__provider__get which likely returns basic details.

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 get_provider_v1_providers__provider__get or get_provider_stats. The description only implies it is for enriched data but does not contrast with siblings or state 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?

No annotations are provided, so the description carries the full burden. It only describes the GET endpoint as public and the statistics returned, but it does not disclose any behavioral traits such as side effects, rate limits, or authentication requirements beyond being public.

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 line but contains redundancy: 'Get provider statistics' appears twice. It could be more concise without losing information.

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

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

For a simple tool with one parameter and no output schema, the description adequately covers the purpose and the type of data returned. It is complete enough to understand what the tool does.

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% with one parameter 'provider' described as 'Provider slug (e.g., 'bls', 'census')'. The description does not add additional meaning beyond the schema, so it meets the baseline of 3.

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 verb 'Get', the resource 'provider statistics', and specifies the metrics included (dataset count, total rows, update info). It also provides the endpoint URL, which differentiates it from sibling tools like get_provider or get_provider_enriched.

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 indicates the tool is public and returns aggregate statistics, but it does not explicitly state when to use this tool versus alternatives like get_provider or get_provider_enriched. There is no guidance on 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?

With no annotations, the description carries full burden. It mentions 'public' in the endpoint string, hinting at access, but does not disclose error behavior, data freshness, or rate limits. Minimal behavioral context.

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 (one line) but combines endpoint, visibility, and purpose in a single string. It is front-loaded but could be better structured for readability.

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

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

For a simple get-by-slug tool with no output schema or annotations, the description covers the basic purpose but lacks detail on response structure or edge cases. Adequate but not comprehensive.

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

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

Schema coverage is 0% with one parameter 'provider' lacking description. The description only says 'by slug', adding no format, constraints, or examples. This is insufficient for proper parameter usage.

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 action ('Get Provider'), resource ('provider details'), and method ('by slug'). It distinguishes itself from sibling tools like get_provider_stats and get_provider_enriched by specifying 'by slug', though it doesn't explicitly differentiate them.

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

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

No guidance on when to use this tool versus alternatives. The description only states what it does, leaving the AI agent without context for selection among many similar provider tools.

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

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

With no annotations, the description carries full burden. It discloses that it's a GET endpoint requiring authentication, returns recommendations based on activity, and describes cold-start behavior. However, it omits details about pagination behavior, error handling, rate limits, or response structure, which are important for safe 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 well-structured with a title line, a brief summary, a list of recommendation kinds, and an authentication note. It is front-loaded with key information. Minor redundancy like repeating 'Get personalized recommendations' could be removed, but overall it is efficient.

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 moderate complexity and lack of output schema, the description adequately explains the tool's purpose, parameters, and authentication. However, it does not describe the response format or pagination behavior. For an agent to reliably use pagination or interpret results, additional details are needed.

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 covers 67% of parameters with descriptions (limit, offset). The tool description adds significant value for the 'kind' parameter by explaining each enum value (datasets, providers, users) and their meaning. This goes beyond the schema, which only lists the enum without 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 gets personalized recommendations for datasets, providers, or users based on user activity. It lists the three kinds and distinguishes from similar tools like 'discover' or 'search' by emphasizing personalization. However, it does not explicitly differentiate from siblings like 'discover_datasets' or 'get_related_datasets', leaving minor 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 explains the tool should be used for personalized recommendations and notes cold-start behavior for new users. It lists the recommendation kinds and authentication requirements. While it provides good contextual guidance, it does not explicitly state when not to use this tool or directly mention 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?

With no annotations, the description effectively discloses multiple behavioral traits: it combines three signals, caches results in Redis, provides categories, and degrades gracefully when Neo4j is unavailable. It does not mention exact response structure or error handling, but the provided details are substantial.

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 reasonably concise, uses section headers for categories, and integrates a fallback note. It could be slightly tighter, but it is well-organized and avoids unnecessary 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?

The description covers signal sources, caching, categories, and degradation, which is good for a listing tool. However, it lacks information about the output format (no output schema exists), pagination, or total count, leaving some gaps for an agent to know 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?

The description adds no additional meaning to the parameters beyond the schema. Only the 'limit' parameter has a schema description; 'provider' and 'dataset' are not further explained, leaving the agent to infer from the path template. Schema coverage is 33% and the description does not compensate.

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 retrieves related datasets using a unified multi-signal scoring approach, combining pgvector, join suggestions, and Neo4j graph signals. It specifies categories of relatedness (joinable, similar) and mentions caching, providing a specific and distinctive purpose among sibling 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?

The description notes the endpoint is public and mentions graceful degradation when Neo4j is unavailable, but it does not explicitly compare to sibling tools like get_related_v1_graph... or list_joinable, nor does it provide guidance on when to use this tool over alternatives.

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

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

No annotations are provided, so the description carries full burden. It mentions the endpoint is public but does not disclose read-only nature, rate limits, or other behavioral traits. Minimal transparency.

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?

Description is one sentence, concise and efficient. No fluff, but could include slightly more detail without becoming verbose.

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 or annotations, the description is adequate for a simple lookup tool. However, it lacks information about return structure, which could be important 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?

Input schema has 100% coverage with clear descriptions for both parameters. The description adds context 'based on shared data domains' but does not significantly enhance understanding beyond the schema.

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

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

The description clearly states the verb 'find' and resource 'related providers', and explains the basis 'shared data domains'. It distinguishes from siblings like get_related_datasets.

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 for finding related providers but does not provide explicit when-to-use or alternatives. No guidance on 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?

No annotations provided, so description carries full burden. It states it is public and uses graph algorithms, but does not clarify read-only nature, authentication needs, rate limits, or side effects. The term 'structural + semantic blended' is vague.

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 but includes redundant HTTP method and path already in tool name. Could be more concise by removing the GET path and 'Get Related' fragment. However, it is short and front-loaded with key info.

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

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

With no output schema and minimal description, the tool behavior is underspecified. Missing details: response format, pagination, effect of limit, definition of structural+semantic blending. Not sufficient for an AI to reliably use the tool 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%, and the description adds no meaning to the three parameters (provider, dataset, limit). No explanation of what each parameter represents or how limit affects results. Parameters are left entirely to their names and types.

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

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

Description clearly states the tool retrieves graph-powered related datasets using structural and semantic blending, distinguishing it from the sibling get_related_datasets which likely uses a different method. The verb 'Get' and resource 'related datasets' 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?

Implied usage via mention of 'graph-powered' and 'public', but no explicit guidance on when to use this over the sibling or other related endpoints. No when-not-to-use or alternative suggestions.

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

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

With no annotations, the description bears full burden for behavioral disclosure. It only mentions 'Admin-only' for access control, but does not state that the operation is read-only, any potential side effects, or other behavioral traits. This is insufficient for a tool with no annotation support.

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

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

The description is short and front-loaded with key information, but includes redundant elements like the full path and repeated title. It could be more streamlined while preserving 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?

For a simple one-parameter tool with no output schema, the description covers purpose and access restriction adequately. However, it omits parameter details and return value description, leaving moderate gaps for full contextual 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?

The input schema has 0% description coverage, and the description does not elaborate on the request_id parameter. No additional meaning is provided beyond the parameter name, leaving the agent without clarity on expected format or semantics.

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?

Description clearly states the tool retrieves full admin detail for a dataset request, with verb 'Get' and resource 'admin detail view'. The 'Admin-only' qualifier distinguishes it from sibling tool get_request_detail_v1_requests__request_id__get, providing specificity and sibling 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 term 'Admin-only' provides clear context on intended user role, implicitly guiding when to use this tool (if admin) versus the non-admin version. However, it lacks explicit when-not-to-use instructions or enumeration of alternatives.

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?

Describes public endpoint and auth-dependent inclusion of upvote state, but does not explicitly state idempotency, rate limits, or data freshness. Since no annotations exist, description provides some behavioral context but insufficient safety guarantees.

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 that front-load the endpoint and title. Efficient but could separate public vs authenticated behavior more clearly.

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 single-parameter GET tool, the description covers key output fields and authentication nuance. However, lacks output schema and does not mention error cases or data format, leaving completeness moderate.

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

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

Schema coverage is 0% and description only mentions request_id as parameter without additional details like format, examples, or constraints. The tool relies on the name to imply it's a request ID string.

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 retrieves request details, listing specific fields (linked-dataset slug, submitter info, comment count, upvote state). Distinguishes from sibling tools like list_requests (list all) or get_request_admin_detail (admin 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?

Implied usage: to get details of a specific request by ID. No explicit when-to-use or when-not-to-use guidance compared to alternatives like list_requests or list_request_events.

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

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

With no annotations provided, the description carries the full burden. It only indicates the endpoint is public but does not disclose how depth and limit affect the output, whether it is read-only, or any rate limits. The return structure is not described.

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, with two sentences that front-load the HTTP method and path. The slight redundancy in repeating 'Get Schema Graph' is minor. Every part serves a 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?

Given no output schema, no annotations, and 0% schema description coverage, the description should compensate but only explains the basic purpose and target audience (D3). It does not cover parameter effects, return format, or edge cases, making it incomplete for a graph endpoint with multiple parameters.

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

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

The schema has 0% description coverage, so parameters provider and dataset are only given by their names. The description mentions them in the path but adds no meaning to depth or limit, leaving the agent to infer their purpose without context.

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 retrieves the schema-level subgraph around a dataset for D3 visualization, distinguishing it from sibling graph endpoints like get_bridges or get_neighbors. The inclusion of the HTTP path and 'public' adds context. However, it could be more precise about what the subgraph contains.

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 versus alternatives such as get_subgraph or get_neighbors. The description implies it is for D3 visualization but does not state when not to use it or mention 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?

With no annotations, description discloses pagination mechanism (cursor, next_cursor) and states it's public. It mentions efficiency of keyset pagination. However, it does not discuss error handling, rate limits, or response structure beyond data rows.

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?

Description is extremely concise: four sentences, front-loaded with purpose, followed by essential pagination details. No redundant or irrelevant information.

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

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

For a GET data retrieval tool with 18 params and no output schema, the description covers retrieval and pagination adequately. However, it lacks details about response structure and does not differentiate from sibling tools, missing some 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?

Schema coverage is 72%, so baseline is 3. Description adds value by explaining pagination behavior for cursor, but other parameters are not enhanced. The cursor description in schema is already comprehensive.

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 action ('Get subdataset with inline data') and resource (subdataset by path). It distinguishes from siblings by specifying it returns data rows, not just metadata.

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?

Description provides pagination guidance but does not explicitly state when to use this tool vs alternatives like get_subdataset_meta (metadata only) or get_dataset_by_path. No when-not or explicit sibling differentiation.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the operation is public and read-only (no data returned), which is good. However, it does not mention error conditions, rate limits, or required permissions, leaving some behavioral gaps.

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 extremely concise: two sentences totaling about 20 words. It includes the endpoint, a label, and a clear purpose. Every word adds value, and the most critical information is front-loaded.

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

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

Given the tool's simplicity (3 string params, no output schema, no annotations), the description is largely complete. It explains what the tool returns and that it's public. However, it could benefit from clarifying possible errors or the relationship to the dataset-level meta 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?

The input schema has 3 string parameters with no additional description (0% schema coverage). The tool description does not explain the parameters further. The parameter names are self-explanatory, but the schema provides only basic type information, so the description adds no semantic value beyond the names.

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 purpose: retrieve metadata about a subdataset without the data. It specifies the HTTP method and endpoint, and mentions that it returns metadata including schema and available views. This distinguishes it from sibling tools like get_dataset_meta (for datasets) and get_subdataset_by_path (for data).

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 this tool (when you need metadata for a subdataset) but does not explicitly state when not to use it or suggest alternatives. It lacks guidance on distinguishing from closely related siblings like get_dataset_meta or get_subdataset_by_path.

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

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

Discloses the method is GET and public, and describes behavior when parameters are omitted. Does not explicitly state read-only nature or other constraints, but annotations are absent so description carries full burden.

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

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

Very concise: three sentences covering endpoint, purpose, and key parameter behaviors. No unnecessary 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?

Adequate for basic use but lacks description of output format and does not address two parameters. Given no output schema, more detail on return structure 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?

Adds meaning to seed_type and seed_id by explaining omission behavior and format, but ignores depth and limit. Schema coverage is 50% and description compensates partially but incompletely.

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 it gets a seeded subgraph for the graph explorer, specifying it's a GET endpoint. Slightly docked because it does not differentiate from sibling graph tools like get_bridges or get_neighbors.

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

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

Provides use case for omitting parameters and gives format for dataset seeds. Lacks explicit guidance on when not to use or alternatives among 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?

With no annotations, the description carries the burden of behavioral disclosure. It states the HTTP method (GET), public access, and output structure (top-5 plus unattributed). However, it omits error conditions, rate limits, or behavior when no data exists. This is adequate but not comprehensive.

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 conveys endpoint, access, and output. No redundant words. Could be improved by structuring with bullet points, but current length is appropriate for a straightforward retrieval tool.

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

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

For a tool that lacks an output schema, the description adequately summarizes the return format (top-5 named + unattributed bucket). It does not cover edge cases or error handling, but the core functionality is well explained. Given the low schema coverage, the description partially compensates.

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 33% (only window described). The description mentions a time window but adds no detail beyond the schema's '7d | 30d | 90d'. The required parameters username and slug lack schema descriptions and are not explained in the description, leaving ambiguity about their format or 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 clearly states the tool retrieves top callers for a view, is public, uses a time window, and specifies output format (top-5 named plus unattributed bucket). This verb+resource+detail distinguishes it from sibling tools like get_view_v1 which return the view itself rather than caller analytics.

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 for getting top callers of a view over a window, which is distinct from sibling tools that retrieve view metadata, versions, or other analytics. However, it does not explicitly mention when to avoid or provide alternative tool names for related tasks.

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

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

With no annotations, the description should disclose behavior. It only says 'public' but doesn't explain read-only nature, pagination via limit/offset, or response content. Minimal value beyond the name.

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?

Description is very short but redundant: 'Public social activity timeline for a user' and 'Public timeline for one user' repeat the same idea. Could be more concise.

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 3 params and no output schema, the description is incomplete. It omits return format, pagination details, and differentiation from similar 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 description coverage is 0%, so description should explain parameters. It only implicitly mentions 'clerk_id' in the URL, with no details on limit or offset semantics.

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?

Description clearly states it returns the public social activity timeline for a user using a verb+resource pattern. However, it doesn't differentiate from sibling 'get_user_activity' which uses 'user_id' instead of 'clerk_id'.

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

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

No guidance on when to use this tool versus similar tools like 'get_user_activity' or 'get_feed'. No alternatives or exclusions mentioned.

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 are missing, so the description must compensate. It states the tool is public, returns paginated results ordered by most recent, and lists activity types. However, it does not disclose auth requirements, rate limits, or other behavioral traits beyond basic functionality.

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 efficient sentences: first provides endpoint and primary purpose, second adds key details about content and ordering. No redundant or unnecessary information.

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

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

With no output schema, the description partially explains return values (list of activities, recent first) but lacks details on pagination metadata, error scenarios, or authentication. Adequate but not comprehensive.

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

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

Schema coverage is 75%, with descriptions for limit, offset, and type. The description adds value by providing example activity types (created, starred, synced, etc.), which helps the agent understand the type filter parameter context.

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 retrieves a paginated activity feed for a user, listing example activity types. However, it does not explicitly differentiate from similar sibling tools like get_feed_v1_me_feed_get or get_user_activity_v1_users__clerk_id__social_activity_get.

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

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

No guidance on when to use this tool versus alternatives, no mention of prerequisites or exclusions. With many activity-related siblings, this omission hinders correct tool 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?

No annotations are provided, so the description must carry the full behavioral burden. It states the endpoint is public and no auth required, but fails to disclose behavior when username is not provided (schema allows null), response shape details beyond 'same shape as user_id endpoint', or error handling.

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 somewhat redundant, repeating 'Look up user by username' twice. It could be more concise, but it is clear and front-loads key information.

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

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

Given no output schema and no annotations, the description should provide more context on expected behavior when username is omitted, response format, and potential errors. It only mentions 'public profile' without further detail.

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% with a clear description ('Username to look up'). The description repeats this without adding deeper details like constraints or format, so baseline 3 is appropriate.

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

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

The description clearly states the tool's purpose: look up a user by username, returning the public profile. It distinguishes from sibling tools like get_user_profile_v1_users__user_id__get by specifying the lookup by username rather than user ID.

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

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

The description implies usage when a username is available, but does not explicitly contrast with sibling tools like get_user_profile_v1_users__user_id__get. It notes the endpoint is public and requires no authentication, which provides 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?

Clearly states it's public, no auth, and returns specific counts. No annotations, but description adequately discloses behavior for a simple read operation.

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

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

Short and front-loaded, though the first sentence is slightly repetitive. No unnecessary information.

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

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

Covers what the tool does and what it returns. Lacks output schema but description provides enough for a simple GET.

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?

Parameter user_id is explained by the HTTP path but lacks details on format or validation. Schema coverage 0% so description partially compensates.

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?

Purpose is clear: get public profile with specific fields. However, no explicit differentiation from sibling user tools like get_user_activity or get_user_by_query.

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?

Description implies usage (public, no auth) but does not provide when-not-to-use or contrast with alternatives.

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 discloses the tool is a public GET operation (read-only) and returns metadata such as display name and schema. Since no annotations exist, the description carries the behavioral transparency burden but does not detail potential side effects, authentication beyond 'public', or rate limits. It is adequate but not thorough.

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 sentence that efficiently conveys the endpoint, visibility, purpose, and return contents. Every part serves a clear function without unnecessary verbosity.

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?

While the tool is simple with two parameters and no output schema, the description lacks a precise enumeration of return fields beyond 'display name, schema, etc.' It also does not clarify the relationship to sibling tools that retrieve more complete view data, leaving some contextual gaps.

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

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

With 0% schema description coverage and no parameter descriptions in the tool description, the agent has no explicit explanation of what 'username' and 'slug_with_version' represent or their allowed formats. The path template provides marginal context but fails to fully compensate.

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 purpose: 'Get version metadata' for a resolved version, specifying it returns metadata like display name and schema. The inclusion of the HTTP method and path, along with differentiation from sibling tools (e.g., get_versioned_view retrieves the view itself), makes the purpose distinct.

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 get_versioned_view (which retrieves the full view) or list_versions (which lists versions). The description implies usage for retrieving metadata but does not provide exclusions or contextual cues.

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

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

With no annotations, the description carries the full burden. It explains internal details: parses frozen config, looks up parquet path, routes through execute_user_view_config, records request_event for view_count trigger, and clarifies that offset is a no-op for keyset-paginated queries. This goes beyond basic purpose to reveal side effects and caveats.

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 structured with a title line, then a paragraph on execution details, and a final paragraph on parameters. It is relatively efficient for the level of detail, though it could be slightly tighter. Each 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?

Given the tool has 4 parameters, no output schema, and no annotations, the description covers behavior, side effects, and parameter caveats reasonably well. However, it fails to describe the two required parameters, reducing completeness. The execution flow explanation is helpful but incomplete without full parameter documentation.

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

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

Schema coverage is 0%, so the description must compensate. It only explains limit and offset (offset is a no-op, limit is honored), but completely omits description for the required parameters username and slug_with_version. This leaves a significant gap in understanding how to specify the view.

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 purpose: 'GET /v1/views/@{username}/{slug_with_version} (public) — Get versioned view data — Resolve a versioned view and execute its query against parquet.' It is a specific verb-resource combination that distinguishes it from siblings like get_versioned_view_meta, which retrieves only metadata.

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 notes that the endpoint is public and explains the behavior of limit and offset, but it does not explicitly guide when to use this tool versus alternatives. It lacks clear when-to-use or when-not-to-use directives, though the purpose is implicit.

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

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

No annotations are provided, so the description carries the full burden. It only mentions access control for drafts vs. published views. It does not disclose authentication requirements, error behavior (e.g., what happens if the view doesn't exist), or any side effects. The minimal behavioral detail is insufficient for a safe agent 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 short and to the point, with the purpose stated first. It consists of two sentences that efficiently convey the tool's function and access rules. No redundant or extraneous information is present.

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 (get by identifier, no output schema) and the existence of sibling tools, the description covers the essential purpose and access constraints. However, it lacks details on return values, authentication requirements, and error handling. For a minimal tool, it is adequate but not comprehensive.

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

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

The schema has 0% parameter description coverage. The description adds that the view is identified by (clerk_id, slug), but does not explain what clerk_id or slug represent, acceptable formats, or constraints. Beyond implying they are identifiers, the description adds little meaning beyond the schema structure.

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 purpose: 'Get a specific user view' identified by clerk_id and slug. It also distinguishes between drafts and published views, giving clarity on access. However, it does not explicitly differentiate from other get view endpoints like get_view_v1_views__name__get, but the identifier makes it distinct enough.

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 a usage condition: 'Drafts are owner-only. Published views are public.' This implies when the tool can be used based on view visibility. However, it does not give explicit guidance on when not to use this tool or mention alternative tools for similar tasks, such as other view retrieval endpoints.

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