blogger-mcp-toolkit

Server Quality Checklist

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

Latest release: v1.1.3
Disambiguation5/5
Each tool targets a distinct resource and action, with clear boundaries between list/get/search, full updates vs patches, and comment moderation actions. Even similar tools like posts_update and posts_patch are clearly differentiated by their descriptions.
Naming Consistency5/5
All tool names follow a consistent blogger_<resource>_<action> pattern using snake_case. Compound actions like getByPath and searchByLabel are also uniformly structured, making the naming predictable and easy to navigate.
Tool Count2/5
At 29 tools, the count exceeds the 25+ threshold, making the server feel heavy. While the scope of Blogger API justifies many tools, the sheer number may overwhelm agents and increase selection complexity.
Completeness5/5
The toolkit provides thorough CRUD and lifecycle coverage for posts, pages, comments, and blogs, plus user and media utilities. There are no glaring gaps; the inclusion of publish/revert, spam handling, and media embedding makes the surface complete for common Blogger workflows.
Average 3.7/5 across 29 of 29 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 only states that the tool returns an array of comment objects, omitting critical details such as pagination behavior (pageToken, maxResults), optional filters (status, dates), and differences based on the 'view' parameter. The tool name suggests a read operation, but the description does not reveal these nuances.
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 two short sentences, front-loading the core action and resource. It contains no filler, and every word contributes to the basic understanding of the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a tool with 9 parameters and no annotations. It fails to mention optional filtering capabilities (status, date ranges), pagination, or the impact of the 'view' parameter. The schema details parameters but does not provide usage context, and the description does not fill this gap, making it incomplete for an agent to select and invoke the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for 100% of parameters, so the baseline is 3. The description adds no additional parameter semantics beyond the generic 'all comments', leaving interpretation of filters and pagination to the schema. Since schema already covers everything, a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('comments for a specific post'), which distinguishes it from the sibling 'blogger_comments_listByBlog' through the 'specific post' qualifier. However, it does not explicitly name the sibling or contrasting use cases, so it falls short of 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 explicit when-to-use or when-not-to-use guidance. The phrase 'for a specific post' implies a use case, but it does not mention alternatives like blogger_comments_listByBlog or define scenarios where this tool should be avoided, such as when needing comments across a blog.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It only says 'create' implies mutation but does not mention authentication, immediate publishing, or side effects. The schema covers isDraft, but description adds no behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with zero redundancy. It is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide context about return values, draft/publish behavior, and errors. It does not, leaving significant gaps for a tool with 6 parameters.
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 100%, so the schema fully documents parameters. The description adds no additional parameter information, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('a new blog post'), clearly indicating the operation. However, it does not distinguish this from sibling tools like blogger_posts_update or blogger_pages_insert, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool vs alternatives. It simply states what it does, without mentioning publication state, draft handling, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only mentions 'optional summary mode to strip heavy HTML', but does not state that the operation is read-only, how pagination works, or whether fetchBodies is required to get full content by default. This is insufficient for a tool with zero 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 a single, front-loaded sentence with clear action and resource. It is efficiently concise, although it sacrifices contextual depth that would earn a 5.
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 7 parameters, no output schema, and no annotations, the description provides only minimal context about return values or operational behavior. The schema fills in parameter semantics, but the description does not convey pagination expectations, response structure, or typical use scenarios, leaving the tool minimally viable but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% description coverage for all 7 parameters, so the baseline is 3. The description adds marginal value by hinting at summaryOnly through 'summary mode' but does not elaborate on parameter formats or dependencies beyond what the schema already states.
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 a specific verb ('List') and resource ('static pages for a specific blog'), making its purpose unmistakable. It naturally distinguishes itself from sibling tools like blogger_posts_list (posts vs. pages) and blogger_pages_get (single vs. all pages).
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 about when to use this tool versus alternatives such as blogger_pages_get or blogger_posts_list. The description does not mention any exclusions or preferred use cases, leaving the agent to infer appropriateness from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that the entire post content is replaced, but does not mention side effects such as clearing omitted fields, the effect of the 'publish' or 'revert' flags, or required permissions. This is insufficient for a mutation tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the key concept of 'full update' and 'replaces the entire post content.' Every word contributes to the meaning; there is no fluff or redundancy. This is a model of concise, structured description.
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 7 parameters, no output schema, and no annotations, the description is too brief. It does not explain return values, what happens to fields not passed (e.g., labels), the interaction of the publish/revert flags, or how this differs from patch in terms of required fields. The description leaves too many gaps for the agent to understand the full update semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all 7 parameters (100% coverage), so the baseline is 3. The description adds minimal parameter semantics beyond the schema, only reinforcing the 'full replacement' concept. It does not explain relationships between parameters (e.g., labels replacing the existing set) or the meaning of optional flags in the context of a full update.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'full update' of an 'existing blog post' and that it replaces the entire content. This distinguishes it from the sibling 'patch' operation, though it does not explicitly name the alternative. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for full replacement scenarios via the phrase 'full update' and 'replaces the entire post content.' However, it does not explicitly state when to use this instead of a partial update (e.g., blogger_posts_patch) or any conditions/exclusions. Usage guidance is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the state change (published to draft) but omits side effects, permissions required, idempotency, or behavior when the post is not published.
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 concise sentence that immediately conveys the tool's action and resource. No filler or redundancy, making it highly 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?
The tool is simple with well-documented parameters, but the description lacks behavioral context (e.g., error cases, prerequisites). It is adequate for basic usage but not fully complete for a mutation tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides complete descriptions for both parameters (blogId, postId) with 100% coverage. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('revert') and resource ('published blog post back to a draft'), clearly distinguishing it from sibling tools like 'publish' (which does the opposite) or 'delete' (which removes entirely).
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 explicit guidance on when to use this tool versus alternatives like publish or delete. The intended use is implied by the name, but no context, prerequisites, 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 bears full responsibility for disclosing behavioral traits. While 'Retrieve' indicates a read operation, it adds nothing beyond what the tool name implies. It does not mention permissions, rate limits, moderation effects, or any constraints like the role of the 'view' parameter.
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, efficient sentence that is front-loaded with the verb and resource. Every word earns its place, with no unnecessary filler. It is appropriately concise for a simple get operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should provide more context about return values or behavior. It does not mention what data is returned or how the 'view' parameter affects results. Given the availability of comment moderation features among siblings, additional context about visibility would be valuable.
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 100%, so the baseline is 3. The description only references 'comment ID' which corresponds to commentId, but does not elaborate on blogId, postId, or view. With schema covering all parameters, the description adds minimal extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and the resource ('a single specific comment') with a unique identifier. This distinguishes it from sibling list operations like blogger_comments_list or blogger_comments_listByBlog, as it focuses on fetching one comment by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a comment ID, but does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites beyond the required IDs. It provides minimal contextual guidance but no explicit comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions partial-update behavior but omits side effects of the 'publish' and 'revert' parameters, authentication requirements, rate limits, or response format. This is a significant gap for a mutation tool.
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, front-loaded sentence with no filler. It directly states the purpose and key behavior, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no output schema, no annotations), the one-sentence description is insufficient. It does not explain return values, the effects of 'publish'/'revert', prerequisites, or relationships to sibling tools like blogger_posts_publish and blogger_posts_revert.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all 7 parameters (100% coverage), so the description need not add parameter details. The phrase 'only the provided fields' reinforces the optional nature of most parameters, which is already evident from the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Perform a partial update') and the resource ('a blog post'). The phrase 'partial update' and 'only the provided fields' effectively distinguishes this tool from the full update tool (blogger_posts_update) and other sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when only specific fields need updating, but it does not explicitly state when not to use it or name alternatives. No exclusions or alternative tool references are provided, so the guidance is purely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of disclosing behavioral traits. It explicitly mentions 'permanently delete', which communicates that the operation is destructive and irreversible. However, it does not disclose any side effects (e.g., whether comments are also deleted) or required permissions, so it is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no redundant words. 'Permanently' adds meaningful nuance, and the structure is front-loaded, making it concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with two fully documented parameters and no output schema, the description is nearly complete. It conveys the tool's purpose and irreversibility, though it could benefit from a brief note on when to use deletion versus other post-modification tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides clear descriptions for both blogId and postId, achieving 100% coverage. The description adds no additional parameter-specific semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with the specific verb 'delete' and the resource 'blog post', and the word 'permanently' adds key information about irreversibility, distinguishing it from other post operations like publish, update, or revert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, scenarios where deletion is preferred over other operations, or any exclusions, leaving usage entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic function and does not mention pagination, status filtering, read-only nature, or response format. This is insufficient for a tool with multiple optional parameters.
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 one concise, front-loaded sentence that immediately states the action and target. No filler or redundant language is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's moderate complexity (6 parameters, no output schema), the description lacks guidance on pagination, status filtering, or response contents. It does not compensate for the absence of an output schema, leaving the agent under-informed.
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 descriptions cover 100% of the parameters, so the schema already provides complete parameter semantics. The description adds no extra meaning beyond what the schema provides, warranting the baseline score of 3.
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 function: filtering and retrieving posts by a specific label. This verb+resource+method structure distinguishes it from siblings like blogger_posts_list (all posts) and blogger_posts_search (content search).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use the tool (filter by label), but does not explicitly mention alternatives or when not to use it. The word 'quickly' hints at a lightweight operation but lacks direct comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation returns a list/array, but it does not explicitly state that it is a read-only operation, mention authentication requirements, or describe any side effects. It provides some useful context (return format) but lacks details about pagination, filtering defaults, or user-specific behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that state the core function and the return type. Every word earns its place, with no filler or redundancy. It is front-loaded with the primary action and resource.
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 has 5 optional parameters and no output schema or annotations, the description is somewhat minimal. It clearly identifies the operation (list blogs by user) and return type, but it does not provide usage guidance, mention filtering capabilities, or clarify behavioral aspects like read-only nature. The schema covers parameters, but for a tool with this complexity, a bit more context (e.g., 'By default, userId is set to self') would improve completeness.
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 100%, so the baseline is 3. The description itself adds no parameter-level detail beyond what the schema already provides. It references 'a specific user' which maps to the userId parameter, but does not explain the default ('self') or the filtering options (role, status, view, fetchUserInfo). The schema fully describes these, so the description does not need to compensate.
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 function: 'List all blogs associated with a specific user.' The verb 'list' and resource 'blogs' are specific, and it distinguishes this tool from siblings like blogger_blogs_get (get a single blog) and blogger_blogs_getByUrl (get by URL). It also mentions the return type ('array of blogs'), reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only explains what the tool does, not when to use it over alternatives. There is no explicit mention of exclusions or alternative tools. The intended usage is implied by the name and description, but the tool does not provide direct guidance such as 'use this to list all blogs for a user, versus blogger_blogs_get for a single blog.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only states 'List' without mentioning pagination, default statuses, return format, or auth requirements. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and scope, and every word adds value. It is appropriately concise without missing essential purpose.
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 and rich schema, the description covers purpose and use case but omits behavioral details like pagination or default filtering. With no output schema, it could mention the return shape, but 'List' partially implies it. Overall adequate but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not restate parameter meanings. It adds a slight semantic cue by linking blogId to 'across all posts', but otherwise relies on the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and a clear resource ('comments across all posts in a blog'), distinguishing it from the sibling blogger_comments_list, which likely targets a single post. The scope is explicit and useful for moderation.
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?
It clearly suggests a use case ('global comment moderation view') that implies when to use this tool over per-post listing, but does not explicitly name alternatives or exclusions. The context is clear, yet lacks direct 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?
With no annotations provided, the description carries the full burden. 'Permanently delete' discloses the destructive and irreversible nature of the operation, which is valuable. However, it omits other behavioral context such as permission requirements, behavior on non-existent page, or whether the operation is idempotent.
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, front-loaded sentence of 8 words. It uses a strong verb and directly states the action and target, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete tool with no output schema and complete parameters, the description covers the essential purpose but lacks contextual richness. It does not mention prerequisites, return behavior, or broader impact beyond the page itself. Adequate but minimal.
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 100%, covering both blogId and pageId. The description adds minimal semantic value beyond the schema—'by its ID' reinforces pageId's role but does not explain blogId's scoping purpose. Baseline 3 is appropriate when the schema already documents parameters.
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 'Permanently delete a static page by its ID' uses a specific verb ('delete'), identifies the resource ('static page'), and specifies the mechanism ('by its ID'). This clearly distinguishes it from sibling tools like blogger_posts_delete and blogger_comments_delete.
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 for static page deletion through the phrase 'static page', but it does not explicitly contrast with alternatives (e.g., 'use blogger_posts_delete for posts') or state any exclusions. The sibling awareness is present but not explicitly leveraged to guide 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Create' without mentioning publication defaults, return values, permissions, or side effects. The schema notes isDraft default but the description adds no behavioral context beyond the action itself.
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?
A single, clear, front-loaded sentence with no redundant wording. It earns its place.
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?
The schema fully documents parameters, but with no annotations and no output schema, the description leaves gaps about return values and post-create behavior. It is adequate for a simple create operation but not fully complete.
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 100%, so the baseline is 3. The description's mention of 'title and HTML content' merely echoes the schema and does not add further semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create a new static page' with specific details about title and HTML content. It distinguishes from sibling tools like blogger_posts_insert by specifying 'static page' and from page update/delete tools through the verb 'create'.
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 term 'static page' provides clear context that this tool is for Blogger pages, differentiating it from posts. However, it does not explicitly mention when not to use it or name alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions 'optional lightweight summary mode' but does not state whether the operation is read-only, describe pagination, or address authentication. The description adds some context but lacks important behavioral details.
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, well-structured sentence that front-loads the action ('Search') and resource ('a blog's posts'). It avoids redundant wording and is appropriately concise for its purpose.
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?
Although the description is clear about the core function, it lacks details about return structure, pagination, or how it compares to searchByLabel. With no output schema or annotations, the description should cover these gaps but only partially does so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of parameter descriptions. The description's mention of 'text query string' and 'summary mode' aligns with q and summaryOnly but adds no new semantics beyond what the schema already documents. Baseline 3 applies because schema is fully self-explanatory.
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 function: searching across a blog's posts using a text query string. It distinguishes itself from siblings like blogger_posts_list (list all posts) and blogger_posts_searchByLabel (search by label) by emphasizing text-based search.
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 text-based search is needed, but it does not explicitly provide alternatives or exclusions. No comparison to sibling tools like searchByLabel or list is offered, leaving the agent to infer when this tool is the right choice.
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 transparency burden. It discloses the key behavioral effect (removing the comment from the live view), which gives some insight into the tool's behavior. However, it does not mention whether the action is reversible, if it requires special permissions, or what happens to the comment's state beyond visibility. This is acceptable for a simple moderation action but lacks deeper context.
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, concise sentence that front-loads the action and result. Every word earns its place, with no redundant information or unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple moderation tool with three identifier parameters, no output schema, and no nested objects, the description adequately explains the tool's purpose and effect. It does not need to explain return values (none provided) and the parameter schema covers the inputs. While it could mention reversibility or permissions, these are not essential for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes all three parameters with clear explanations (blogId, postId, commentId), and the schema coverage is 100%. The tool description adds no extra parameter-specific meaning beyond what the schema already states; it only reinforces which comment is being marked. By the baseline rule, this scores a 3.
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 uses a specific verb ('Mark') and resource ('a comment') with a clear action ('as spam') and explains the visible effect ('moving it out of the live view'). It immediately distinguishes this from sibling operations like approve, delete, or removeContent.
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 when to use the tool (to hide spam comments from public view) but does not explicitly state exclusions or alternatives. It contrasts with approve by the effect, but does not name sibling tools or conditions like 'use only for comments that are actually spam, not for comments that merely need moderation.'
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 bears the full burden. It discloses that the tool returns content and metadata, but it does not explain the behavioral impact of the 'view' parameter (e.g., ADMIN vs READER access levels) or any potential side effects/errors. It safely implies a read operation but lacks depth.
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, front-loaded sentence that uses a clear verb-first structure. Every word contributes meaning without redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description adequately communicates the return value ('content and metadata'). It does not list the required parameters (handled by schema) or cover edge cases like pagination or authorization, but given the low complexity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptive text for all three parameters, including the enum for 'view', giving 100% coverage. The description adds no additional parameter-level meaning, so it does not exceed the schema baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve'), the resource ('a single static page'), and the means ('by its unique page ID'). It also specifies what is returned ('content and metadata'), differentiating it from sibling tools like blogger_pages_list and blogger_pages_delete.
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 a specific page ID is known, but it does not explicitly state when to use this tool over alternatives such as blogger_pages_list or blogger_pages_getByPath. There is no mention of prerequisites or when not to use it, so guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic retrieval action and gives no information about permissions, return format, pagination, or potential side effects. This is a significant gap for a tool with no structured safety hints.
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 sentence, front-loaded with the action and followed by a relevant use case. No redundant information, making it extremely concise and to the point.
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 tool's simplicity and the fact that the schema covers all parameters exhaustively, the description provides the essential purpose and a typical use case. It does not mention optional parameters or return details, but these are either self-explanatory or covered by the schema, making this adequate for a straightforward retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description adds minimal semantic value—it mentions 'path' as the key identifier, but that is already implied by the schema. It does not help disambiguate the optional 'view' or 'maxComments' parameters.
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 'Retrieve a single blog post by its URL path', using a specific verb with a clear resource and method. This distinguishes it from sibling tools like blogger_posts_get (which likely retrieves by ID) by emphasizing the path-based lookup.
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 phrase 'Useful when resolving public blog links' provides a clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusions (e.g., when you have a post ID vs. a path), so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the core behavior (partial update, only provided fields) but does not mention side effects such as how publish/revert booleans interact with the update, whether existing unprovided fields are preserved (though implied), or permissions/auth requirements. The disclosure is adequate but lacks depth.
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 two sentences, directly states the purpose and key behavior, and contains no filler or repetition. It is front-loaded and efficiently conveys the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters and no output schema or annotations. The description covers the core partial-update concept but does not address edge cases like setting both publish and revert, or the required blogId/pageId (though those are in the schema). For a mutation tool, this leaves some contextual gaps regarding operational expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so the baseline is 3. The description adds only an example ('e.g., title or content') which does not go beyond schema semantics. It does not clarify the relationship between publish/revert and the update, so no additional meaning is provided beyond the structured fields.
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 performs a partial update of an existing static page, which is specific and distinguishes it from sibling tools like blogger_pages_update (full update) and blogger_pages_insert. It also clarifies that only provided fields are updated, reinforcing the 'patch' semantics.
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 phrase 'partial update' and 'Only updates the provided fields' gives clear context for when to use this tool—specifically for targeted modifications. However, it does not explicitly name alternative tools (e.g., blogger_pages_update for full replacement) or state exclusions, but the partial-update framing implies usage boundaries effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral trait of full replacement, which is essential. However, it does not explain the implications of optional parameters like publish and revert, or what happens to other page properties, leaving meaningful gaps.
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 concise sentence, front-loaded with the main purpose, and every word contributes value. It is neither verbose nor under-specified.
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 six parameters, no annotations, and no output schema, the description covers the core update semantics but omits behavior around optional parameters (publish, revert) and potential side effects. It is adequate but not complete for guiding an agent through all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for all six parameters, so the baseline is 3. The description only mentions title and content, adding no significant meaning beyond the schema for optional parameters like revert and publish.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'full update of an existing static page' and 'replaces the entire page with the new title and content.' This specifies the verb, resource, and scope, and naturally distinguishes it from sibling tools like blogger_pages_patch (which implies partial updates).
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 by emphasizing 'full update' and 'replaces the entire page,' indicating this is for complete replacements and not partial edits. However, it does not explicitly name alternatives like blogger_pages_patch or state when not to use this tool, so it falls short of a 5.
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 disclosure burden. It reveals the two behavioral modes (immediate vs. scheduled) but does not mention the post's status change, reversibility, or failure conditions. The scheduling option adds some value beyond the schema.
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 13-word sentence that directly states the action and its two variants, with zero redundancy. It is front-loaded and efficiently communicates the core purpose.
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 3-parameter publish tool with no output schema or annotations, the description covers the essential purpose and the two modes, but omits the return value, error conditions, and irreversibility. It is adequate for a simple action but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all three parameters, so the baseline is 3. The description's mention of 'scheduled for the future' aligns with the publishDate parameter but adds no new information beyond what the schema already 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 uses the specific verb 'publish' with the resource 'blog post' and explicitly distinguishes between immediate and scheduled publishing. This clearly differentiates it from sibling tools like revert, delete, and update, which have distinct purposes.
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 implies the use case: publish a draft post, either now or later. However, it does not explicitly state when not to use this tool (e.g., for updating existing content) or mention any prerequisites like ownership or required permissions.
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 transparency burden. It correctly labels the operation as 'Retrieve' (read-only) and lists return fields, but it omits details like permission requirements, error behavior, and the effect of view/maxPosts parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences deliver the purpose, method, and return content without redundancy. The structure is front-loaded with the action and qualifies the scope immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description plus complete schema coverage is mostly sufficient. It provides representative return fields, though the lack of an output schema and annotations means some behavioral aspects are left unspecified.
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 100%, so the parameters are already well-documented. The description adds minimal semantic value beyond reaffirming that blogId is the lookup key; it doesn't elaborate on view or maxPosts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a single blog's metadata using a unique blog ID. This specific verb-resource relationship and the ID-based lookup distinguish it from sibling tools like getByUrl and listByUser.
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 gives clear context: use this tool when you have a blog ID and need metadata. However, it doesn't explicitly mention alternatives or when-not-to-use cases, so it stops short of a perfect score.
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 must carry the full burden. It only says 'Retrieve' which implies a read operation, but it doesn't disclose what metadata is returned, error behavior, permissions, or rate limits. This is not misleading, but it's minimal for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, front-loaded with the purpose, and has zero filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-resource GET with two well-described parameters, the description covers the essential selection criteria and the unique URL-based identifier. It doesn't explain what the metadata includes or specify authentication requirements, but given the simplicity, the tool is adequately described for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters (url and view) with descriptions, so schema coverage is 100%. The description adds no additional meaning beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieve' plus the specific resource 'a single blog's metadata' and the scoping method 'by its public URL.' This distinguishes it from sibling tools like blogger_blogs_get (likely by ID) and blogger_blogs_listByUser (by user), so the agent can easily differentiate.
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?
It provides a clear usage context: 'Useful when you only know the blog address.' This tells the agent when to select this tool, though it doesn't explicitly mention alternatives or when not to use it. The context is clear enough to guide selection.
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 burden of disclosing safety-critical behavior. 'Permanently delete' clearly communicates irreversibility, which is a significant behavioral trait beyond the tool name. It does not mention auth requirements or side effects, but the core destructive nature is explicit.
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 sentence that front-loads the action and permanence. Every word contributes, with no fluff or 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?
For a simple delete tool with fully documented parameters and no output schema, the description is largely sufficient. However, given multiple comment-related siblings, a note on when to choose delete over removeContent or markAsSpam would enhance completeness slightly.
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 100%, with each parameter (blogId, postId, commentId) clearly described in the schema. The description adds no additional parameter context, so it meets the baseline but does not exceed it.
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 'Permanently delete a comment from a post' uses a specific verb (delete), names the resource (comment), and specifies scope (from a post). It clearly distinguishes from sibling tools like blogger_comments_approve or blogger_comments_removeContent by emphasizing permanence.
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 for permanent deletion, but it does not explicitly contrast with similar comment moderation tools such as removeContent or markAsSpam. No when-to-use or when-not-to-use guidance is provided, leaving the agent to infer from tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the read-only nature ('Retrieve') and indicates the return contents (content, metadata, labels, optional comments/images). However, it does not mention authentication requirements, error conditions, or the effect of the 'view' parameter, leaving some behavioral aspects unexplained.
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, front-loaded sentence with no redundant content. It states the action and resource immediately, then follows with a concise list of included data. Every word earns its place.
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?
Despite having no output schema, the description adequately conveys the return composition and identifies the unique ID as the selection key, enabling differentiation from siblings. It does not elaborate on the view access level or response structure, but for a simple get-by-ID operation, it is sufficiently complete for an agent to select and invoke correctly.
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 coverage is 100%, establishing a baseline of 3. The description adds value by grouping parameters conceptually: 'content, metadata, labels' map to default behaviors, while 'optionally comments and images' directly explains the purpose of fetchComments (via maxComments) and fetchImages. This synthesis helps the agent understand the optional flags beyond their schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single blog post by unique ID, using the specific verb 'Retrieve' and resource 'blog post'. It also enumerates included data (content, metadata, labels, optionally comments/images), which distinguishes it from sibling tools like search or list that operate on multiple posts or by path.
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 the unique post ID is known, but it does not explicitly state when to use this tool versus alternatives like getByPath (which uses path) or list (which discovers posts). No exclusions or alternative suggestions are provided, giving clear context but no direct guidance.
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 mentions the tool returns user details (ID, name, URL, location), which gives some insight into behavior, but it does not state whether authentication is required, that it is a read-only operation, or any other operational constraints.
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 two concise sentences, front-loaded with the primary action and then elaborating on return details. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-profile tool with one optional parameter and no output schema, the description adequately conveys purpose and returns. It doesn't need to detail return values extensively, though it could briefly note the parameter default (already in schema). Overall, it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the single userId parameter, including its default value and meaning. The description adds no additional parameter semantics beyond what the schema states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a user's Blogger profile information, using the specific verb 'Retrieve' and naming the resource. It distinguishes itself from sibling tools, as no other tool handles user profile retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need a Blogger user's profile details. It doesn't explicitly exclude alternatives, but no sibling tool serves the same purpose, making the use case clear.
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 burden of behavioral disclosure. It states the key side effect: the comment is removed from spam or pending status and becomes live. While it does not mention permissions or reversibility, this covers the core behavior for a straightforward approve action.
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, focused sentence that front-loads the action ('Approve a comment') and immediately conveys the outcome. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool with no output schema and no annotations, the description covers the essential behavior. It could mention the response format or prerequisites like moderation permissions, but it is adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (blogId, postId, commentId) with 100% coverage. The tool description adds no additional parameter-specific meaning, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'approve' with the resource 'comment' and clearly explains the outcome: removing it from spam or pending status and making it live. This distinguishes it from sibling tools like markAsSpam and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool (whenever a comment should be approved) and clarifies the effect. It does not explicitly mention alternatives or exclusions, but the context is clear enough for agents to select it over sibling comment actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the key behavioral outcomes: content is replaced with an admin notice and the comment object persists. It does not mention permissions or reversibility, but the core mutation behavior is clearly stated.
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, front-loaded sentence that states the action and its caveats without any unnecessary words. It is perfectly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter mutation tool, the description explains the primary effect and distinguishes it from deletion. However, it does not describe the return value or any required permissions, which leaves minor operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a generic 'unique identifier' description. The tool description adds no additional parameter semantics beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove comment content') and clearly identifies the resource and outcome, including replacing with an admin notice and not fully deleting the comment object. This distinguishes it from sibling tools like blogger_comments_delete.
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 implies the use case: to redact content while preserving the comment object, and contrasts with deletion ('without fully deleting the comment object'). However, it does not explicitly name alternatives or exclusion criteria, making it clear but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the output (Base64 Data URI and img tag) but does not disclose potential limitations (e.g., size inflation, failure modes, or whether it only reads the file). It is not misleading, but it lacks depth in behavior beyond the core function.
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 two concise sentences, front-loaded with the main action. It provides all necessary information without redundancy, making it easy to parse.
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?
With no output schema, the description clarifies the return value by mentioning the generated <img> tag snippet. It covers essential context for a utility tool, though it could be more explicit about the exact response format or error handling.
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 coverage is 100%, providing descriptions for all parameters. The description adds value by listing supported image formats, which complements the filePath schema description and informs which files are valid.
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 function: converting local image files to Base64 Data URIs and generating a Blogger <img> tag snippet. It specifies supported formats and the output, distinguishing it from sibling Blogger API tools like post/pages management.
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 context on when to use this tool: for embedding images permanently in Blogger posts without external host dependencies. It does not explicitly name alternatives or exclusions, but the use case is clear.
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?
No annotations are provided, so the description carries the burden. 'List' clearly indicates a read-only operation, and mentioning pagination and summary mode offers useful behavioral context. It does not go into details like response format or auth requirements, but for a read-only list tool this is adequate.
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?
A single, front-loaded sentence that states the core action and key capabilities. Every word earns its place with no fluff or 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?
For a tool with 12 parameters, the description is concise but adequate because the schema richly documents every parameter. With no output schema, the description doesn't detail return structure, but 'List posts' strongly implies the response is a collection of posts. Overall, it provides enough context for an agent to select and invoke the tool correctly.
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 100%, so baseline is 3. The description groups parameters conceptually (filtering, pagination, summary mode) but adds no meaning beyond the schema's per-parameter descriptions. It is redundant with the schema rather than supplementary.
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 uses a specific verb ('List') and resource ('posts for a specific blog'), clearly distinguishing it from sibling tools like blogger_posts_get (single post) and blogger_posts_search. It also highlights optional filtering, pagination, and summary mode, which further defines its scope.
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 implies use cases: listing posts for a blog with optional filters and pagination. It gives clear context but does not explicitly mention alternatives or exclusions, such as 'use blogger_posts_get for a single post'. This aligns with 'clear context, no exclusions'.
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:

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

Score Badge

Copy to your README.md:

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

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/RadouaneElarfaoui/blogger-mcp-toolkit'

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