mcp-metricool

Official

by metricool

Overview Schema Related Servers Score Discussions(1)

Python

Remote

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools are clearly distinct by social network and content type (e.g., get_facebook_posts vs. get_instagram_reels), but there is some overlap between get_brands and get_brands_complete, and between get_analytics and various network-specific tools for retrieving data. The descriptions help clarify when to use each, but an agent might occasionally be uncertain between the two brand tools or between general analytics and specific post retrieval.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, with all tools using 'get_' or 'post_' or 'update_' prefixes followed by a descriptive noun phrase (e.g., get_facebook_posts, post_schedule_post, update_schedule_post). There are no deviations in naming conventions, making the set predictable and easy to understand.
Tool Count3/5
With 28 tools, the count feels heavy for a social media management server, bordering on excessive. While the domain involves many networks and content types, the number could be streamlined (e.g., by combining similar tools across networks). It's not extreme, but it's on the higher end of what's manageable for an agent.
Completeness5/5
The tool set provides comprehensive coverage for social media management: retrieving brands, analytics, metrics, best times to post, competitors, and posts from various networks (including ads campaigns), plus scheduling and updating posts. There are no obvious gaps; it supports full CRUD-like operations for scheduling and rich data retrieval across the domain.
Average 3.3/5 across 28 of 28 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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

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 offers minimal behavioral insight. It implies a read operation ('Get') but doesn't cover authentication needs, rate limits, pagination, error handling, or what 'list' entails (e.g., format, completeness). This leaves significant gaps for a tool with parameters.
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 appropriately sized and front-loaded with the core purpose, followed by parameter details. Each sentence adds value without redundancy, though the parameter explanations could be slightly more integrated into the flow.
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, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers parameter basics but lacks behavioral context, output details, and usage guidelines, making it inadequate for reliable tool 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 description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter's purpose and date formats, covering all 3 parameters. However, it doesn't detail constraints like valid date ranges or blog_id sourcing, leaving some semantic gaps.
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 ('list of Bluesky Posts from your Metricool brand account'), making the purpose evident. It distinguishes from siblings by specifying Bluesky posts, but doesn't explicitly contrast with similar tools like get_x_posts or get_instagram_posts beyond the platform name.
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 is provided. The description doesn't mention prerequisites, appropriate contexts, or comparisons with sibling tools like get_x_posts or get_analytics, leaving the agent without usage direction.
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 of behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify aspects like authentication requirements, rate limits, pagination, error handling, or the format/structure of the returned list. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded, with the core purpose stated first followed by parameter details. The sentences are efficient and avoid redundancy. It could be slightly more structured by separating usage notes, but overall, it's concise and well-organized.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It covers basic parameter semantics but lacks behavioral details (e.g., authentication, response format), usage guidelines, and output information. For a tool that fetches data with multiple inputs, this leaves too many contextual gaps for effective agent 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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining that 'init_date' and 'end_date' define a period for data retrieval and specifying their format (YYYY-MM-DD), and it clarifies that 'blog_id' refers to a Metricool brand account. However, it doesn't detail what a 'blog_id' is, how to obtain it, or any constraints on date ranges, leaving some parameter semantics 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's purpose: 'Get the list of Facebook Stories from your Metricool brand account.' It specifies the verb ('Get'), resource ('Facebook Stories'), and scope ('from your Metricool brand account'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_facebook_posts' or 'get_instagram_stories', which is why it doesn't earn a 5.
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 doesn't mention sibling tools like 'get_facebook_posts' or 'get_instagram_stories' for comparison, nor does it specify prerequisites or exclusions. The only implied context is the need for a Metricool brand account, but this is insufficient for effective 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 carries the full burden. It mentions 'retrieve' which implies a read operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'available metrics' entails (e.g., format, scope). This is a significant gap for a tool with no annotation coverage.
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 appropriately sized with two sentences, front-loaded with the main purpose. However, the 'Args:' section is redundant since the schema already documents the parameter, making it slightly less efficient than it could be.
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 (1 parameter, no annotations, no output schema), the description is incomplete. It lacks details on what 'available metrics' returns, how to interpret results, or any behavioral context, making it inadequate for an agent to use the tool effectively without additional information.
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 minimal meaning beyond the input schema: it specifies that the 'network' parameter is for a 'specific network to get the available metrics'. With 0% schema description coverage and 1 parameter, this provides some context but doesn't fully compensate for the lack of schema details (e.g., network format, examples). Baseline is 3 as the description adds marginal 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 clearly states the verb 'retrieve' and the resource 'available metrics for a specific network', making the purpose understandable. However, it doesn't distinguish this tool from sibling tools like 'get_analytics' or 'get_network_competitors', which might retrieve related but different data, so it misses full 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?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that seem related (e.g., 'get_analytics', 'get_network_competitors'), there's no indication of context, prerequisites, or exclusions, leaving the agent to guess based on tool names 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 are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), but doesn't describe important behaviors: whether it requires authentication, rate limits, pagination, error handling, or what the returned data structure looks like. For a data retrieval tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately sized and front-loaded with the core purpose first, followed by parameter details. The two-sentence structure is efficient with minimal waste. However, the parameter documentation could be slightly more concise by combining the date format explanation into one statement rather than repeating it for both date parameters.
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 with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers basic parameter formats but misses crucial context: authentication requirements, return format, error conditions, rate limits, and what constitutes a valid 'blog id.' For a data retrieval tool in a social media analytics context, users need to understand what data structure to expect and any access constraints.
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 schema provides no parameter documentation. The description compensates by documenting all 3 parameters with names and format requirements (YYYY-MM-DD for dates, integer for blog_id). However, it doesn't explain what a 'blog id' represents in the Metricool context, valid date ranges, or whether dates are inclusive/exclusive. The description adds meaningful value but doesn't fully compensate for the complete lack of schema documentation.
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's purpose: 'Get the list of Threads Posts from your Metricool brand account.' It specifies the verb ('Get') and resource ('Threads Posts'), and distinguishes it from siblings by focusing on Threads platform posts rather than other social media platforms. However, it doesn't explicitly differentiate from similar list-retrieval tools like get_x_posts or get_instagram_posts beyond the platform name.
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 doesn't mention prerequisites (e.g., needing a Metricool account), compare it to similar tools like get_x_posts or get_instagram_posts, or indicate when this tool is preferred over others. The only implicit context is the platform-specific focus on Threads.
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 for behavioral disclosure. It mentions the tool retrieves data (implied read-only), but doesn't cover authentication needs, rate limits, pagination, error handling, or what the returned list includes (e.g., campaign details). This leaves significant gaps for a tool with 3 parameters and no output schema.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly. The 'Args' section is structured but could be more integrated; overall, it avoids unnecessary fluff and each part adds value.
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 with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers parameter basics but lacks behavioral context (e.g., data format, errors), usage guidelines, and output details, making it inadequate for reliable tool invocation.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context for all 3 parameters: 'init date' and 'end date' define a period with format YYYYMMDD, and 'blog id' specifies the Metricool brand account. This clarifies purpose beyond schema types, though it doesn't explain parameter interactions 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 'Get the list of Facebook Ads Campaigns from your Metricool account,' which specifies the action (get/list), resource (Facebook Ads Campaigns), and source (Metricool account). It distinguishes from siblings like 'get_googleads_campaigns' by specifying the platform, but doesn't explicitly differentiate from other Facebook-related tools (e.g., 'get_facebook_posts').
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. It doesn't mention prerequisites (e.g., needing a Metricool account), exclusions, or comparisons to siblings like 'get_googleads_campaigns' or 'get_tiktokads_campaigns'. The description only states what it does, not when it's 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, so the description carries the full burden of behavioral disclosure. It states the tool retrieves a list of posts but doesn't describe the return format (e.g., JSON structure, pagination), rate limits, authentication requirements, or error handling. For a read operation with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured 'Args:' section with parameter details. There's no wasted text, though the formatting (e.g., 'init date' vs. 'Init date') could be slightly more consistent. Every sentence adds value.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It covers parameter semantics but lacks behavioral details (e.g., output format, error cases) and usage guidelines. For a tool that retrieves data over a date range, more context on what 'list' includes (e.g., post metadata, limits) would be helpful.
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 description adds meaningful semantics for all three parameters beyond the schema (which has 0% description coverage). It explains that 'init date' and 'end date' define a period for data retrieval with format 'YYYY-MM-DD', and 'blog id' identifies the Metricool brand account. This compensates well for the schema's lack of descriptions, though it doesn't specify parameter constraints (e.g., date ranges, valid blog IDs).
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's purpose: 'Get the list of Facebook Posts from your Metricool brand account.' It specifies the verb ('Get'), resource ('Facebook Posts'), and scope ('from your Metricool brand account'), which distinguishes it from generic Facebook tools. However, it doesn't explicitly differentiate from sibling tools like get_facebook_reels or get_facebook_stories, which target different Facebook content 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like get_facebook_reels (for Facebook Reels) or get_facebook_stories (for Facebook Stories), nor does it specify prerequisites (e.g., authentication, brand account setup). The only implied context is needing a Metricool brand account, but this is minimal guidance.
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 states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like authentication needs, rate limits, pagination, error handling, or what happens if dates are invalid. This leaves significant gaps for a tool with 3 parameters and no output schema.
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 appropriately sized and front-loaded with the main purpose in the first sentence. The 'Args' section efficiently lists parameters with brief explanations. No wasted sentences, though it could be slightly more structured (e.g., bullet points).
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, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It explains parameters but lacks behavioral context (e.g., data format, error cases) and doesn't describe return values, which is critical for a data-fetching tool with no output schema provided.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining all 3 parameters: 'init date' and 'end date' define the period with format YYYYMMDD, and 'blog id' specifies the Metricool brand account. This clarifies purpose beyond the bare schema, though it doesn't detail constraints like valid date ranges.
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 ('list of Google Ads Campaigns from your Metricool account'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_facebookads_campaigns' or 'get_tiktokads_campaigns', which would require mentioning it's specifically for Google Ads campaigns.
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 doesn't mention sibling tools like 'get_facebookads_campaigns' for Facebook Ads or 'get_tiktokads_campaigns' for TikTok Ads, nor does it specify prerequisites or context for selecting this tool over others.
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 of behavioral disclosure. It mentions the tool retrieves data ('Get the list'), implying a read-only operation, but doesn't specify authentication requirements, rate limits, pagination, error handling, or what the returned data structure looks like. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args:' section for parameters. There's no unnecessary fluff, and each sentence serves a clear purpose. It could be slightly more concise by integrating the parameter details into the main description, but overall it's 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's complexity (3 parameters, no annotations, no output schema), the description is incomplete. It covers the basic purpose and parameters but lacks critical context: no information on authentication, rate limits, pagination, error handling, or the structure of returned data. For a data retrieval tool in a suite with many siblings, this leaves the agent with insufficient guidance to use it effectively.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: 'init date' and 'end date' define the period with format 'YYYY-MM-DD', and 'blog id' identifies the Metricool brand account. This adds meaningful context beyond the schema's basic titles and types, though it doesn't explain where to find the 'blog id' or validate date ranges.
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's purpose: 'Get the list of Instagram Posts from your Metricool account.' This specifies the verb ('Get'), resource ('Instagram Posts'), and source ('Metricool account'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_instagram_reels' or 'get_instagram_stories' beyond mentioning 'Posts' in the name.
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 doesn't mention sibling tools like 'get_instagram_reels' or 'get_instagram_stories' for different content types, or 'get_analytics' for performance data. The only context is the implied date range filtering, but no explicit usage scenarios or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions retrieving data but fails to describe key traits: whether this is a read-only operation, if it requires authentication, rate limits, pagination, error handling, or the format of returned data. For a data-fetching tool with zero annotation coverage, this is a significant gap.
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 appropriately sized and front-loaded, with the main purpose stated first followed by parameter details. It avoids unnecessary fluff, but the parameter explanations could be slightly more integrated into the flow rather than listed as 'Args:'.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It covers parameter semantics but lacks behavioral context (e.g., authentication needs, data format, error cases) and output details, which are critical for a data retrieval tool. This leaves significant gaps for the agent.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining each parameter's purpose and format (e.g., 'Init date of the period to get the data' with format 'YYYY-MM-DD'), which clarifies beyond the schema's basic types. However, it does not cover all potential nuances, such as date validation or blog ID sourcing, preventing a perfect score.
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's purpose: 'Get the list of Instagram Reels from your Metricool account.' It specifies the verb ('Get'), resource ('Instagram Reels'), and source ('Metricool account'), which is clear and actionable. However, it does not explicitly differentiate from sibling tools like 'get_instagram_posts' or 'get_instagram_stories', which would require a 5.
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 lacks context about prerequisites (e.g., authentication), exclusions, or comparisons to sibling tools such as 'get_instagram_posts' or 'get_facebook_reels'. This absence leaves the agent without usage direction.
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 states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits such as authentication requirements, rate limits, pagination, error handling, or what the returned list includes (e.g., story metadata). For a tool with no annotations, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a bullet-point list for parameters. Each sentence earns its place by adding value, with no redundant information. However, the structure could be slightly improved by integrating parameter details more seamlessly.
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 (a data retrieval tool with 3 parameters), no annotations, and no output schema, the description is incomplete. It covers parameters but lacks context on authentication, rate limits, return format (e.g., list structure, fields), and error cases. For a tool with no structured support, more behavioral and output details are needed.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining all three parameters: 'init date' and 'end date' define the period with format YYYY-MM-DD, and 'blog id' specifies the Metricool brand account. This provides clear semantics beyond the schema's basic types, though it doesn't detail constraints like valid date ranges or how to obtain the blog_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 clearly states the tool's purpose: 'Get the list of Instagram Stories from your Metricool account.' It specifies the verb ('Get') and resource ('Instagram Stories'), and distinguishes it from siblings like get_instagram_posts or get_facebook_stories by focusing on Instagram Stories. However, it doesn't explicitly differentiate from all siblings (e.g., it's similar to get_facebook_stories but for a different platform).
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 doesn't mention prerequisites (e.g., needing a Metricool account), exclusions, or compare it to similar tools like get_instagram_posts or get_facebook_stories. The usage is implied by the tool name and description but not explicitly stated.
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 states this is a 'Get' operation, implying read-only behavior, but doesn't disclose any behavioral traits such as authentication needs, rate limits, pagination, error handling, or what the returned list includes. For a tool with zero annotation coverage, this is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args:' section. There's no wasted text, and it efficiently conveys necessary information in a readable format, though minor improvements in flow could elevate it.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It covers parameter semantics but lacks behavioral context, usage guidelines, and details on return values. For a data retrieval tool with multiple parameters, this leaves significant gaps for an AI agent to operate effectively.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: 'init date' and 'end date' define the period with format YYYY-MM-DD, and 'blog id' specifies the Metricool brand account. This clarifies semantics beyond the schema's basic types, though it doesn't cover all potential nuances like valid ranges or examples.
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's purpose: 'Get the list of Tiktok Videos from your Metricool account.' This specifies the verb ('Get'), resource ('Tiktok Videos'), and source ('Metricool account'). However, it doesn't differentiate from sibling tools like 'get_tiktokads_campaigns' or 'get_youtube_videos' beyond the resource name, which is why it doesn't reach 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 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 doesn't mention sibling tools, prerequisites, or specific contexts for use. The only implied usage is for retrieving TikTok videos within a date range, but this is basic and lacks explicit when/when-not instructions.
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 for behavioral disclosure. It states it retrieves a list but doesn't mention whether this requires authentication, has rate limits, returns paginated results, or what format the output takes. This leaves significant gaps for an agent to understand how to use it effectively.
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 a single, clear sentence with no wasted words. It's front-loaded with the core purpose and efficiently communicates the essential information without unnecessary elaboration.
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 annotations, no output schema, and a simple purpose, the description is too minimal. It doesn't explain what 'brands' are in this context, what the returned list contains, or any behavioral aspects like authentication needs. Given the lack of structured data, more context would help the agent.
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 tool has zero parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter information, and it appropriately doesn't mention any parameters, earning a high baseline score.
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 resource ('list of brands from your Metricool account'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tool 'get_brands_complete', which appears to serve a similar function, 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 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_brands_complete' or other data retrieval tools in the sibling list. It lacks context about prerequisites, timing, or comparison with similar 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 provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a list, implying a read-only operation, but lacks details on permissions, rate limits, pagination, error handling, or response format. For a tool with three required parameters and no annotation coverage, this is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured Args section. There's no wasted text, though the formatting as a code block might be slightly verbose. Every sentence earns its place by adding value.
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 tool's moderate complexity (3 required parameters, no output schema, no annotations), the description is partially complete. It covers parameter semantics well but lacks behavioral details like response format, error cases, or usage context. Without annotations or output schema, the agent has incomplete information for reliable invocation.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context for all three parameters: it explains that init_date and end_date define a period for data retrieval with specific format (YYYY-MM-DD), and blog_id refers to a Metricool brand account. This goes beyond the schema's basic titles and types, providing essential usage semantics.
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 the list of') and resource ('Facebook Reels from your Metricool account'), which distinguishes it from siblings like get_facebook_posts or get_instagram_reels. However, it doesn't explicitly differentiate from other list-fetching tools like get_analytics or get_metrics beyond the resource name.
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 doesn't mention prerequisites (e.g., needing a Metricool account with Facebook integration), exclusions, or comparisons to similar tools like get_facebook_posts or get_instagram_reels, 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 are provided, so the description carries the full burden of behavioral disclosure. It describes a read operation ('Get') but doesn't mention permissions, rate limits, pagination, error handling, or what the returned list includes (e.g., post details, metadata). For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, followed by a structured 'Args:' section. Each sentence earns its place by defining parameters, though it could be more concise by integrating the format details into the parameter descriptions.
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 tool's moderate complexity (3 parameters, no annotations, no output schema), the description is partially complete. It covers the purpose and parameters adequately but lacks behavioral details (e.g., response format, error cases) and usage context. Without an output schema, it should ideally hint at what the returned list contains, which is missing.
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 description adds meaningful semantics for all three parameters: 'init date' and 'end date' define the period for data retrieval with format 'YYYY-MM-DD', and 'blog id' specifies the Metricool brand account. With 0% schema description coverage, this compensates well by explaining what each parameter represents, though it doesn't detail constraints like valid date ranges or blog ID sources.
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's purpose: 'Get the list of Linkedin Posts from your Metricool brand account.' It specifies the verb ('Get'), resource ('Linkedin Posts'), and scope ('from your Metricool brand account'). However, it doesn't explicitly differentiate from sibling tools like 'get_x_posts' or 'get_facebook_posts' beyond mentioning LinkedIn specifically.
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 doesn't mention sibling tools like 'get_x_posts' for other platforms, nor does it specify prerequisites (e.g., authentication needs) or use cases beyond the basic date range and blog ID parameters. The agent must 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 are provided, so the description carries full burden. It mentions the tool 'gets' data (implying read-only) and prompts for missing blog_id, but doesn't disclose behavioral traits like authentication needs, rate limits, pagination, error handling, or what the returned list includes (e.g., board names, IDs, metadata). For a read operation with zero annotation coverage, this is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences: one states the purpose, and another provides usage guidance for missing parameters. It's front-loaded with the main action. There's no wasted text, but it could be slightly more structured (e.g., bullet points for clarity), keeping it efficient but not perfect.
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 complexity (read operation with 1 required parameter), no annotations, no output schema, and 0% schema coverage, the description is incomplete. It lacks details on return values (what boards look like), error cases, authentication, or how to handle multiple brands. For a tool in a set with many siblings, more context is needed to ensure proper agent usage.
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 compensate. It adds meaning by explaining 'blog_id' as 'Blog id of the Metricool brand account', which clarifies its purpose beyond the schema's generic 'Blog Id' title. However, with 1 parameter, this is minimal compensation; baseline would be 4 for 0 params, but here it only partially addresses the coverage gap without detailing 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 the verb 'Get' and the resource 'list of Pinterest boards', specifying it's for a 'specific Metricool brand (blog_id)'. This distinguishes it from sibling tools like 'get_pinterest_pins' which retrieves pins rather than boards. However, it doesn't explicitly contrast with other board-related tools (none exist in siblings), so it's not a perfect 5.
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 implies usage when needing Pinterest boards for a Metricool brand, and it mentions asking for blog_id if not provided, which gives some procedural guidance. However, it lacks explicit when-to-use vs. alternatives (e.g., compared to 'get_brands' or other platform-specific tools), and no exclusions or prerequisites are stated beyond the blog_id requirement.
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 states it 'gets' data, implying a read-only operation, but doesn't disclose behavioral traits like rate limits, pagination, error handling, or authentication requirements. For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.
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 appropriately sized and front-loaded with the core purpose in the first sentence. The parameter explanations are clear and direct, with no wasted words. However, the formatting with 'Args:' and bullet-like lines is slightly informal but still effective.
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 3 parameters, no annotations, and no output schema, the description is minimally adequate. It covers the purpose and parameters but lacks behavioral context, usage guidelines, and output details. For a data retrieval tool, this leaves the agent with incomplete information about what to expect in return or operational constraints.
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?
With 0% schema description coverage, the description compensates well by explaining all three parameters: init_date (format YYYY-MM-DD), end_date (format YYYY-MM-DD), and blog_id (blog id of the Metricool brand account). This adds crucial meaning beyond the bare schema, though it doesn't detail constraints like date ranges or blog_id sourcing.
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 the list of') and resource ('Pinterest Pins from your Metricool brand account'), which is specific and unambiguous. It distinguishes from siblings like get_pinterest_boards by focusing on pins rather than boards. However, it doesn't explicitly contrast with other data-fetching tools like get_analytics or get_metrics, which slightly limits 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), exclusions, or comparisons to siblings like get_pinterest_boards or other social media data tools. The agent must infer usage solely from the tool name and parameters.
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 of behavioral disclosure. It states the tool retrieves data ('Get the list'), implying a read-only operation, but doesn't mention authentication requirements, rate limits, pagination, error handling, or what the returned list contains. For a data-fetching tool with zero annotation coverage, this leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args:' section detailing parameters. There's no wasted text, and the structure aids readability. A perfect score is reserved for exceptional brevity or formatting, but this is efficient.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers the purpose and parameter semantics adequately, but lacks usage guidelines, behavioral details (e.g., authentication, output format), and doesn't leverage sibling context. It meets a minimum viable standard but has clear gaps.
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 description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains that 'init date' and 'end date' define a period for data retrieval with format 'YYYY-MM-DD', and 'blog id' identifies the Metricool brand account. This clarifies parameter purposes and formats, compensating well for the schema's lack of 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's purpose: 'Get the list of Tiktok Ads Campaigns from your Metricool brand account.' It specifies the verb ('Get'), resource ('Tiktok Ads Campaigns'), and source ('Metricool brand account'). However, it doesn't explicitly differentiate from sibling tools like 'get_facebookads_campaigns' or 'get_googleads_campaigns' beyond the platform name, which prevents 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 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 doesn't mention sibling tools like 'get_facebookads_campaigns' or 'get_googleads_campaigns' for comparison, nor does it specify prerequisites or exclusions. The only implied context is needing a Metricool brand account, but this is minimal guidance.
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 of behavioral disclosure. It mentions retrieving data from 'your Metricool account,' implying a read-only operation, but doesn't clarify authentication needs, rate limits, pagination, error conditions, or what the returned list includes (e.g., video metadata, performance metrics). For a data-fetching tool with zero annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded: the first sentence states the purpose, followed by a structured 'Args:' section with parameter details. There's no redundant information. It could be slightly more concise by integrating the parameter explanations into a single paragraph, but overall, it's efficient and well-organized.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is minimally adequate. It covers the purpose and parameters but lacks behavioral details (e.g., response format, error handling) and usage context. Without annotations or an output schema, the agent must infer these aspects, making the description incomplete for reliable tool invocation.
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?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all three parameters: 'init date' and 'end date' define the period with format YYYYMMDD, and 'blog id' specifies the Metricool brand account. This adds meaningful context beyond the schema's basic types (string/integer). However, it doesn't explain where to find the 'blog id' or validate date ranges, leaving minor gaps.
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's purpose: 'Get the list of Twitch Videos from your Metricool account.' It specifies the verb ('Get') and resource ('Twitch Videos'), and distinguishes it from siblings by focusing on Twitch videos rather than other platforms like Facebook or Instagram. However, it doesn't explicitly differentiate from similar tools like 'get_tiktok_videos' or 'get_youtube_videos' beyond the platform name.
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 doesn't mention prerequisites (e.g., needing a Metricool account with Twitch integration), compare it to sibling tools (e.g., 'get_tiktok_videos' for TikTok content), or specify use cases (e.g., for analytics vs. scheduling). The only implicit context is the date range requirement, but this is parameter-specific rather than usage guidance.
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 for behavioral disclosure. It states the tool retrieves data ('Get'), implying a read-only operation, but doesn't clarify permissions, rate limits, pagination, or response format. For a data-fetching tool with zero annotation coverage, this lack of behavioral details is a significant gap.
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 appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args:' section for parameters. Every sentence adds value without redundancy. Minor improvements could include briefer formatting, but overall it's efficient and well-organized.
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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete. It covers purpose and parameter semantics well, but lacks behavioral details (e.g., response format, error handling) and usage guidelines. This makes it adequate for basic use but insufficient for robust agent decision-making.
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?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining all three parameters: 'init date' and 'end date' define a period with format 'YYYYMMDD', and 'blog id' specifies the 'Metricool brand account'. This goes beyond the schema's basic titles and types, providing crucial context for correct 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 clearly states the tool's purpose: 'Get the list of X (Twitter) Posts from your Metricool account.' It specifies the verb ('Get'), resource ('X (Twitter) Posts'), and source ('Metricool account'), which is clear and specific. However, it doesn't explicitly differentiate from sibling tools like 'get_analytics' or 'get_metrics' that might also retrieve data from Metricool, 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 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 doesn't mention sibling tools like 'get_analytics' or 'get_metrics' for comparison, nor does it specify prerequisites (e.g., authentication needs) or contextual triggers. The absence of usage context leaves the agent without clear selection 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 provided, the description carries the full burden of behavioral disclosure. It mentions fetching data but lacks details on permissions required, rate limits, pagination, error handling, or the format of returned data (e.g., list structure, fields included). This leaves significant gaps for an agent to understand how the tool behaves beyond basic input.
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 appropriately sized and front-loaded, starting with the main purpose followed by parameter details in a clear 'Args:' section. There is no redundant or verbose language, making it efficient, though it could be slightly more structured (e.g., bullet points) for enhanced 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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is partially complete: it covers parameter semantics well but lacks behavioral details like response format, error cases, or usage context. This makes it adequate for basic use but insufficient for full agent understanding without additional inference.
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 description adds meaningful context for all three parameters: it explains that 'init date' and 'end date' define a period for data retrieval with specific format (YYYY-MM-DD), and 'blog id' relates to a Metricool brand account. Since schema description coverage is 0%, this compensates well by clarifying parameter purposes beyond the schema's basic types and 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 the action ('Get the list of Youtube Videos') and specifies the resource ('from your Metricool brand account'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'get_tiktok_videos' or 'get_twitch_videos' beyond mentioning 'Youtube Videos', which slightly limits 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?
The description provides no guidance on when to use this tool versus alternatives, such as other 'get_' tools for different platforms (e.g., 'get_tiktok_videos'), nor does it mention prerequisites like authentication or account setup. Usage is implied by the tool name and parameters but not explicitly stated.
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 the tool 'Add[s] interesting conclusions for my brand about my competitors,' which implies analysis or insights generation beyond a simple list. However, it fails to disclose critical behavioral traits: whether this is a read-only operation, if it requires specific permissions, rate limits, or what the output format looks like (e.g., structured data vs. text). For a tool with no annotations and complex functionality, this is a significant gap.
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 structured with a purpose statement and a parameter list, but it's somewhat verbose in parameter explanations (e.g., repeating format details). Sentences like 'Add interesting conclusions for my brand about my competitors' are vague and could be more precise. It's front-loaded with the main purpose, but the parameter section lacks bullet points or clearer organization, making it less efficient.
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 annotations, 0% schema coverage, no output schema, and 6 parameters, the description does a fair job: it explains the purpose and parameters well. However, it misses key contextual details: no output information (what 'conclusions' entail), no behavioral disclosures (e.g., safety, permissions), and minimal sibling differentiation. For a tool with moderate complexity, this leaves gaps in completeness.
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?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all 6 parameters: formats for dates (YYYY-MM-DD), network options (e.g., 'twitter'), blog id context, default limit (10), and timezone format with a reference to 'get_brands tool'. This adds substantial meaning beyond the bare schema, covering all parameters effectively, though it could clarify 'blog id' sourcing more.
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's purpose: 'Get the list of your competitors from your Metricool brand account. Add interesting conclusions for my brand about my competitors.' It specifies the verb ('Get'), resource ('list of your competitors'), and includes the unique aspect of generating conclusions. However, it doesn't explicitly differentiate from sibling tools like 'get_network_competitors_posts', which might retrieve competitor posts rather than lists with insights.
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 implies usage by specifying parameters like 'network' and 'blog id', suggesting it's for analyzing competitors on specific social networks for a given brand. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., 'get_network_competitors_posts' for posts vs. lists) or any prerequisites. The mention of 'timezone' referencing 'get_brands tool' hints at context but isn't a clear usage rule.
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 of behavioral disclosure. It mentions retrieving and analyzing posts, but does not specify whether this is a read-only operation, if it requires authentication, rate limits, or what the output format looks like. The description adds minimal behavioral context beyond the basic action, leaving significant gaps for an AI agent.
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 appropriately sized and front-loaded with the core purpose, followed by a clear 'Args:' section detailing parameters. Each sentence adds value, though the analysis part ('Add interesting conclusions...') could be more integrated. Overall, it's efficient with minimal waste.
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 6 parameters with 0% schema coverage and no output schema, the description does well on parameter semantics but lacks behavioral details (e.g., output format, error handling). It's complete enough for basic usage but insufficient for full transparency, especially as a data retrieval tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 provides detailed semantics for all 6 parameters: formats for dates (YYYY-MM-DD), network options (e.g., 'twitter', 'facebook'), blog id context, limit default (50), and timezone format and source ('Use the timezone of the user extracted from the get_brands tool'). This adds substantial meaning beyond the bare 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's purpose: 'Get the list of posts from your competitors from your Metricool brand account' and adds 'Add interesting conclusions for my brand about my competitors and analyze their posts.' This specifies the verb ('get'), resource ('posts from competitors'), and context ('Metricool brand account'), but does not explicitly differentiate it from sibling tools like 'get_network_competitors' or network-specific tools (e.g., 'get_facebook_posts').
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 implies usage context by mentioning 'competitors' and 'Metricool brand account,' suggesting it's for competitive analysis. However, it lacks explicit guidance on when to use this tool versus alternatives like 'get_network_competitors' (which might provide different data) or network-specific tools. No exclusions or prerequisites are stated, leaving usage somewhat ambiguous.
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 discloses some behavioral aspects: the return format (list of hours/days with values), the 'higher value = better time' interpretation, and the fallback logic for missing hour data. However, it doesn't mention rate limits, authentication requirements, error conditions, or whether this is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured with a clear purpose statement, return format explanation, usage guidance, and parameter documentation. The 'Args:' section organizes parameter details efficiently. Minor redundancy exists in date format repetition.
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 the complexity (5 parameters, no annotations, no output schema), the description provides good coverage. It explains the return format, parameter semantics, and some behavioral logic. The main gap is lack of output structure details (exact fields, data types) which would be helpful without an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter semantics. It explains all 5 parameters: their purposes, formats, constraints (provider enum values), and even references another tool (get_brands) for timezone extraction. This adds substantial value beyond the bare 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's purpose: 'Get the best time to post for a specific provider' with a return format explanation. It specifies the resource (best posting times) and verb (get), but doesn't explicitly differentiate from sibling tools like get_analytics or get_metrics that might also provide timing-related data.
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 some implied usage context: 'Try to get the best for as maximum of 1 week' suggests optimal date range selection, and it references the get_brands tool for timezone extraction. However, it doesn't explicitly state when to use this tool versus alternatives like get_analytics or provide clear exclusion criteria.
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 describes the core behavior (getting brand list) and adds specific context about competitors being limited to certain networks, which is valuable behavioral information. However, it doesn't address other behavioral aspects like authentication requirements, rate limits, 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 reasonably concise with three sentences, but the structure could be improved. The first sentence states the purpose, the second provides usage guidelines, and the third adds behavioral context about competitors - this ordering is logical. However, the third sentence feels somewhat tacked on rather than integrated, and the description could be more polished.
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 tool with no parameters, no annotations, and no output schema, the description provides adequate coverage of purpose and usage guidelines. However, it lacks information about return format, authentication requirements, error handling, or what constitutes 'complete' versus the regular get_brands tool. The competitor network information is helpful but doesn't fully compensate for other missing context.
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?
With 0 parameters and 100% schema description coverage, the baseline would be 4 even with no parameter information in the description. The description doesn't discuss parameters (which is appropriate since there are none), so it meets expectations for a parameterless tool.
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 'list of brands from your Metricool account', making the purpose understandable. It distinguishes from sibling 'get_brands' by indicating this is for when users ask specifically for 'his brands', though the distinction could be more explicit about what makes this version 'complete'.
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?
The description provides explicit guidance on when to use this tool ('Only use this tool if the user asks specifically for his brands') and when to use the alternative ('in every other case use get_brands'). This directly addresses sibling tool differentiation with clear conditional logic.
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 mentions that it 'Only retrieves posts that are scheduled (not yet published)' and includes a note about asking for blog_id if missing, which adds some behavioral context. However, it lacks details on permissions, rate limits, pagination, or error handling, which are important for a tool with 5 required parameters and no output schema. The description does not contradict any annotations, but it is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and appropriately sized. It starts with a clear purpose statement, followed by a bullet-point list of parameters with concise explanations. Every sentence adds value, with no redundant information. It could be slightly more front-loaded by integrating parameter details into the initial description, but overall it is efficient and easy to parse.
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 complexity (5 required parameters, no annotations, no output schema), the description is partially complete. It excels in parameter semantics and purpose clarity but falls short in behavioral transparency (e.g., missing details on response format, error cases, or performance). Without an output schema, the description should ideally hint at return values, but it does not. It is adequate for basic use but has clear gaps for robust agent operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It provides detailed semantics for all 5 parameters: blog_id (Blog id of the Metricool brand account), start and end (date formats YYYY-MM-DD), timezone (format 'Europe%2FMadrid', sourced from get_brands), and extendedRange (expands search range, default false). This adds significant meaning beyond the bare schema, fully documenting each parameter's purpose and format.
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's purpose: 'Get the list of scheduled posts for a specific Metricool brand (blog_id). Only retrieves posts that are scheduled (not yet published).' It specifies the exact resource (scheduled posts), scope (for a specific brand, not yet published), and distinguishes it from siblings like 'get_analytics' or 'post_schedule_post' by focusing on retrieval of scheduled content only.
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 provides clear context for usage: 'If the user doesn't provide a blog_id, ask for it.' It implies when to use this tool (to get scheduled posts) but does not explicitly state when not to use it or name alternatives like 'get_analytics' for different data. The guidance is helpful but lacks explicit exclusions or sibling comparisons.
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 of behavioral disclosure. It describes some behavioral aspects: it's a retrieval operation (implied by 'Retrieve'), requires specific parameters, and mentions dependencies on other tools (get_metrics, get_brands). However, it lacks details on rate limits, authentication needs, error handling, or what the returned data looks like, which are important for a tool with 6 required parameters.
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 well-structured with a clear purpose statement followed by a parameter breakdown. It's appropriately sized for a tool with 6 parameters, though some sentences could be more concise (e.g., the conditional instructions are repetitive). Every sentence adds value, and it's front-loaded with the core functionality.
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 complexity (6 required parameters, no annotations, no output schema), the description is moderately complete. It covers parameter semantics thoroughly and provides usage guidelines, but lacks information about the return format, error conditions, or behavioral constraints like rate limits. For a data retrieval tool with multiple dependencies, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/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 fully compensate. It provides detailed semantics for all 6 parameters: explains what each parameter represents (e.g., 'blog_id' is 'ID of the Metricool brand account'), specifies required status, gives format examples (e.g., date format 'YYYY-MM-DD'), and includes usage notes (e.g., how to obtain timezone from get_brands). This adds significant value beyond the bare 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's purpose: 'Retrieve analytics data for a specific Metricool brand.' It specifies the verb ('Retrieve') and resource ('analytics data'), making it understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_metrics' beyond mentioning it as an alternative for obtaining metrics, so it doesn't reach the highest clarity level.
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?
The description provides explicit guidance on when to use this tool versus alternatives. It states: 'If the user does not specify any metric you can use the get_metrics tool and let the user decide them.' It also includes conditional instructions for missing parameters (e.g., 'If blog_id is missing, ask the user to provide it'), which helps the agent understand usage contexts and 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 provided, the description carries the full burden of behavioral disclosure. It effectively describes critical behaviors: the tool modifies existing posts (mutation), requires user confirmation before changes, has specific error handling (no retries, character limit errors), and includes platform-specific constraints (e.g., date can't be in the past, media requirements). However, it doesn't mention authentication needs or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively long (over 800 words) and poorly structured. While it contains valuable information, it's not front-loaded—critical usage guidelines are buried among platform-specific details. The 'Args:' section duplicates information from earlier text, and the platform-specific rules could be summarized more efficiently. Every sentence adds value, but the overall presentation lacks conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity (mutation operation, 4 parameters with 0% schema coverage, no annotations, no output schema), the description provides exceptional completeness. It covers purpose, usage prerequisites, behavioral constraints, detailed parameter documentation, platform-specific requirements, error handling, and format specifications. For a tool with this complexity and no structured support, the description leaves no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate. It provides extensive parameter semantics: explains that 'id' comes from 'get_scheduled_posts', details the 'date' format and constraint (can't be past), and comprehensively documents the complex 'info' JSON structure with all fields, formats, defaults, and platform-specific data requirements. This far exceeds the baseline expectation.
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's purpose: 'Update a scheduled post in Metricool.' It specifies the verb ('update'), resource ('scheduled post'), and platform ('Metricool'), distinguishing it from sibling tools like 'post_schedule_post' (create) and 'get_scheduled_posts' (read).
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?
The description provides explicit usage guidance: 'You need the id of the post to update. Get it from the get_scheduled_posts tool previous on the conversation.' It also includes detailed when-to-use rules for different social platforms (e.g., Instagram requires media, Bluesky has character limits) and explicitly states 'Do not retry if there is a problem.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so comprehensively. It details critical behavioral traits: validation rules (character limits for Bluesky/X, past date prohibition), error handling (do not modify text, notify user), platform-specific requirements (media needs for Instagram/Pinterest/YouTube/TikTok/Facebook), and interaction guidance (ask user for missing info).
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 information-rich, the description is overly verbose and poorly structured. It mixes high-level guidance, platform-specific rules, and parameter details in a dense block. Key behavioral information is buried among parameter specifications, and the text could be significantly streamlined with better organization while maintaining completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation tool with 3 parameters, 0% schema coverage, no annotations, and no output schema, the description provides exceptional completeness. It covers purpose, usage guidelines, behavioral constraints, error handling, all parameter details, platform-specific requirements, and references to other tools. Nothing essential appears missing given the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by providing extensive parameter semantics. It explains all three parameters in detail: 'date' format, 'blog_id' purpose, and most importantly, the complex 'info' JSON structure with all fields, their formats, defaults, and interdependencies. This goes far beyond what the bare schema provides.
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's purpose with specific verb ('Schedule') and resource ('a post to Metricool'), distinguishing it from sibling tools like 'get_scheduled_posts' (which retrieves) and 'update_schedule_post' (which modifies). It explicitly defines the action of scheduling with specific timing requirements.
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?
The description provides explicit guidance on when to use this tool versus alternatives, mentioning 'get_best_time_to_post' for time selection if unspecified. It also outlines prerequisites like maintaining structure and platform-specific requirements, and implicitly distinguishes from sibling tools by focusing on creation rather than retrieval or update.
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:

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

Score Badge

Copy to your README.md:

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

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/metricool/mcp-metricool'

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