hikerapi-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.2
Disambiguation2/5
Multiple tools serve identical purposes across different API versions (e.g., v1, v2, gql, g2). For example, get_v1_user_by_id, get_v2_user_by_id, and get_gql_user_web_profile_info all return user objects. This redundancy makes it difficult for an agent to pick the correct tool, especially with conflicting depreciation notes.
Naming Consistency3/5
Tool names follow a pattern of get_<api_version>_<resource>_<action>, which is consistent. However, the variety of version prefixes (v1, v2, v3, gql, g2) and occasional deviations (e.g., get_v2_media_comment_offensive) introduce some inconsistency. Overall, the naming is readable but could be simpler.
Tool Count1/5
With 106 tools, the set is excessively large for an Instagram data retrieval API. Many tools are duplicates across API versions (e.g., five different ways to get user followers). This bloat severely undermines usability and coherence. A leaner set of 20-30 tools would be more appropriate.
Completeness4/5
Despite the redundancy, the tool set covers a comprehensive range of Instagram read-only operations: users, media, stories, highlights, hashtags, locations, search, comments, and more. Missing write operations are acceptable for the server's apparent purpose. Minor gaps exist (e.g., no bulk operations), but overall coverage is strong.
Average 2.5/5 across 101 of 106 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on April 21, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description offers no behavioral details such as read-only nature, authentication needs, or side effects. The fragmented warning lacks clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but not concise; it is incomplete and confusing with a distracting 'Attention!' prefix. Every sentence should add value, but here it fails to communicate clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and many sibling tools, the description is severely inadequate. It does not explain what a 'media object' is, how the tool differs from others, or what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'url' is required, but the description only shows a truncated URL example. It does not explain the expected format, validation, or constraints, and schema description coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get media object' but is preceded by a truncated API path and an incomplete warning. It is too vague to distinguish from many sibling media retrieval tools like get_v1_media_by_id or get_v1_media_by_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. The truncated example does not convey usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits such as pagination, result format, rate limits, or whether it performs exact or fuzzy search. Completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but under-specifies; repetition of the tool name does not add value. Every sentence should contribute, but here it does not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter and no output schema, the description should at minimum clarify the return value (e.g., list of hashtag strings or objects). It is completely inadequate for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one required parameter 'query' (string) with 0% description coverage. The description does not mention or explain the parameter, its format, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description repeats the tool name and endpoint without specifying what information is returned (e.g., hashtag metadata, counts, suggestions). It does not differentiate from similar siblings like get_v1_fbsearch_topsearch_hashtags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 alternative search hashtag tools (e.g., get_v1_fbsearch_topsearch_hashtags, get_v2_search_hashtags). No context on prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as destructive nature, pagination, return format, or rate limits. The agent gets no insight into side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of necessary content. It is under-specified rather than concise, as it omits critical details about the tool's behavior and parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and the presence of many similar sibling tools, the description is far from complete. It provides no context on how this tool fits into the broader set of search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the parameters 'query' or 'page_token'. It adds no meaning beyond the schema titles, which are generic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search accounts' which is a verb+resource, but it is nearly a tautology of the tool name and provides no differentiation from siblings like get_v2_fbsearch_topsearch or get_v1_fbsearch_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no information on when to use this tool versus alternatives, no when-not-to-use scenarios, and no references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as read-only nature, auth requirements, rate limits, or side effects. The minimal description fails to inform the agent about tool behavior beyond the basic verb 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but it is under-specified rather than concise. It repeats the HTTP method and tool name without providing substance. Each sentence could earn its place, but the description lacks necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single parameter, the description should explain what the tool returns or provides. It fails to do so, leaving the agent with no understanding of the output or its structure. The description is incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'id' with no description coverage (0%). The description does not explain what 'id' represents or how to format it. No additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get media template,' which is vague and does not clarify what a media template is. Among many sibling tools with similar names, it fails to differentiate its purpose. The tool name and title provide no additional clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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. There is no mention of context, prerequisites, or exclusions. The description offers no help for decision-making among many similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., whether it is read-only, pagination, rate limits, or typical result structure). For a search tool, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is under-specified and repeats itself. It includes a redundant line break and fails to front-load critical information. Conciseness is not valuable without substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema but no output schema, the description should at least hint at the response type or search behavior. It is completely inadequate for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'query' has no description in the schema (0% coverage), and the tool description adds no guidance on what constitutes a valid query (e.g., track name, artist, lyrics). The agent cannot infer usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Music' which is vague and does not distinguish this tool from many sibling search tools like get_v1_search_users or get_v1_search_hashtags. The redundancy ('Search Music' followed by 'Search music') adds no clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the similar get_v2_search_music or other search endpoints. The description lacks context about the appropriate search scope or query format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits like authentication, rate limits, or pagination. It does not mention any such details, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to be informative. It includes a bracketed endpoint header that adds noise without value. Under-specification is not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is insufficient. It does not explain what 'places' means, the response format, or any constraints. The agent cannot use this tool correctly based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the parameter 'query', and the tool description provides no additional meaning. The agent gets no guidance on what values the query expects (e.g., text, location, format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search places' is a tautology of the tool name and fails to specify what kind of places or the scope of search. It does not differentiate from siblings like get_v1_fbsearch_places or get_v2_fbsearch_topsearch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description lacks context about use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or pagination. The tool likely performs a read operation but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified—repeating the name without substantive information. True conciseness should preserve clarity, which is absent here.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the abundance of sibling tools and lack of output schema, the description is critically incomplete. It does not explain what 'topsearch' returns, how results are structured, or how it differs from other search endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'query' lacks description in both schema (0% coverage) and tool description. The description adds no meaning about the query format, expected input, or its role in the search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description merely repeats the tool name 'Fbsearch Topsearch' without specifying what it returns (e.g., top users, places, or combined results). It fails to differentiate from siblings like get_v1_search_users or get_v1_fbsearch_places.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 the many sibling search tools (e.g., get_v1_search_hashtags, get_v2_fbsearch_topsearch). The description lacks any context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It merely says 'Search locations' without disclosing behavioral traits such as auth requirements, rate limits, expected response format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief but under-specified. The single sentence repeats the path and title with minimal added value. Essential information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is completely inadequate. It does not explain the response format, pagination, or any constraints on the search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage and the tool description adds no explanation beyond parameter names. The query parameter is required but its meaning is only implied by 'Search locations'; lat and lng defaults are given but no guidance on how to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Search locations' which is somewhat clear but vague. It does not specify what kind of locations (e.g., places, businesses) and fails to distinguish from similar sibling tools like get_v1_fbsearch_topsearch or get_v1_location_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are many search-related siblings (e.g., get_v1_fbsearch_topsearch, get_v1_fbsearch_topsearch_hashtags, get_v1_location_search) with no comparative context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks any behavioral details such as authentication requirements, read-only nature, or return value format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While short, the description is too terse to be useful; the bracketed path adds minor value but overall information density is extremely low.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema coverage and no output schema, the description fails to provide any meaningful context for a tool with many location-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'location_pk' is not described in the text, leaving its purpose and constraints entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get location guides' is nearly a tautology of the tool name, with no further elaboration on what a 'location guide' specifically entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v1_location_by_id or get_v1_location_search.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses no behavioral traits such as authentication needs, rate limits, side effects, or any constraints. The agent has no insight into what happens when calling this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but brevity comes at the cost of missing crucial information. It does not effectively convey the tool's purpose or usage, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 multiple siblings, the description lacks completeness. It does not explain the return value (no output schema), nor does it differentiate from similar tools. The description fails to provide a complete picture for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 explanation for the 'code' parameter. The title 'Media By Code' hints at its purpose, but the description does not clarify what a code is or how to obtain it. This leaves the parameter meaning ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'Get media object', which gives a clear verb and resource. However, it does not distinguish this tool from siblings like get_v1_media_by_id or get_v2_media_info_by_code, as it doesn't clarify what a 'code' is relative to other identifiers. The purpose is adequate but lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools that retrieve media by different identifiers (e.g., by id, by url), the description offers no context for choosing this one. This leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose that it is a GET (read-only), nor does it mention pagination, rate limits, or authentication requirements. The max_id parameter suggests pagination but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (2 sentences) but under-specified. It lacks meaningful content and is not an example of efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain the concept of 'usertag medias', chunking behavior, or expected response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 information about either parameter (user_id, max_id). The agent has no context on what values to provide or how max_id affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get usertag medias', which is a verb+resource but is vague. It does not differentiate from siblings like get_v1_user_medias_chunk or get_v2_user_tag_medias, and does not clarify that it returns a chunk (paginated subset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_v1_user_medias_chunk or get_v2_user_tag_medias. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only mentions 'GET' in brackets and a vague 'Whether to receive an offensive comment.' It does not clarify if this is a read-only operation, what side effects exist, or what the response looks like. Critical gaps in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the expense of clarity. The bracketed HTTP method and path are redundant given the tool name. The actual prose is ambiguous and does not earn its place. A single coherent sentence would be better.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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% parameter coverage, the description should provide comprehensive context. It fails to explain return values, error handling, or how the offensive check works. The tool is essentially undocumented for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 two parameters (media_id and comment). It does not explain what media_id or comment refers to, what format is expected, or how they relate to the check. The description fails completely to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Media Check Offensive Comment' and 'Whether to receive an offensive comment' is vague and uses passive language. It does not clearly state what the tool does (e.g., returns a boolean, checks a comment). The purpose is ambiguous compared to sibling tools like get_v2_media_comments or get_v2_media_likers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many sibling tools. Does not specify prerequisites, alternatives, or context. The description only hints at checking offensive comments but offers no decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details (e.g., pagination, rate limits, return structure). For a read-only search tool, disclosure of any constraints is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one line), but it is under-specific rather than concise. It lacks essential details and does not effectively communicate tool purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 is grossly incomplete. It fails to explain the return format, pagination behavior, or how this tool differs from siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the 'query' or 'page_token' parameters. The schema titles ('Query', 'Page Token') are minimally informative, and the description adds no value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search accounts' is vague and does not specify what type of accounts (e.g., user, business) or differentiate from siblings like get_v2_fbsearch_accounts or get_v1_search_users. The title 'Fbsearch Accounts' hints at Facebook search but lacks clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v1_fbsearch_topsearch or get_v2_fbsearch_accounts. Missing context about 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It is a GET request implying read-only, but this is not explicitly stated. No information is given about authentication requirements, rate limits, or what data is returned beyond a vague 'user object'. The description adds no value beyond the HTTP method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it includes redundant text ('User' and 'Get user object'). The structure with the path in brackets is somewhat informative, but the conciseness comes at the cost of clarity. It could be more efficient with a single clear sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is severely incomplete. It does not specify what fields or structure the returned user object has, nor does it provide any context about pagination, filters, or common usage patterns. For a simple tool, this minimalism is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'username' has no description in the schema (0% coverage), and the tool description does not clarify its meaning. It is unclear whether 'username' refers to an Instagram username, a user ID, or something else. The description adds no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get user object' with the HTTP method and path, clearly indicating the verb and resource. However, it does not differentiate from many sibling tools like get_v1_user_by_username or get_v2_user_by_username, making it unclear which user object is retrieved (e.g., by username, ID, or other criteria).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 the numerous similar user retrieval tools. There is no mention of prerequisites, alternatives, or specific use cases, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'get user's likers', implying a read operation but offering no additional behavioral traits like pagination, ordering, rate limits, or response format. The description adds minimal value beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two short lines), but conciseness is undercut by lack of useful information. It could be restructured to front-load the core action and clarify the parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, 0% parameter description coverage, and no annotations, the description is severely incomplete. An agent cannot determine the input semantics, output structure, or how to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the purpose or format of the required 'id' parameter (e.g., is it a media ID?). No value added beyond the schema's basic type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get user's likers' and title 'Media Likers', which suggests retrieving users who liked a media, but it's ambiguous whether 'user's' refers to the media owner or the media itself. It does not clearly distinguish from siblings like get_v1_media_likers or get_gql_media_likers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v1_media_likers or get_gql_media_likers. The description lacks any 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavioral traits. It only states it gets a chunk of recent medias, without mentioning authentication, rate limits, pagination details, or what a chunk entails. The behavioral disclosure is very limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two lines) but is under-specified rather than concise. It wastes space by repeating the title and HTTP method without adding useful information. The brevity misses opportunities to convey necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description is grossly incomplete. It does not explain the chunk concept, pagination via max_id, or expected response structure. The description is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters (location_pk, max_id) with 0% description coverage. The description does not explain any parameters, so it adds no meaning beyond the schema. It fails to compensate for the lack of parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get location chunk of recent medias' which indicates the verb 'get' and resource 'location medias recent chunk'. However, it is vague about what 'chunk' means compared to similar siblings like get_v1_location_medias_recent. The purpose is discernible but lacks specificity to distinguish from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not mention when to use this tool versus others like get_v1_location_medias_recent or get_v1_location_medias_top. There is no guidance on context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states it's a GET request that searches, but lacks details on behavioral traits like pagination, rate limits, or any side effects. The 'force' parameter's description is in the schema, not the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but wastes space reiterating the HTTP method and path in brackets, which is already implied by the tool name. The remaining content is minimal and does not provide sufficient information for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, low schema coverage, and no annotations, the description is severely incomplete. It does not explain what the tool returns, how to interpret results, or how it differs from numerous sibling tools, leaving the agent without critical context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'force' has a description). The tool description adds no explanation for 'user_id' or 'query', leaving the agent to guess their meaning. Given the low coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search users by followers' which indicates a search operation but is ambiguous: it could mean searching for users that are followers of a given user or searching for users based on their followers. The title 'Search Followers' leans toward the former, but the distinction from sibling 'get_v1_user_search_following' is unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are many sibling tools with similar names (e.g., get_v1_user_search_following, get_v1_user_followers_chunk), and the description does not provide any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose any behavioral traits like pagination (despite next_max_id parameter) or response format, leaving the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundant repetition of 'Search Music'; it could be more concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling search tools and lack of output schema, the description is incomplete; it fails to specify result expectations or scope, making it insufficient for complex decisions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning to parameters; it does not explain the 'query' purpose or the pagination mechanism for 'next_max_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Search Music' but is vague; it does not specify what is being searched (e.g., tracks, artists) and does not distinguish from sibling tools like get_v1_search_music.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_v1_search_music or other search endpoints; the description provides no context for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not mention any side effects, safety details, authorization needs, or return behavior, offering no transparency about the tool's actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains an error ('by id' instead of 'by url') and a helpful callout. While concise, the mistake undermines structure and accuracy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description should clearly explain what the tool does and how to use the url parameter. It fails to do so, leaving significant gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'url' parameter with 0% description coverage, and the description completely fails to explain how to use it. The misleading phrase 'by id' adds confusion instead of clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get story object by id' but the tool name indicates 'by url', creating inconsistency. It identifies the resource as a story object but fails to clearly align with the tool's function, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific warning: 'To work with /s/ links, call /v1/share/by/url first', offering guidance on when not to use this tool. However, it does not mention when to use this tool over siblings like get_v2_story_by_id or get_v1_story_by_url, leaving gaps in context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description omits any behavioral traits. It does not disclose return format, pagination, authentication requirements, or limitations. The burden falls entirely on the description, which fails to provide necessary context 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (2 lines) but at the cost of completeness. It repeats the HTTP method and endpoint already in the name and adds little value. The structure is minimal and lacks front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
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 only one parameter, the description should explain the response or behavior but does not. It is completely inadequate for a search tool, providing no context about what data is returned or how the tool behaves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'query' (string, required). Schema description coverage is 0%, meaning the description does not explain the parameter. The keyword 'Search' implies the query is a search term, but no details on format or examples are given, failing to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search places', which clearly indicates the tool searches for places using a query. However, it lacks specificity and does not differentiate from sibling tools like get_v1_fbsearch_places or get_v2_fbsearch_places, which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are multiple fbsearch_places tools, but the description does not explain differences or provide context for selecting this version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 the operation (GET, read-only implied) but omits details like idempotency, error behavior, 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but under-specified. It repeats the tool name and provides a path notation that is likely not useful for an agent. It fails to be effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description should explain what the media code is used for or how it relates to other media tools. This is missing, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'pk' parameter, and the description does not clarify its meaning (e.g., numeric ID, string format). No value is added beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get media code from pk', which clarifies the basic operation. However, it does not distinguish this tool from its inverse sibling get_v1_media_pk_from_code, leaving potential confusion for an agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v1_media_by_code or get_v1_media_pk_from_code. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only repeats the HTTP method and path. It does not disclose behavioral traits such as whether it requires authorization, the nature of the data (read vs write), or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) but lacks substance. It is not verbose but also not informative. It includes the HTTP path which is somewhat redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only one parameter, the description provides no useful context about the tool's behavior, response format, or how to interpret 'insight'. It is inadequate for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'media_id' with a basic title, and the description adds no additional meaning. With 0% schema description coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get media insight', which is somewhat specific but lacks detail on what kind of insight (e.g., engagement, reach). It distinguishes from siblings by mentioning 'insight', but many other media tools exist. The purpose is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v1_media_by_id or get_v1_media_likers. No context about prerequisites or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination (implied by reels_max_id), authentication needs, rate limits, or return format. The description is too brief to provide meaningful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two lines), but it lacks structure and substance. The HTTP path is included but not essential, and the single sentence fails to provide enough information. Under-specification is not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 3 parameters, many sibling search tools, and no annotations or output schema, the description is severely incomplete. It does not cover return values, pagination, or how to use optional parameters, making it inadequate for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for parameters. The description does not add any information about 'query', 'reels_max_id', or 'rank_token' beyond their names. The tool's purpose is implied but no parameter semantics are explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search top content by keyword', which combined with the tool name 'get_v2_fbsearch_reels' clearly indicates it searches for reels using a keyword. However, it does not explicitly distinguish this from sibling search tools like get_v2_fbsearch_topsearch or get_v2_fbsearch_accounts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 compared to other search tools. There is no mention of prerequisites, exclusions, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as pagination, rate limits, or side effects. It only restates the 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but wastes space by repeating 'Search hashtags' unnecessarily. It is under-specified and lacks structure or front-loading of key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 presence of many sibling hashtag search tools, the description is far from complete. It does not help an agent understand what the tool returns or how to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or format of the 'query' and 'page_token' parameters beyond their names. The agent gets no additional insight from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Hashtags' which is a clear verb+resource pair, but it is vague and does not differentiate from sibling tools like get_v1_search_hashtags or get_v2_fbsearch_topsearch, which likely also search hashtags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context for its appropriate use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only says 'Get user clips.' It fails to mention pagination (though page_id parameter exists), authentication needs, rate limits, or data scope, providing essentially no insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but lacks structure and essential context. It is under-specified, not concise in a helpful way. There is no front-loading of key information, and every sentence is almost tautological.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain return values, pagination behavior, or the concept of clips. Given the tool's complexity (pagination parameters), the description is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides, so it remains at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get user clips,' which indicates a specific verb and resource, but it lacks differentiation from sibling tools like get_gql_user_clips and get_v1_user_clips_chunk. No context is provided on what 'clips' refers to, reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites, constraints, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It only notes a prerequisite for /s/ links but omits any details about return structure, side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (two lines), which is concise, but the first line is a special note and the second is a simple statement. It could be clearer and more structured, but it avoids verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and parameter descriptions, the tool description fails to provide a complete picture. It does not specify what a highlight object contains, how to interpret the URL, or what the response looks like.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, and the description does not explain the 'url' parameter. Instead, it misleadingly says 'by id', contradicting the parameter name and adding no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get highlight object by id' but the tool is named 'get_v1_highlight_by_url' and accepts a 'url' parameter, creating confusion between id and URL. This misalignment reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a useful note about /s/ links requiring a call to /v1/share/by/url first, providing some usage guidance. However, it does not explicitly differentiate from sibling tools like get_v1_share_by_url or give scenarios for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description adds minimal behavioral context beyond the tool name. It does not mention pagination, rate limits, data freshness, or the definition of 'top'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is concise, but it lacks substance and does not prioritize key information. The HTTP path is included but not essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description does not provide enough context for an agent to understand the tool's functionality or select it appropriately among many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. With 0% schema coverage, the burden is high, but the description fails to clarify what 'location_pk' and 'amount' represent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get location top medias' is clear about the verb and resource, but it does not differentiate from siblings like get_v1_location_medias_recent or the chunked versions. The meaning of 'top' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 recent medias or chunked endpoints. There is no mention of conditions or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It does not explain what is returned, pagination, ordering, or any side effects. The tool appears to be a read operation but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it sacrifices clarity for brevity. It fits in two lines but lacks essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should at least explain the parameter and the expected response. It fails to do so, leaving the agent uncertain about correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' has no description in the schema and a 0% coverage. The description does not clarify that 'id' refers to the media ID. No additional meaning is provided beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get user's likers' and provides the endpoint path, but it's ambiguous whether it means likers of a specific media or a user's media. The term 'Media Likers' is clearer but still lacks specificity. Among siblings like get_gql_media_likers and get_v2_media_likers, no differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No mention of prerequisites, authentication, rate limits, or any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No behavioral traits are disclosed beyond the billing note. Since no annotations are provided, the description should carry the burden, but it omits information on side effects, permissions, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but at the expense of clarity. It reads more like a note than a tool definition. Every sentence should add value, but here the focus is on performance and billing rather than the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description should explain what the tool returns, but it does not. There is no differentiation from sibling tools like get_v1_user_highlights or get_v2_user_highlights_by_username. The context provided is insufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no meaning to the parameters. The schema has a description only for 'force' (skip privacy check), and the description does not explain what 'amount' does or how the tool uses 'username'. Schema description coverage is low (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.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state that the tool retrieves user highlights by username. It begins with the endpoint path but lacks a verb like 'get' or 'fetch'. The mention of an alternative endpoint implies the purpose, but it is not directly clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage guideline by suggesting the by/id endpoint for speed. However, it does not specify when to use this tool (e.g., when you only have a username) or any other 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details such as return format, pagination, authentication requirements, or rate limits. The description is too sparse to cover the needed behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two lines), but it omits critical information. It is under-specified rather than concise, lacking necessary detail for effective tool usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description should provide more context. It only restates the endpoint and a vague action, which is insufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter explanation in the description, the 'query' parameter is left entirely unexplained. The description adds no meaning beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Search hashtags via topsearch', which clearly indicates the tool's action and resource. However, it does not differentiate from similar siblings like get_v1_fbsearch_topsearch or get_v1_search_hashtags, lacking precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention when topsearch is appropriate or any exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as authentication requirements, error handling, rate limits, or side effects. For a mutation tool (GET but still needs transparency), 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive ('Get user object by URL' appears twice). It could be more concise without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, and the description provides no information on return structure, error scenarios, or limitations. Given the tool's single parameter and lack of annotations, it is severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds no value beyond the parameter name. It does not specify expected URL format, constraints, or examples, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user object using a URL. It is specific about the resource and operation, but does not differentiate from sibling tools like get_v1_user_by_username or get_v1_user_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. The description does not mention prerequisites, preferred scenarios, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a billing note ('2 requests per call'), which is helpful, but no annotations are provided. It does not disclose whether the operation is read-only, what the 'force' parameter does regarding privacy checks, or other behavioral traits beyond billing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two sentences) but is not well-structured. The first line gives the endpoint, the second is a billing warning. It is concise, but the brevity sacrifices clarity and completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is highly incomplete. It fails to explain return values, the meaning of 'highlights', or how parameters affect results. The billing note is the only extra context, which is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'force' has a description). The description adds no additional meaning to the parameters; it does not explain 'user_id', 'amount', or the context of 'force'. With low coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'User Highlights' and gives the endpoint path, indicating it retrieves highlights for a user. However, it does not clarify what user highlights are or use a verb, making the purpose somewhat vague. It is differentiated from siblings that use username or v2 endpoints, but not clearly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v1_user_highlights_by_username or get_v2_user_highlights. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only includes billing information (2 requests per call). It does not disclose behavioral traits such as mutability, side effects, or response structure. Since annotations are absent, the description fails to compensate for the lack of 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two lines), which is efficient, but it sacrifices necessary detail. Every sentence is short, but the overall structure lacks completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and multiple siblings, the description is woefully incomplete. It fails to clarify return values, parameter usage, or how it differs from similar tools, making it insufficient for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema description coverage, the description adds no explanation for the parameters. It does not mention 'user_id', 'amount', or provide context beyond what is in the schema, leaving the agent unclear about their semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'User Stories' and provides the endpoint path, giving a basic idea that it fetches user stories. However, it lacks specificity about what constitutes a user story (e.g., Instagram stories) and does not differentiate from sibling tools like get_v1_user_stories_by_username.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings. The description does not mention filtering, prerequisites, or alternatives, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
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 whether the operation is read-only, authentication requirements, rate limits, or side effects. The description only states the action without any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes a URL pattern, which is somewhat redundant. It is concise but lacks necessary detail; the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about the response, errors, or usage. It only states the basic retrieval function, leaving the agent with insufficient information to invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'id' is required and typed as string, but the description adds no additional meaning such as format, source, or example. With 0% schema description coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a story object by its ID, using the verb 'Get' and specifying the resource 'story object'. It is specific enough to understand the basic purpose, but does not differentiate from similar sibling tools like get_v1_story_by_id or get_v2_story_by_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v1_story_by_id or get_v2_story_by_url. The description lacks any context about preconditions, fallbacks, or scenarios 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It mentions 'one request required' and pagination, but these are contradictory. It doesn't explain auth requirements, rate limits, or what happens with the response (e.g., format or pagination details).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundant and conflicting elements. The 'Prefer' note is useful but placed awkwardly, and the 'one request required' phrase is confusing. Could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations. The description fails to explain what the response contains (list of users?), how pagination works, or how this tool differs from siblings like get_v1_user_following_chunk or get_g2_user_following. The confused messaging leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are well-described there. The description adds no new information about parameters beyond the schema, so it meets the baseline but doesn't provide extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is confusing: 'Get a user following (one request required)' combined with 'Get part (one page) of following users' is contradictory. It also suggests preferring /g2/user/following without clear differentiation, making the purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. The statement 'Prefer /g2/user/following' hints at a better option but doesn't explain why or when, leaving the agent without proper direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds billing info (3 requests per call) and speed caveat. However, does not disclose auth needs, limit, error behavior, or side effects. The billing note adds some value but leaves major gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and to the point, but at the cost of clarity. Could include a one-sentence purpose. The billing and speed note are relevant but not enough to earn higher conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description is incomplete. It does not specify what is returned, how pagination works, or what the 'force' parameter actually does. The speed alternative hint helps but overall leaves agent guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%) with only 'force' having a schema description. The description does not explain any parameter meaning, e.g., 'amount' or relationship between 'username' and 'force'. No added value over schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description does not explicitly state what the tool does. It starts with endpoint path and mentions a faster alternative, but purpose (retrieving user highlights by username) is only implied by the tool name and context. No verb or clear description of the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides one guideline: use by/id endpoint for speed. But lacks guidance on when to use this tool vs alternatives, prerequisites, or scenarios where it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies read-only via HTTP GET but doesn't disclose behavioral traits like rate limits, authorization needs, or what 'user medias' includes. The flat parameter's effect is only in schema, not description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive ('Returns the user medias' then 'Get user medias'). It could be more efficient and structured. Not overly long, but contains redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and many siblings, the description lacks completeness. It doesn't explain pagination (cursor), flattening behavior, or what constitutes 'user medias'. The tool is underdescribed for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33% (only flat has a description). The description does not explain any parameter. For a low-coverage schema, the description should compensate but fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Returns the user medias' which is clear but generic. It includes the HTTP path but doesn't differentiate from many similar sibling tools like get_v1_user_medias_chunk or get_gql_user_clips. The purpose is vaguely conveyed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. Does not mention pagination, cursor usage, or when to set flat=true. The description offers no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as pagination support (implied by the parameter repost_next_max_id), authentication requirements, or rate limits. It simply states the function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains repetition ('Get user's reposted content' and 'Get user media reposts'). It could be more concise by combining into one sentence. Still, it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, annotations, and low schema coverage, the description is incomplete. It does not explain the response format, pagination logic, or how to use the pagination parameter. The flat parameter's effect is unclear without schema context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. Schema coverage is only 33% (flat parameter has a description), but the description adds no meaning beyond what is already in the schema. The repost_next_max_id parameter, which indicates pagination, is completely ignored.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get user's reposted content' and 'Get user media reposts', which clearly indicates the verb (get) and resource (user reposts). The tool name also includes 'reposts' which distinguishes it from siblings like get_gql_user_medias, but the description itself does not differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not specify prerequisites, typical contexts, or scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, rate limits, or what 'chunk' means (e.g., cursor-based pagination). The parameter name has a good description in the schema, but the description itself 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no unnecessary words. However, it sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the many sibling hashtag tools, the description is incomplete. It does not explain the chunking mechanism, and there is no output schema. The tool's complexity (pagination, recent vs top) is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds nothing beyond the input schema; the name parameter is already well-described in the schema, and max_id has no description. With 50% schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets hashtag medias, but uses vague terms like 'chunk' and 'top recent' without explaining what distinguishes it from sibling tools like get_v1_hashtag_medias_top_chunk and get_v1_hashtag_medias_clips_chunk. The purpose is somewhat clear but not specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no mention of pagination or that it returns a subset. The agent would need to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavior but only states 'Get location recent medias'. It does not disclose pagination, authentication needs, error handling, or any constraints, providing 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, but the first line repeats the endpoint path already in the tool name, adding redundancy. The second line is a simplified rephrase. It is concise but could be more efficient by removing the endpoint line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and no output schema, the description is incomplete. It fails to clarify return format, parameter details, or selection criteria, insufficient for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters with no descriptions (0% coverage), and the tool description adds no meaning beyond the schema. For instance, the 'amount' parameter's unit or behavior is not explained, leaving the agent guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get location recent medias', clearly indicating the verb 'get' and resource 'location recent medias'. However, it does not distinguish from sibling tools like 'get_v1_location_medias_top' or the chunk variants, missing an opportunity to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives such as 'get_v1_location_medias_top' or the chunk endpoints. The description lacks context for selection, leaving the agent uninformed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It only states it's a GET for top medias chunk but does not explain pagination (e.g., use of max_id), rate limits, authentication needs, or what 'chunk' entails in terms of size or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a redundant HTTP method line). It is concise but at the expense of necessary detail. The bracketed '[GET /v1/location/medias/top/chunk]' adds no value as it repeats the tool's name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema, annotations, and parameter explanations, the description is woefully incomplete. It fails to clarify pagination, response format, or how this tool differs from siblings. For a 2-parameter tool with no structured context, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not mention or explain the two parameters (location_pk and max_id). Despite the schema having titles like 'Location Pk' and 'Max Id', the description adds no value to clarify their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get location chunk of top medias', which provides a clear verb and resource. However, it does not differentiate from sibling tools like 'get_v1_location_medias_top' (which may return all top medias) or 'get_v1_location_medias_recent_chunk' (which returns recent chunks). The word 'chunk' hints at pagination, but this is not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of use cases, prerequisites, or when not to use. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as idempotency, read-only nature, or required permissions. It only states the 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant information: the HTTP method and heading are not essential and waste space. It could be more concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and many siblings, the description is insufficient. It does not explain what 'pk' or 'code' means, nor what the output represents, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 additional meaning to the 'code' parameter beyond what is in the schema. The parameter is self-explanatory, but the description should compensate for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get media pk from code' clearly states the verb and resource, but does not differentiate from sibling tools like get_v1_media_by_code or get_v1_media_code_from_pk, making it vague in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description lacks any context about use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose essential behavioral traits such as idempotency, authentication requirements, or error handling. The minimal description offers no insight into side effects or constraints beyond the vague 'Get story object'. The tool's behavior is largely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, with only one functional sentence and an attention note. It is front-loaded with the HTTP path and key caveat. No redundancy; every part adds information. However, the note's placement before the main purpose could be confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input schema (one param) and no output schema, the description should clearly define input constraints, output shape, and when to use alternatives. It fails to do so, leaving gaps about error scenarios and response structure. The 'by id' misstatement undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'url' is of type string, but the description adds no semantic value—it incorrectly refers to 'by id' instead of 'by url'. With 0% schema description coverage, the description should clarify URL format (e.g., full vs. short link, required prefix) but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description claims 'Get story object by id' but the tool name and parameter expect a URL, contradicting the resource identifier. Sibling tool get_v1_story_by_id exists, but no differentiation is provided. The attention note about /s/ links adds confusion rather than clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The attention note explicitly advises using get_v1_share_by_url first for /s/ links, offering some guidance on when to avoid this tool. However, it does not specify when to use this tool over other story-related siblings (e.g., get_v1_story_by_id, get_v1_story_download). The guidance is incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not reveal behavioral traits such as what the download returns (e.g., file content, URL), authorization needs, rate limits, or file format. The tool likely produces a file download, but this is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but redundant, repeating the same sentence twice. It could be more concise and front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and lack of output schema, the description should at least hint at what 'download story file' entails (e.g., file format, size). It is incomplete and does not prepare the agent for the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning beyond the schema. The parameter 'url' is mentioned only in the example (which is truncated), with no explanation of format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Download story file by story URL' with a specific verb and resource. However, it does not differentiate from siblings like get_v1_story_download and get_v1_story_download_by_url, which have nearly identical names and purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_v1_story_download or get_v1_story_download_by_url). No context about prerequisites, limitations, or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose any behavioral traits such as authentication requirements, rate limits, or response format. Assumes basic retrieval with no additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the second ('Get user medias') is redundant with the first. Could be merged into one concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and minimal annotations, the description falls short. It does not clarify what 'pinned medias' means or how the response is structured.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; the description does not explain the purpose or constraints of parameters like 'amount' (default 33). No value added beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get pinned medias' with a clear verb and resource, and the phrase 'pinned' distinguishes it from general media retrieval tools. However, the repetition does not add clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v1_user_medias_chunk or other media-related tools. The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention the response format, pagination, rate limits, or the effect of the 'force' parameter (skipping privacy check). The minimal description leaves the agent unaware of important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise but at the expense of necessary details. It is not front-loaded with important information; instead it repeats the HTTP method and path in a bracket prefix. While brief, it could be restructured to highlight the core functionality first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters, no output schema, and many similar sibling tools (e.g., search users, search followers), the description is too vague. It does not explain what is returned, how results are filtered, or how it differs from related endpoints. The agent cannot reliably use this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema coverage (only 'force' has a description), the description adds no additional meaning for 'user_id' or 'query'. It does not explain what values are valid or how they affect the search. The tool description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Search Following' and 'Search users by following users', which gives a general idea but is ambiguous: it could mean searching for users that a user follows or searching by following criteria. It does not clearly specify that it searches within a user's following list using a query string, and lacks explicit mention of the required user_id and query parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like get_v1_user_search_followers, get_v1_search_users, or get_v1_user_following_chunk. The description fails to mention the use case of searching within a specific user's following list, leaving the agent without 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions a return limit of 15 comments per request, implying pagination, but lacks details on authentication, rate limits, or behavior when no comments exist. Annotations are absent, so the description carries full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences; the first includes the API endpoint path which is redundant and could be removed. The structure is acceptable but not optimally concise for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, incomplete parameter descriptions, and missing behavioral details. The tool is moderate complexity (3 params, 1 required) but the description does not sufficiently guide an agent on proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters with 0% description coverage. The tool description adds no explanation for any parameter (id, can_support_threading, page_id), leaving their purpose and valid values entirely unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves media comments and specifies a return limit of 15 comments. However, it does not differentiate from sibling tools like get_v1_media_comments_chunk or get_v2_media_comments_replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_v1_media_comments_chunk for chunked access, get_v2_media_comments_replies for replies). No context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only mentions billing. It does not disclose that the tool performs a read operation, any privacy implications of the 'force' parameter, or other behavioral traits like 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence, but it lacks detail. It is well-structured with the endpoint and title front-loaded, but the brevity comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description is insufficient. It does not cover return values, pagination, or parameter behavior, leaving an agent inadequately informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 33% description coverage (only 'force' described). The tool description adds no parameter information, failing to explain 'user_id' and 'amount' beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'User Highlights' and the endpoint indicates fetching highlights for a user, but it does not clarify what constitutes a 'highlight' or distinguish it from sibling tools like get_v1_user_highlights or get_v2_user_highlights_by_username.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The billing note is present but does not help with usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only mentions billing (2 requests per call) but does not state that it reads data, whether authentication is needed, or what the response contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and efficient, but it lacks critical information. It is not overly verbose, but the conciseness comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, and the description does not explain return values. Given the presence of many sibling tools, the description should provide more context to differentiate and guide usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67% (2 of 3 params have descriptions). The tool description adds no additional meaning to parameters; user_id is not explained despite lacking a schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'User Stories' and the endpoint but does not explicitly say it retrieves stories for a user. It provides a basic purpose but is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 siblings like get_v1_user_stories or get_v2_user_stories_by_username. The description does not mention prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds a billing warning (3 requests per call), which is a useful behavioral trait. However, it lacks other important information such as authentication requirements, side effects, or return value characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences plus a warning), which is concise, but it is not well-structured. The purpose is not front-loaded, and the billing warning is placed at the end. It is adequate but missing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, and no annotations. The description does not state what information is returned, how to interpret results, or any prerequisites. It only provides a billing note and a comparison to another endpoint, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two of three parameters have descriptions in schema, but 'username' has only a title). The description itself does not mention any parameters or add meaning beyond the schema. Since coverage is below 80%, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description does not explicitly state what the tool does. It mentions the endpoint URL and gives a speed comparison, but it fails to clearly specify that this tool retrieves user stories by username. The purpose is implied rather than stated, making it vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the 'by/id' endpoint for better speed when efficiency is critical, providing some guidance on when not to use this tool. However, it does not elaborate on when to use this tool or provide any other usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose important behavioral traits such as rate limits, data freshness, or how the cursor-based pagination works. The phrase 'one request required' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but slightly redundant (including the endpoint path). It front-loads the core purpose but lacks structured clarity for the pagination mechanism.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and two parameters, the description is insufficient. It does not explain how to paginate, what the response format is, or any edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description mentions 'cursor' but does not explicitly map it to the page_id parameter. It adds minimal meaning beyond the schema, which itself lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a page of following users using a cursor. The HTTP method and path are included, but it does not differentiate from sibling tools like get_g2_user_followers or get_v1_user_following_chunk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With multiple sibling tools for user following, the description lacks use-case differentiation or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'Get likers on a comment'. It does not disclose that this is a paginated endpoint (chunk), that media_id is deprecated, or any rate limits or authentication needs. The agent gains no insight into side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two sentences), but it is not concise in a helpful way; it omits necessary details. It does front-load the purpose but fails to provide value beyond the name and title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no annotations, no output schema, and 0% schema coverage, the description is severely lacking. It does not cover pagination behavior, required parameters, deprecated fields, or response expectations. The agent would struggle to use this correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The description adds no meaning to parameters beyond their names. For example, 'end_cursor' for pagination is not explained, and 'media_id' being deprecated is only in the schema (deprecated: true) but not in description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get likers on a comment', which clearly identifies the resource (comment likers) and action (get). The name includes 'chunk', indicating paginated retrieval, though not explicitly stated. Among sibling tools, this distinguishes itself from media likers and user chunk tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_gql_media_likers or other paginated chunk endpoints. No mention of prerequisites (e.g., requiring comment_id) or context where this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, yet the description only states the basic operation. It does not disclose read-only nature, authentication needs, or pagination behavior, leaving important gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant second line ('Get user clips') that echoes the name. It could be tighter but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, lack of output schema, and no annotations, the description is incomplete. It omits pagination details, sorting behavior, and the effect of the flat parameter, which are essential for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only 'flat' has a description). The description adds no value to parameters like user_id, max_id, or sort_by_views, failing to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the user's short video posts (reels), including the endpoint path. However, it does not differentiate from sibling tools like get_v2_user_clips or get_v1_user_clips_chunk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions billing (2 requests per call) but does not disclose behavior regarding pagination, rate limits, or account privacy checks (though 'force' parameter hints at it). The return format 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence), but it includes useful billing info and the API path. However, it lacks necessary details to be fully self-contained. It's not overly verbose, but conciseness here comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It does not explain how to use pagination (end_cursor), the effect of 'force', or what the response contains. The complexity of a chunked follower fetcher is not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'force' has a description). The tool description adds no parameter information beyond the schema. 'user_id' and 'end_cursor' are not explained, relying on the schema which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a user's followers and includes the API path. However, the phrasing 'Get a user followers' is slightly grammatically awkward and doesn't explicitly mention the required 'user_id' parameter. It distinguishes from siblings like 'get_gql_user_following_chunk' via the noun 'followers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sibling tools like 'get_v1_user_followers_chunk' or 'get_gql_user_following_chunk'. The phrase 'one request required' is ambiguous and does not explain pagination or batch usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Get user profile info' with no details on returned structure, side effects, permissions, or rate limits. Lacks necessary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but repetitive: repeats 'Get user profile info' and 'GraphQL web_profile_info' in two lines. Could be combined into one concise sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and many siblings, the description is too sparse. It lacks detail on what kind of profile info is returned, authentication needs, and how it differs from other user info endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description only adds 'by user id' to the parameter. No format, example, or constraint explanation beyond the schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States verb+resource clearly: 'Get user profile info by user id'. However, does not differentiate from many sibling tools like get_v1_user_about, get_v2_user_by_id, etc. The mention of GraphQL is subtle but not explicitly justified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the numerous similar sibling tools. No mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description lacks behavioral details such as pagination, rate limits, or side effects. The term 'chunk' is undefined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short (2 lines) but not overly concise; it misses essential information. Front-loading is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and many siblings, the description is incomplete. It does not explain chunk mechanism, response format, or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (only 'name' described). The description adds no parameter info beyond the schema, failing to explain 'max_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get hashtag chunk of clips (reels)', clearly indicating the action and resource. It distinguishes from siblings like get_v1_hashtag_medias_top_chunk by specifying 'clips (reels)'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other hashtag medias tools. Siblings include many similar tools, but no usage context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions 'chunk', implying pagination. It fails to disclose behavioral traits like rate limits, error conditions, or the nature of 'top' medias.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, but it is also under-specified. It repeats the title and provides minimal additional information. Structure is acceptable but not efficient given the lack of detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is incomplete. It does not explain chunking behavior, how to paginate with max_id, the meaning of 'top', or how this tool fits among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the 'name' parameter well with examples and cleaning instructions. However, the 'max_id' parameter is completely undocumented in both schema (no description) and tool description. The description adds no value beyond the schema for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a chunk of top medias for a hashtag, and includes the REST path. However, it does not differentiate from siblings like get_v1_hashtag_medias_clips_chunk or get_v1_hashtag_medias_top_recent_chunk, which also deal with hashtag medias in chunks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., clips, recent), nor on how to effectively use the max_id parameter. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only states that the tool 'gets locations' but does not explain whether it is read-only, the nature of the search (fuzzy or exact), expected response format, or any rate limits or prerequisites. This lack of detail leaves significant behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines of actual content), which is efficient but leaves out critical information. It is not overly verbose, but the brevity comes at the cost of completeness. A well-structured description would front-load the key action but still provide necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (search tool with many siblings, no output schema, no annotations), the description is insufficiently complete. It does not mention what the tool returns (e.g., location objects with fields like name, address, etc.), how many results, or any pagination or ordering. This lack of context hinders an agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'lat and long' but does not clarify their format, valid ranges, or coordinate system. Although the parameter names are self-explanatory, the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves locations using latitude and longitude, which is a specific verb and resource. It is distinct from siblings like get_v1_location_by_id (which uses an ID) and get_v1_fbsearch_places (which likely uses text search). However, it does not explicitly distinguish itself from other search tools, so it loses some points for not explicitly stating its unique use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it is for coordinate-based searches, nor does it reference sibling tools that might be better suited for other scenarios. Without usage context, an AI agent may struggle to select the correct tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits such as authentication requirements, error behavior for invalid IDs, or rate limits. The bare minimum 'Get media object' provides no insight into the tool's behavior 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—one line—but it is not a tautology. However, the brevity sacrifices clarity and fails to provide essential details, making it minimally adequate but not well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete. It does not specify the return format, potential errors, or how this tool fits among the numerous sibling media retrieval tools, leaving gaps in the agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'id' with no description (0% coverage). The description does not elaborate on what the ID represents, its format, or how to obtain it, leaving the agent with insufficient information to correctly set the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get media object', clearly indicating the verb-retrieve and resource-media. However, it does not differentiate from sibling tools like get_v1_media_by_code or get_v1_media_by_url, which also retrieve media objects but by different identifiers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many other media retrieval tools. No context on prerequisites or alternatives, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It mentions returning info but omits whether it is a read operation, authentication needs, rate limits, or side effects. The description is insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but includes an unnecessary endpoint identifier and title. It could be more concise while adding value. Structure is acceptable for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return structure. It vaguely mentions 'info about media and user' without specifics on fields, pagination, or error handling. The tool's simplicity slightly mitigates the gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description should add meaning beyond the field names. The description says 'from post URL' but does not specify URL format, required scheme, or provide examples. The single required parameter lacks semantic depth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Return info about media and user from post URL', clearly indicating the tool retrieves embedded information. However, it does not differentiate from other media-related sibling tools like get_v1_media_by_url, which may also return similar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools for media retrieval, the lack of usage context forces agents to guess the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It mentions 'GET' but does not describe authorization needs, rate limits, pagination behavior (despite next_max_id parameter), or what 'top' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes an unnecessary HTTP method prefix ('[GET /v2/fbsearch/topsearch]') which could be omitted. It is concise but could be more informative without additional length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 a poorly documented parameter (next_max_id), the description lacks completeness. For a search tool with many siblings, it should explain the result type and pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It hints that 'query' is for keyword search but provides no detail about 'next_max_id' (e.g., pagination token). It adds marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search top content by keyword', which indicates a search tool for top content. However, it does not differentiate from siblings like get_v2_fbsearch_accounts or get_v2_fbsearch_reels, which also search but for specific types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling search tools (e.g., get_v1_fbsearch_topsearch, get_v2_search_hashtags), the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It only states 'get', implying a read operation, but does not disclose error handling, idempotency, or what happens if the hashtag does not exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes a code snippet, but the main sentence is concise. It could be more structured with additional context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple one-parameter tool with no output schema or annotations, the description is minimal. It does not cover expected response, potential errors, or any behavioral aspects beyond the basic operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'name' parameter. The description merely repeats 'by name', adding no extra meaning about format, case sensitivity, or exact match requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a hashtag object by name. However, it does not distinguish itself from the sibling tool get_v1_hashtag_by_name, which serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v1_hashtag_by_name or search-related tools. The description lacks context about the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention authentication, rate limits, or what happens if the hashtag does not exist. The term 'chunk' hints at pagination but 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but not efficiently informative. The first line repeats the endpoint, and the second line is minimal. While not verbose, it lacks sufficient detail, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description is incomplete. It does not explain the return format, pagination behavior, or how to interpret the 'chunk' of medias. More context is needed for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only 50% description coverage (only page_id has a description). The description adds nothing about the 'name' parameter, which is required and unclear (e.g., it does not say it is the hashtag name). Thus, it fails to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets a chunk of recent medias for a hashtag, which is clear and distinguishes it from sibling tools like 'top' medias. However, it does not explicitly compare to other chunk endpoints like get_v1_hashtag_medias_top_recent_chunk, so slight lack of differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other hashtag media tools (e.g., top, clips). There is no mention of prerequisites or pagination context, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose behavioral traits such as authentication needs, rate limits, or error handling. Minimal mention of pagination ('chunk') but lacks specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short but includes redundant bracket notation. It is front-loaded with endpoint but could be clearer and more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and no output schema, the description is insufficient. It lacks information on response structure, error states, and required permissions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%; description adds no additional meaning beyond the schema. The 'name' parameter is not documented beyond its title, and the page_id description in schema is not reiterated. Description does not compensate for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets 'top medias' for a hashtag. However, it does not differentiate from siblings like get_v1_hashtag_medias_top_chunk or get_v2_hashtag_medias_recent, lacking specificity on what 'top' means vs 'recent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool instead of siblings. No context on prerequisites, expected input format, or conditions for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions pagination by min_id but does not disclose any other behavioral traits (e.g., ordering, rate limits, response structure, or whether all replies are returned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences), but the first line includes a technical endpoint reference that may be noise. It is concise but lacks completeness, sacrificing necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is incomplete. It does not explain the return format, how pagination works beyond min_id, or what the response contains (e.g., nested replies structure).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only adds context for the min_id parameter (pagination). The media_id and comment_id parameters are left with only their titles, offering minimal additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('media comment replies'), and mentions pagination by min_id. However, it does not differentiate from sibling tools like get_v2_media_comments (which retrieves top-level comments), leading to potential confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_v2_media_comments for top-level comments). It does not specify prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like pagination or error handling, but only states 'Get music track object'. Missing details on response format, auth, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description includes the redundant HTTP path in brackets and a title line, but is otherwise short. Could be more concise by removing redundant elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks context on pagination via page_id, output structure, and how to handle results. Incomplete for a tool with optional pagination and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the canonical_id parameter beyond the schema, and the schema already has 50% coverage. No additional meaning is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a music track using a canonical_id, but fails to distinguish it from sibling tools like get_v2_track_by_id, which uses a different ID type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as pagination behavior, error handling, rate limits, or the nature of the operation (read-only). The minimal description fails to inform the agent beyond the basic retrieve action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 11 words, but it lacks important structure and details. While front-loaded with the endpoint and title, it omits essential usage context, making it less efficient for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 a complex context with many sibling tools, the description is incomplete. It fails to explain pagination (implied by 'page_id'), return object structure, or any side effects. The agent needs more information to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 50% description coverage (only 'page_id' has a description). The tool description adds no extra meaning for the required 'track_id' parameter, and the page_id description is already in the schema. The description does not compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get) and resource (music track object by id), making the purpose straightforward. It implicitly distinguishes from sibling tools like 'get_v2_track_by_canonical_id' and 'get_v2_track_stream_by_id' by specifying 'by id', but lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are no instructions on prerequisites, context, or exclusions, leaving the agent with no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'Get music track object by id' without disclosing behavioral traits such as read-only nature, auth requirements, pagination behavior (despite page_id parameter), or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief with two sentences and a title, but it lacks structure and essential details like pagination behavior or sibling differentiation. Its conciseness is underinformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of a pagination parameter, the description should explain pagination behavior, but it does not. It also fails to differentiate from similar tools, making it incomplete for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds no meaning for the required 'track_id' parameter; it merely says 'by id'. The optional 'page_id' parameter is already described in the schema. With 50% schema description coverage, description fails to compensate for the undocumented 'track_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get music track object by id' with a verb and resource. However, it does not differentiate from sibling tool 'get_v2_track_by_id' which also gets a track by id, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'get_v2_track_by_id' or 'get_v2_track_by_canonical_id'. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must bear the full burden of behavioral disclosure. It only states 'Get user object by id' without mentioning authentication, rate limits, or any side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, consisting of a header and a single line. While concise, it omits critical details; however, it is not overly verbose. The structure front-loads the endpoint and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is incomplete. It does not explain the return object, any pagination, or how to handle errors. The tool is underspecified for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the 'id' parameter (0% coverage), and the description adds no meaning beyond what the schema provides. It does not clarify whether the ID is numeric, a string, or any format constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a user object by ID (verb+resource). However, it does not differentiate from sibling tools like get_v1_user_by_id or get_v2_user_by_username, which is a notable gap given the many similar user tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v2_user_by_username or get_v1_user_by_id. Given the abundance of sibling tools, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention authentication requirements, rate limits, idempotency, or any side effects. The description only states the basic operation, leaving significant behavioral unknowns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two sentences) but contains nearly identical rephrasing. It could be condensed into one clear sentence without loss. It earns a 3 for conciseness but loses points for redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single parameter, no output schema, and no annotations, the description is insufficient for full understanding. It does not explain what 'recommended accounts' means, how the category is determined, or what the response contains. Compared to sibling tools, it feels incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description adds no meaning beyond the parameter name 'user_id'. It does not clarify whether this is the user whose recommendations are sought or the target user, nor does it specify format or constraints. The description only parrots the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves recommended accounts for a business category by user ID. The verb 'Get' and resource 'recommended accounts' are specific. However, it repeats the same information in two sentences and does not differentiate from sibling tools like get_v2_user_suggested_profiles, which may also provide recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, context for use, or when not to use it. Among many sibling recommendation tools, the description offers no decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 pagination with a cursor but does not disclose edge cases, error handling, rate limits, or whether it is a read-only operation. The phrase 'one request required' is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences are efficiently written with no fluff. The first sentence states the endpoint and purpose, the second adds pagination detail. Could be slightly more concise but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a paginated list operation with no output schema. The description lacks details on pagination mechanics, return format, or how it differs from sibling follower tools. More context is needed for effective usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only hints that page_id is a cursor. user_id is self-explanatory from the name, but the description adds minimal meaning beyond the schema. For 0% coverage, it should provide clearer parameter explanations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a user's followers, one page per request with cursor. The verb 'get' and resource 'user followers' are specific. However, it does not differentiate from sibling tools like get_v1_user_followers_chunk or get_v2_user_followers, which have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Does not mention prerequisites, pagination strategy, or why to choose this over many similar follower endpoint tools in the same server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral disclosure: only mentions read operation and batch limit. No annotations provided, but description fails to cover authentication, rate limits, or handling of invalid IDs. Contradicts no annotations, but insufficient for a no-annotation scenario.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Redundant: the same sentence appears twice. While short, the repetition wastes space and suggests poor editing. The endpoint path is front-loaded but not necessary for understanding usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and simple parameter, description lacks detail on return format (usernames, IDs?), pagination, or error scenarios. Does not fully equip an agent to handle responses or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds the crucial constraint of 'up to 10 media ids' which is not in the schema. However, it does not explain the format or provenance of media IDs, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States it returns users tagged in the video and specifies the parameter count (up to 10 media IDs). Clear verb+resource but doesn't distinguish from similar sibling tools like get_v1_media_likers or get_v1_media_user.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Only describes functionality without context for selection among many similar media-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the basic action, without disclosing potential side effects, authentication needs, rate limits, or error behavior. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Minimal text, not verbose. But the structure is flat; it could be improved by front-loading the purpose and adding structured detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given many sibling user-retrieval tools, the lack of usage guidance and output schema makes it incomplete. The agent lacks info on return format and when to prefer this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'id' has no description in schema (0% coverage) and the tool description adds no extra meaning, example, or format hint. The agent gets no helpful semantic beyond the schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user object by id' – a specific verb and resource. It distinguishes from siblings that retrieve by username or URL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v1_user_by_username or get_v1_user_by_url. The agent must infer from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions pagination with a cursor but doesn't explain how cursors work, what the 'one request required' means, or any behavioral details like rate limits, authentication, or error handling. Lacks transparency given no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a parenthetical; no wasted words but slightly unstructured. Could be more informative without major length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (2 params, no output schema), the description lacks essential details about the pagination mechanism, response structure, and how to iterate through pages. Incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not clarify parameters beyond their names. The term 'cursor' is mentioned but not linked to max_id parameter. No additional meaning provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves a paginated chunk of followers using a cursor. It distinguishes itself from sibling tools by noting 'one request required', but lacks explicit differentiation from similar chunk tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v2_user_followers or get_gql_user_followers_chunk. No conditions for use or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is minimal. It does not disclose behavioral traits such as read-only nature (implied by GET but not stated), pagination limits, or error conditions. The term 'chunk' is vague without details on ordering or cursor usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short with two sentences. The first sentence repeats the HTTP method and endpoint in brackets, which could be omitted. Overall, it is concise but front-loaded with the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's use of cursor-based pagination and lack of output schema, the description is incomplete. It fails to explain how to obtain the initial cursor, how to iterate, or what information is returned. With many sibling tools, more contextual guidance is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain the 'user_id' or 'end_cursor' parameters beyond the cursor mention in the second sentence. The parameter titles in the schema provide some meaning, but the description adds no additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets 'part of user medias with cursor', clearly indicating a paginated retrieval. It differentiates from siblings by mentioning cursor-based chunk retrieval, but could be more explicit about the resource and pagination semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_gql_user_medias or get_v1_user_medias_pinned. The description does not specify prerequisites or filtering behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions relative speed, which is minimal. Does not cover auth, rate limits, or other important behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) but awkwardly structured: the speed note precedes the main action. Every sentence has a purpose, but clarity could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With multiple sibling tools and 3 parameters, the description is insufficient. It doesn't explain what 'user stories' entails, how 'amount' affects results, or how this differs from similar endpoints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only 'force' has a description). The description adds no parameter-level details beyond the schema, failing to explain 'amount' or 'username'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user stories' with a specific resource. The endpoint path is included. However, it does not explicitly differentiate from sibling tools like get_v1_user_stories or get_v2_user_stories_by_username, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a speed comparison, suggesting an alternative endpoint for faster responses. This gives some guidance on when not to use this tool, but lacks explicit when-to-use criteria or full enumeration of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the basic operation without disclosing behavioral traits such as authentication requirements, rate limits, error handling, or side effects. The agent cannot infer if this is a safe 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but it includes a bracketed HTTP method which is redundant with the tool name. While not verbose, it misses opportunities to provide more value in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single param, no output schema), the description is incomplete. It does not explain what the returned highlight object contains, any limitations, or how to interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 additional meaning beyond the schema. The parameter 'id' is not described; the agent receives no clues about its format, length, or expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('highlight object by id'). It effectively distinguishes from sibling tools like get_v1_highlight_by_url (by URL) and get_v2_user_highlights (user-specific highlights).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_v1_highlight_by_url) or when not to use it. No conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes a billing warning (2 requests per call) which is behaviorally relevant. However, it does not mention read-only nature, authentication needs, pagination behavior, or the effect of the 'force' parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the endpoint. However, it is so terse that it sacrifices important information, making it more under-specified than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, pagination implications, and billing costs, but the description only covers the billing. It does not explain the return type, how to paginate, or how to use 'end_cursor'. This is insufficient for a paginated list endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any parameters. The schema provides descriptions only for 'force', but 'user_id' and 'end_cursor' are left unexplained. With 33% schema coverage, the description should add context but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a user's following list and mentions it requires one request. However, it does not differentiate from sibling tools like get_v1_user_following_chunk or get_v2_user_following, and it does not specify that it returns a paginated chunk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus the many similar sibling tools. The description offers no context for selection or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the chunk size (15 comments per request), implying pagination. However, no annotations exist, and the description does not cover other behaviors like ordering, 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repetitive ('Get media comments' and 'Get comments on a media' are redundant). The HTTP method and path in the first sentence are unnecessary. Front-loaded but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of pagination (how to use min_id/max_id for next pages) and output structure. For a paginated API with no output schema, the description should provide more context to enable correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of parameters. While parameter names (id, min_id, max_id, can_support_threading) hint at their purpose, the description adds no semantic value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get media comments' and specifies the chunk size (15 comments per request). It identifies the resource and action, but does not differentiate from sibling tools like get_v2_media_comments or get_v2_media_comments_replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v2_media_comments. No prerequisites or context for pagination described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Get userstream (info)' with no mention of side effects, permissions, rate limits, or data structure. This is 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a bracket notation for the API path which may be unnecessary. The first sentence is a conditional suggestion that is somewhat out of place. Overall concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fails to explain what userstream contains or what to expect from the response. It lacks essential context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the schema provides no parameter descriptions. The description adds no additional meaning for the username parameter beyond what is obvious from the schema type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets userstream info by username, using a specific verb and resource. It also mentions an alternative endpoint for speed, helping differentiate from the by-id variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using the by/id endpoint when speed is crucial, providing a clear when-not-to-use condition. However, it does not cover other scenarios or compare with other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only reiterates the tool's basic function without disclosing behavioral traits such as authentication requirements, rate limits, or pagination behavior. It does not contradict any annotations, but fails to add value beyond the core purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy ('Get usertag medias' repeats the first sentence). It is not overly verbose, but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description does not clarify return values or pagination details. For a paginated media retrieval tool, this omission is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no extra meaning beyond the parameter descriptions already provided in the input schema. It meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates the tool retrieves media where a user is tagged, using the verb 'Get' and specifying the resource 'medias where user is tagged'. It distinguishes the core action from other tools but does not contrast with similar v1 or other media retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v2_user_clips or get_v2_hashtag_medias_recent. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states a GET operation returning a location object, omitting any details about error states (e.g., not found), authentication requirements, rate limits, or response format. The minimal description fails to inform the agent of important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (two lines) but includes some redundancy: the first line repeats the HTTP method and path which are already implied by the tool name. The second sentence is efficient. Minor waste prevents a top score of 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and one required parameter, the description should explain the return value structure and potential behavior. It only says 'Get location object', leaving out what fields the object contains, error handling, or response details. This inadequacy leaves the agent with insufficient information for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single 'id' parameter, so the description's mention of 'by id' adds basic context that the parameter is the location identifier. However, it does not specify the format, constraints, or source of the ID, leaving the agent to infer details from the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves a location object by its ID, clearly indicating the verb and resource. However, it does not differentiate from sibling location tools like get_v1_location_guides or get_v1_location_medias_recent, which limits clarity when selecting among multiple location endpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, exclusions, or comparisons to sibling tools, leaving the agent without 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention any behavioral traits like idempotency, authentication needs, or side effects. The tool likely performs a safe read, but this is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, fitting in a single line plus a short note. It front-loads the HTTP method and path, which is useful for context. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, yet the description does not explain what the return value (media pk) looks like. It also lacks information on error conditions or edge cases, making it incomplete for an agent to reliably use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context beyond the schema by specifying the expected URL pattern via an example (truncated). However, it does not explain the exact format or any constraints on the URL parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get Media pk from URL', specifying the action and resource. It distinguishes from siblings like 'get_v1_media_by_url' by focusing on extracting the media primary key. The note with an example URL further clarifies the input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an example URL but does not explicitly state when to use this tool versus alternatives such as 'get_v1_media_pk_from_code'. No guidance on when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It only states the HTTP method and that it gets the author, but does not disclose any behavioral aspects such as required permissions, error conditions, or what happens if media_id is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short and front-loaded with the HTTP method and path. However, it could include more useful information without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value (e.g., user object details, format). Given the complexity of sibling tools and the absence of an output schema, more context is needed for the agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, media_id, is self-explanatory from its name. The description adds no additional meaning, but given the parameter's clarity, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get author of the media', which is a specific verb and resource. It distinguishes this tool from siblings like get_v1_media_likers or get_v1_media_comments, but does not elaborate on the scope or uniqueness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no indication of when to use this tool versus other user-retrieval tools (e.g., get_v1_user_by_id) or when not to use it. Sibling tools are numerous but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior but only states the basic action. It does not mention read-only nature, error handling, authentication, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the endpoint, but it is too minimal and could include more detail without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with no output schema and minimal description, the context is lacking. Missing details on return value, authentication, and differentiation from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'id' has no description in the schema (0% coverage) and the description only says 'by id', adding no format, constraints, or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get story object by id', specifying the verb (get) and resource (story) and the identifier method (by id). This distinguishes it from siblings like get_v1_story_by_url and get_v2_story_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., v1 vs v2, by_id vs by_url). No mentions of prerequisites, exclusions, or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool downloads a file, implying a data retrieval operation, but it does not disclose whether authentication is required, how the file is returned (stream, redirect, raw bytes), or any error conditions. With no annotations, this is insufficient for a download operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an example, which is reasonably concise. However, the first sentence is repeated twice, adding unnecessary redundancy. The example is lengthy but serves as a concrete illustration. Overall, it is efficient but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should provide more context about what the tool returns (e.g., file content, download link) and any prerequisites or side effects. It does not address these, making it incomplete for a download tool with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description clarifies that the 'url' parameter should be a story file URL (not a page URL) and provides an example. However, it does not explain constraints like valid URL formats, expiration, or file size limits, leaving room for misinterpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Download story file by URL to file' and provides an example URL. The verb 'download' and resource 'story file' are specific. However, it does not differentiate from close siblings like get_v1_story_download or get_v1_story_download_by_story_url, which may have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions where to obtain the URL ('/v1/story/by/id' or '/v1/story/by/url'), but it gives no guidance on when to use this tool over its siblings (e.g., get_v1_story_download_by_story_url). It lacks exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It reveals HTTP status code behavior (200, 404 for unavailable/deleted), missing usertags for video, and a caveat for ad posts. However, it does not mention authentication requirements, rate limits, or response shape beyond 'media object.' This is moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but disorganized. It starts with a technical HTTP path, then jumps to status codes, then a video-specific exception, then an ad post note, and ends with 'Get media object.' The information is present but not logically structured; a more front-loaded and organized presentation would be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, no annotations), the description should provide a complete picture: what it does, what it returns, and key limitations. It covers some behavioral aspects but does not describe the response structure or data fields beyond 'media object,' leaving the agent without enough context to confidently use the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'id' with a title but no description. The tool description mentions 'by id' in the path and 'Get media object' but does not clarify what format or type the id expects (e.g., numeric string, media ID, etc.). With 0% schema description coverage, the description should compensate but fails to add meaningful semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns media info by ID and explicitly mentions HTTP status codes and edge cases. It differentiates itself from get_v2_media_info_by_url and get_v2_media_info_by_code by focusing on ID-based retrieval, and it distinguishes from /v2/media/by/id for ad posts. However, the purpose is slightly buried amid status code details, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one explicit alternative: for promoted/ad posts, use /v2/media/by/id instead. This helps the agent avoid that edge case. However, it does not give general guidance on when to choose this tool over the many other media-info siblings (e.g., by code, by URL, v1 versions). More comprehensive usage context would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as permissions, rate limits, return format, or whether the operation is read-only. It only restates the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, consisting of two sentences. However, the first sentence is somewhat redundant and could be integrated into the second for better flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 provides basic purpose and usage hint. It lacks detail on what 'userstream' is or what the output contains, which is acceptable but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal meaning beyond the parameter name. It mentions 'by id' but does not clarify the format or constraints of the ID parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves userstream info by ID. It distinguishes from sibling 'get_v2_userstream_by_username' by referencing the ID endpoint. The first sentence is a bit ambiguous but the second sentence clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hint about using this endpoint when speed is crucial, implying the ID-based variant is faster than the username variant. However, it does not explicitly state when to use versus other userstream tools or provide alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It implies a read-only operation and lists returned fields, but does not disclose authorization needs, rate limits, or potential side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with a clear header and a single informative sentence. No unnecessary words, though the 'User About' line adds little beyond the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool without output schema, the description covers the main purpose and data fields. However, it omits parameter documentation and return structure, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not mention the required 'id' parameter or its purpose (e.g., user ID format). The agent must infer meaning from context, which is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'About this account' panel for a user, listing specific data fields (verified status, country, creation date, former usernames). This distinguishes it from sibling tools that handle followers, media, stories, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_v1_user_about or get_gql_user_web_profile_info. With many sibling tools, explicit usage conditions would help an agent select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It describes the returned data and indicates a GET endpoint, but omits authentication needs, rate limits, or error scenarios.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using two sentences to convey the endpoint, recommendation, and returned data. No extraneous words, though structure could be slightly improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers the output fields but lacks parameter input details and behavioral context, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the single required parameter 'id', and the input schema provides no description. With 0% schema description coverage, the parameter remains entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'About this account' panel for a user, listing specific fields. It also recommends switching to a GraphQL alternative, but does not explicitly differentiate from other get_v1_user_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using a preferred alternative (/gql/user/about), implying the current tool is legacy. However, it does not specify when to use this tool (e.g., if GQL is unavailable) or provide explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It indicates a read operation with pagination (cursor), but lacks details on idempotency, safety, rate limits, or error handling. Basic 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short sentences. The [GET ...] prefix is helpful. No wasted words, but could be slightly clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 many sibling tools, the description omits key details like response format, pagination behavior, and how this tool differs from similar ones. Incomplete for effective selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. It mentions 'cursor' but does not explicitly map to the 'max_id' parameter. The user_id is implied. Partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a page of a user's following list using a cursor. However, it does not differentiate from sibling tools like get_gql_user_following_chunk or get_v2_user_following, and the phrase 'one request required' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives such as get_gql_user_following_chunk or other following tools. No explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It notes that paging is unavailable, which is a behavioral trait. But it does not disclose authentication needs, rate limits, error behavior (e.g., invalid media_id), or whether it returns partial data. For a read operation, more transparency would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two lines with no extraneous text. Every sentence adds value: the endpoint path, the purpose, and the important paging limitation. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no output schema and many siblings, the description lacks completeness. It fails to describe the return format (e.g., what fields the likers response includes), does not differentiate from similar endpoints, and omits any context about required permissions or typical use cases. For a simple one-parameter tool, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (media_id) with 0% description coverage. The description does not explain what media_id is (e.g., numeric ID, URL parameter), its format, or how to obtain it. With no schema documentation in the description, the agent has insufficient context to correctly supply the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get likers on a media') and the resource ('media'). The title includes the HTTP method and endpoint path. However, it does not explicitly differentiate from sibling tools like get_v1_media_likers or get_v2_media_likers, relying on the naming convention 'gql' to imply a GraphQL version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a key constraint ('paging is unavailable'), which is helpful for usage. However, it provides no guidance on when to use this tool versus alternative likers endpoints (v1, v2) or whether it requires authentication. The context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description offers no behavioral disclosure beyond the basic read operation. It does not mention return format, pagination, or any side effects. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the route and purpose. However, the HTTP method and route in the first line are redundant for an agent that already knows the tool name. Still efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and no output schema, the description is somewhat complete for a straightforward retrieval. However, it lacks explanation of what a 'hashtag object' contains, and does not differentiate from similar v2 tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a detailed description of the 'name' parameter. The description adds no extra meaning, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get hashtag object by name', which is a specific verb-resource combination. It distinguishes from sibling tools like hashtag media retrieval or search because it explicitly says 'hashtag object'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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_v2_hashtag_by_name or get_v1_search_hashtags. The description lacks 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'Download' but does not disclose response format (binary, URL?), error handling, auth requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two lines with no redundant words. The key action and input are front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what 'download' returns (e.g., file stream, URL). It is incomplete for an agent to understand response handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds context that 'id' is a story id. However, it does not specify format, length, or example values, leaving the agent partially informed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb (Download), resource (story media), and input (by story id). It distinguishes from sibling tools like get_v1_story_by_id and the URL-based download variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_v1_story_download_by_url). The description only states what it does, not context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that responses include trial publications and that they lack a 'reshare_count' field, which is useful. However, it does not mention whether the operation is read-only or any potential side effects, and annotations are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and front-loaded with the endpoint and core action. It includes a link for context, but some information could be more structured and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and low schema coverage, the description partially compensates by noting trial publications and filtering. However, it does not explain pagination mechanics, error conditions, or return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should compensate heavily. It explains that 'end_cursor' is for cursor-based pagination, but does not describe 'user_id' beyond implying it identifies the user. The name hints at the resource, but format details are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a chunk of user clips using a cursor, with a specific verb and resource. However, it does not explicitly differentiate from sibling clip tools like get_v2_user_clips.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other user data retrieval tools. Without this, an agent may choose incorrectly among many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It mentions pagination via cursor and that only one page is fetched, but does not disclose authorization needs, rate limits, or the response structure. The phrase 'one request required' 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy (e.g., two lines essentially repeating the same information) and awkward formatting with brackets. It could be more streamlined without loss of meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and no annotations, the description is incomplete. It does not explain return values, error handling, or how to use the cursor for pagination beyond the schema. The context of sibling tools is not addressed beyond one alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions already explaining user_id and page_id. The description adds minimal additional semantics (e.g., 'cursor' is mentioned but not elaborated), so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a user's followers, specifying the HTTP method, endpoint, and that it returns one page. It distinguishes from sibling get_g2_user_followers by explicitly recommending that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises to prefer /g2/user/followers, offering some guidance. However, it does not explain when to use this tool over other followers-related siblings like get_gql_user_followers_chunk, nor does it clarify the meaning of 'one request required'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The deprecation warning adds behavioral context beyond the schema, but with no annotations, the description should disclose more about authentication or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the deprecation warning and basic purpose, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and deprecation context, the description is incomplete; it omits how to use the query and what the response contains, which is needed for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and only one required parameter ('query'), the description provides no explanation of its meaning or format, leaving the agent to infer from the name alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool searches for users and provides a deprecation warning, but lacks specifics on how the search works or what it returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using a v2 alternative due to deprecation, which guides the agent away from this tool. No other usage guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description shows an example output and URL format constraints, but it does not address authentication, error cases, or read-only behavior. The example is helpful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but suffers from truncation and informal language. It conveys the key points but is not well-structured, reducing readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 provides an example output and clarifies the scope. It lacks explanation of error handling, data interpretation, and edge cases, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides an example URL and mentions that the link must contain '/s/', adding value beyond the schema's basic string type. However, it does not formally describe the parameter format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it works for stories and highlights only and provides an example output, distinguishing it from siblings like get_v1_media_by_url. However, the formatting is messy with truncation, and the purpose could be stated more cleanly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for stories/highlights and suggests alternative endpoints, but it does not fully explain when to use this over other similar share tools or provide comprehensive exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It only mentions the scope (reels only) but lacks details on side effects, auth requirements, rate limits, or return behavior, making it insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence that directly states the purpose and scope. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and only one parameter, the description is too brief. It does not explain what is returned, the response format, or any constraints, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'url' with 0% schema description coverage. The description does not clarify the expected format or content of the URL (e.g., full URL vs. partial), adding no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it works for reel (clips) only, using a specific verb 'get' and resource 'share reel by URL', distinguishing it from sibling tools like get_v1_share_by_url which likely handle other share types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the scope ('Works for reel (clips) only'), implicitly guiding when to use it. However, it does not explicitly exclude other types or mention alternative tools for non-reel shares.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only notes 'one request required' (trivial) and omits behavioral traits like read-only nature, auth needs, rate limits, or error handling. The GET method implies safety but is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Short but contains duplicate sentences ('Get user object by username'). The HTTP method and path in brackets are useful, but redundancy reduces efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple lookup tool, but missing details on response structure, error responses, or pagination (if any). For a single-parameter read operation, it's minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description must compensate. It only mentions 'by username' without clarifying format, case sensitivity, or constraints, adding minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get user object by username', which is specific and aligns with the tool name. It distinguishes from the by/id sibling by mentioning efficiency, though the duplicate sentence slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using the by/id endpoint for speed, providing a clear alternative and when-not-to-use scenario, which is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses key behaviors: returns 200/404, doesn't return usertags for video, and ad posts may incorrectly return 404. This covers safety and edge-case knowledge beyond the bare minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, but the first and last sentences are repetitive ('Get media object' and the 200/404 info). Could be trimmed to two clear sentences without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covers key behavioral aspects but omits the return object structure. The single parameter is trivial but still undefined. Overall adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'code' has no description beyond the schema title. While the tool name implies it's a media code, the description does not confirm its format or semantics. Schema coverage is 0%, so description should compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns media info by code, specifying HTTP response codes (200/404) and noting an alternative for ad posts. However, the structure is slightly redundant with both a technical note and a summary line.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when not to use (for ad posts, use /v2/media/by/code) and mentions 404 behavior for deleted posts. Does not differentiate from sibling get_v1_media_by_code or get_v2_media_info_by_id, but the note about ads is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It implies a read-only operation (GET) and mentions an optional parameter for detail, but does not specify side effects, authentication needs, rate limits, or error behavior. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using only three short sentences. It front-loads the endpoint and purpose, then gives a key usage hint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values or structure. It says 'more detailed response' but nothing concrete. It also lacks context on when to use this tool over many siblings, leaving agents underinformed for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It describes 'expand_suggestion' as providing a more detailed response, adding meaning. However, it refers to 'target_id' instead of the actual parameter name 'user_id', causing slight ambiguity. It does not define the format or constraints of 'user_id'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Fetch Suggestion Details' and 'Fetch suggested users details by target_id', using a precise verb and resource. The tool name and title uniquely identify it among many sibling tools as specific to suggested profiles, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It mentions the 'expand_suggestion' parameter for more detailed response, but does not explain when to choose this over other user-related tools or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral details: returns interleaved accounts and media, discrimination by __typename, and effect of flat parameter. It does not cover authentication or rate limits, but the key behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: overview, response discrimination, and parameter detail. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and low parameter coverage, the description adequately explains the response structure and the flat parameter. However, it does not cover pagination behavior (end_cursor) or any limits, which are important for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), but the description adds meaning: it clarifies that query is the keyword, explains the flat parameter's effect, and describes the overall response structure. However, end_cursor is not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: search top content by keyword. It explains the return format (interleaved accounts and media). However, it does not explicitly differentiate from sibling search tools, though the name and context imply it is a GraphQL-based top search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other search tools in the sibling list. No mention of prerequisites, alternatives, or when-not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 'one request required' and compares speed, but does not disclose authentication, error handling, or response structure. Adequate for a simple GET 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, but the last sentence is a redundant restatement of the first. Could be more concise by omitting the repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET tool with one parameter and no output schema, the description provides the essential purpose and a speed hint. However, it lacks details on response format, error behavior, and rate limits, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema has no description for the 'username' parameter. The tool description adds no additional meaning beyond the schema's type and title, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a user object by username, and distinguishes from the by/id endpoint for speed, which helps the agent choose correctly among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific alternative for speed-critical use, guiding when to prefer the by/id endpoint over this one. Does not explicitly state when not to use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 includes a decoded example showing the output format (pk and type), which gives insight into the result. However, it does not explicitly state that the operation is read-only or idempotent, though the GET method and context imply safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, consisting of two sentences and an example. It is efficient, though the HTTP path notation is somewhat extraneous. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides an example output. It explains the parameter with a concrete example, specifies scope (stories/highlights only), and suggests alternatives. For a simple lookup tool, this is sufficiently complete. Missing are potential error scenarios or more detailed output structure, but the example covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no description for the 'code' parameter (0% coverage). The description adds meaning by explaining that the code is a base64-like string and showing an example of its decoded form ('aGlnaGxpZ2h0OjE4MTQ2MjE2Njk4MDIyMTc0' -> pk and type). This helps the agent understand parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a share object by code, specifies it works only for stories and highlights, and distinguishes from siblings by referencing alternatives like get_v1_media_by_url. However, the inclusion of the HTTP path in brackets adds noise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the tool should only be used for stories and highlights and provides alternative tools for media and story by URL, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: returns 200/404 for specific cases, lacks usertags for video, and promoted posts may 404. Without annotations, this is valuable, though auth constraints or rate limits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is somewhat verbose with repeated notes and a redundant final line. While structured with line breaks, it could be trimmed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool, the description covers purpose, usage, behavior, and parameter format. The lack of output structure is a minor gap given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description provides a concrete URL example ('https://ins...ram.com/p/CA2aJYrg6cZ/'), clarifying expected format. This compensates well for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves media info by URL. It specifies the resource ('media object') and distinguishes from siblings by noting alternatives for promoted posts and other ID-based tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions when to use (for standard posts) and when not to (for promoted/ad posts, use /v2/media/by/url). Provides URL format guidance, aiding correct tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![hikerapi-mcp MCP server](https://glama.ai/mcp/servers/subzeroid/hikerapi-mcp/badges/card.svg)](https://glama.ai/mcp/servers/subzeroid/hikerapi-mcp)

Score Badge

Copy to your README.md:

[![hikerapi-mcp MCP server](https://glama.ai/mcp/servers/subzeroid/hikerapi-mcp/badges/score.svg)](https://glama.ai/mcp/servers/subzeroid/hikerapi-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/subzeroid/hikerapi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server