bitbucket-python-mcp

Server Quality Checklist

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

Latest release: v0.2.2
Disambiguation4/5
Most tools have clearly distinct purposes, with memory and PR operations well-separated. However, get_file_content and get_repository_contents both retrieve file content, which could cause confusion despite different functionality.
Naming Consistency4/5
The majority follow a consistent verb_noun pattern (e.g., create_branch, list_pull_requests). Only remember_from_pr_comment deviates, being a verb_phrase rather than simple verb_noun.
Tool Count3/5
With 32 tools, the server is on the heavier side but still within a reasonable range for a comprehensive Bitbucket integration. The count is justified by the inclusion of memory management features.
Completeness3/5
Core Bitbucket operations are well-covered (repos, branches, PRs, comments, search), but notable gaps exist: there's no tool to merge a pull request, update PR details, or manage commits. The memory subsystem is a nice addition but not part of the core domain.
Average 4.2/5 across 32 of 32 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- 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?
No annotations provided; description only says 'Delete' without disclosing confirmation, reversibility, authorization needs, or side effects. Minimal behavioral context for a destructive action.
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?
Very concise, with no wasted words. Includes optional formatting for arguments and returns, but is efficient for a simple tool.
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 one parameter and an output schema, the description is minimally viable. However, lacks detail on behavior beyond deletion (e.g., confirmation format, ripple effects).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'memory_id' with 0% schema description coverage. Description merely repeats the parameter name and its purpose as ID, adding no value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete', the resource 'memory', and the identifier 'by ID'. It distinguishes from sibling tools like 'add_memory' or 'list_memories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as whether there is a bulk delete or undo capability. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return value but lacks disclosure of side effects, authorization requirements, or whether the approval triggers merges. Critical behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with only necessary sentences, front-loads the action, and includes a structured Args section. Every sentence serves a purpose with no redundancy.
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?
Output schema exists, reducing need to explain return values. Parameter descriptions are complete. However, missing behavioral context (e.g., preconditions, permissions, side effects) leaves gaps for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining each parameter's meaning and default behavior (e.g., repository slug uses context if not provided). Provides clear semantics beyond the schema types.
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 'approve a pull request' and the purpose 'indicating the changes are acceptable and ready to merge.' It distinguishes from sibling tools like 'request_changes' implicitly, but does not explicitly differentiate, thus score 4.
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 implies when to use (when changes are acceptable) but does not provide explicit guidance on when not to use or alternatives such as 'request_changes' or 'add_pull_request_comment'. No when-not or comparison is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should carry the full burden of behavioral disclosure. It explains the return format (JSON list) and names parameters, but lacks details on side effects, error handling, or the meaning of 'relevance.' The tool is read-only, but this is not explicitly stated. More behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the purpose, followed by usage guidance and parameter explanations. The Args section is well-structured. No unnecessary sentences.
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 output schema exists and the description explains the return, the description is adequate for a simple retrieval tool. It covers when to use and parameter functions. However, it lacks details on how relevance is determined or how the tool filters by workspace and repository context, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides an Args section with brief explanations for each parameter: workspace (default if not specified), repository, and categories (comma-separated, with example). This adds meaning beyond the raw schema, though it could be more detailed about formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all memories relevant to the current context,' providing a specific verb and resource. It gives usage examples (start of PR review, working with a repository) and distinguishes itself from sibling tools like 'list_memories' and 'search_memories' by focusing on relevance to context. However, it does not explicitly differentiate from all siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to call this tool 'at the start of a PR review or when working with a repository to retrieve all applicable standards and learnings,' which gives clear contextual guidance. It does not mention alternatives or when not to use, but the context is sufficient for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the filtering behavior and return format, but with no annotations, it does not explicitly disclose read-only nature, authorization needs, or limits. The behavior is implied but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: overview, parameter details, return type. It avoids redundancy and is easy to scan.
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?
The description is complete for a simple list tool, covering filter behavior and return type. With an output schema present, the agent has enough information to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds significant value by listing possible categories and explaining how the workspace parameter includes global memories. This compensates for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists stored memories/learnings with optional filters. However, it does not differentiate from sibling tools like 'search_memories', which may perform a similar function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance such as the inclusion of global memories when filtering by workspace, but it does not explicitly state when to use this tool versus alternatives like 'search_memories'.
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 convey behavioral traits. It states it returns a JSON list with names, descriptions, and URLs, but omits details like sorting order, pagination beyond limit, or whether it uses the default workspace. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for purpose, usage, arguments, and returns. It is concise without being too terse, though some sentences could be streamlined.
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 existence of an output schema and the complexity of sibling tools, the description covers the core functionality but lacks details on pagination, sorting, or error handling. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well. It explains the 'workspace' parameter defaults to an environment variable and 'limit' defaults to 50. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists repositories in a BitBucket workspace and positions itself as the primary discovery tool. However, it does not explicitly differentiate from the sibling 'search_repositories' tool, which might filter results.
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 usage context: use when the user wants to see available repositories or browse for a specific one. However, it does not mention when not to use it or suggest alternatives for filtered searches.
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 mentions the parameters and that a memory is created, but lacks details on side effects, permissions, idempotency, or error conditions. Essential behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clear docstring format with Args and Returns sections. It's front-loaded with purpose, and each sentence is necessary. Slightly verbose but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 params, 4 required) and the presence of an output schema, the description covers purpose, usage, and parameter details. However, it lacks behavioral transparency, which prevents a higher score.
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?
Although the schema has 0% description coverage, the tool's description explains each parameter's meaning and default values (e.g., category enum, apply_to_all_repos behavior). This adds significant value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Extract and store a learning from a PR comment.' It specifies a specific verb and resource, distinguishing it from similar tools like add_memory that operate on generic memories.
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 explicitly states when to use the tool: 'Use this when you identify a standard or pattern in a PR comment that should be remembered for future reference.' It does not mention alternative tools, but the context is clear given the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states it returns a JSON list but does not mention whether the operation is read-only, any authentication requirements, rate limits, pagination, or error states. For a search tool, minimal behavioral context is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is reasonably concise with clear sections (Args, Returns). However, it could be slightly more terse without losing clarity. The structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 optional parameters, no enums) and the presence of an output schema, the description covers purpose and parameters adequately but lacks behavioral context (read-only assumptions, pagination, etc.). It meets minimum viability but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaningful context for both parameters: 'query' is a filter by name, 'workspace' defaults to the default workspace. This compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (search), resource (repositories), and scope (in a BitBucket workspace). It also clarifies behavior when query is not provided (lists all repositories), making it distinct from siblings like list_repositories or get_repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool to find repositories by name or other criteria.' While it doesn't list when not to use it, the context of sibling tools (list_repositories, get_repository) provides implicit guidance. Could be improved with direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that comments are added (mutation) and that inline comments require file_path and line_number. However, it does not mention authentication needs, rate limits, or what happens if the PR does not exist. More detail would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose, then explains use cases followed by parameter details. It is concise with no wasted sentences, though the parameter list could be more compact (e.g., bullet points). Overall, it is well-structured and readable.
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 has 6 parameters and no annotations, the description covers purpose, parameters, and return value. It mentions default behavior for workspace and repository. It lacks error handling or prerequisites but is complete for basic use. Output schema exists, so return description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains all 6 parameters, including defaults for repository and workspace and the optional nature of file_path and line_number. Since the input schema has 0% description coverage, this adds significant value. It does not specify types but provides enough context for usage.
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 adds a comment to a pull request, distinguishing between general comments and inline code comments. It uses a specific verb ('Add') and resource ('comment to a pull request'), and among siblings, it is distinct from tools like 'approve_pull_request' or 'request_changes'.
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 tells when to use the tool (adding feedback or discussion) and explains inline comment usage. However, it does not explicitly mention when not to use it or name alternative tools for related actions (e.g., requesting changes). This is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the default source branch but does not disclose behavior on existing branches, error handling, permissions, or side effects, leaving significant 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 brief with a clear purpose statement followed by a structured Args list. Every sentence adds value, and it is front-loaded with the core action.
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?
The description explains the tool's operation, defaults, and output, but lacks coverage of error conditions or prerequisites like repository existence and permissions, which are relevant for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that explains each parameter's purpose and defaults, adding substantial value beyond the schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new branch in a BitBucket repository' with specific verb and resource, and distinguishes from sibling tools like delete_branch, get_branch, and list_branches by focusing on creation.
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 says 'Use this tool when the user wants to create a new branch' and explains the default source branch, providing context without explicit exclusions or alternative tool naming.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return as a JSON object with commit info, but does not disclose behavior on error, permission requirements, or side effects. It offers adequate but not rich transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a usage paragraph and an Args section. It is concise with no wasted words, though it could be slightly more streamlined by integrating the usage guidance into the first sentence.
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 presence of an output schema (so return values need not be detailed), the description covers purpose, usage, and parameters adequately. It could mention error handling, but for a standard get operation it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description explains each parameter: branch_name is required, repository and workspace are optional slugs that default to the current context. This adds good meaning beyond the schema's basic type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific branch.' It uses a specific verb and resource, and distinguishes well from sibling tools like list_branches (list vs get) and create_branch.
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 says 'Use this tool when you need complete details about a branch, including its latest commit information.' This provides clear usage context, but it does not explicitly exclude scenarios or mention alternative tools for related tasks.
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 the return type ('JSON list of matching code locations with snippets') but does not mention any behavioral traits like rate limits, authentication needs, or side effects. For a read-only search, it 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized with a clear structure: a title line, usage statement, parameter list (Args), and return description (Returns). It is efficiently written without superfluous content, though slightly verbose in the parameter section.
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?
The description covers the essential aspects of the tool: parameter meanings, default behaviors, and return type. Given the output schema exists (though not detailed) and the tool's complexity is low, it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaningful explanations for each parameter (e.g., 'repository slug', 'uses current repository context' for defaults). This adds significant value beyond the raw schema, clarifying defaults and usage.
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 specifies 'search for code patterns in a BitBucket repository', which is a specific verb+resource combination. It differentiates from sibling tools like search_repositories and search_memories by focusing on code content within a repository.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool ('find specific code patterns, function names, or text') but does not explicitly mention when not to use it or provide alternative tools. The context of sibling tools offers implicit differentiation, but explicit exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It mentions slug behavior and defaults, but does not disclose permissions, uniqueness constraints, or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: purpose sentence, usage, Args list, Returns. Front-loaded and no unnecessary words.
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 5 parameters and presence of output schema, the description adequately covers creation details. Missing error conditions or prerequisites, but overall complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaningful context: explains each parameter, notes name is used as slug, and states defaults. This compensates well for the lack of schema documentation.
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 'Create a new repository in BitBucket', providing a specific verb-resource pair. It differentiates from sibling tools like delete_repository, update_repository, etc.
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 explicitly says 'Use this tool when the user wants to create a new repository.' It lacks explicit alternatives or when-not-to-use guidance, but the context makes the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it returns raw content as a string and mentions defaults for ref, workspace, repository, but does not disclose potential size limits, permissions, or error conditions. 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 concise: a one-line summary, a short use-case paragraph, a clear Args list, and a Return statement. Every sentence adds value, no redundancy. 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?
Given 4 parameters (1 required) and an output schema, the description covers the function well. It explains defaults, return type, and use cases. Minor gaps: no mention of error handling or file size limits. Mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: file_path, repository, workspace, ref, with defaults. This adds meaningful context beyond the schema, making parameter usage clear.
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 gets the raw content of a specific file from a BitBucket repository. It uses a specific verb ('Get') and resource ('file content'), differentiating it from siblings like get_repository_contents (list files) or search_code.
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 explicitly says 'Use this tool when you need to read the full content of a specific file' and gives examples (reviewing code, config files, docs). It does not specify when not to use or alternatives, but provides clear context for when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that it returns complete details but does not disclose behavioral traits such as being read-only, authentication requirements, or error handling. The description is adequate but lacks additional context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a front-loaded purpose statement, followed by well-structured Args and Returns sections. Every sentence adds value without 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?
Given an output schema exists, the description appropriately summarizes returns as 'JSON object with complete pull request details.' It covers parameter behavior sufficiently for a retrieval tool. Minor missing details (e.g., error handling) but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds meaning to all three parameters. It explains default behaviors: pr_id defaults to newest open PR, repository to current context, workspace to default. This provides useful guidance beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information about a specific pull request' with specific attributes like description, reviewers, and approval status. It distinguishes itself from sibling tools such as 'list_pull_requests' (listing) and 'get_pull_request_diff' (diff).
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 explains when to use this tool and provides default behaviors for each parameter (e.g., if pr_id not provided, returns newest open PR). It does not explicitly state when not to use or list alternatives, but the context is clear given the 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?
With no annotations, the description carries the full burden of behavioral disclosure. It clarifies the read-only nature (listing members) and default parameter behavior, but it lacks details on authentication requirements, rate limits, or potential errors. The mention of a JSON return provides some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a front-loaded purpose statement followed by usage guidance, parameter details, and return information. Every sentence adds value without redundancy, achieving high efficiency.
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?
The tool has a simple interface with one optional parameter and an output schema. The description adequately covers the parameter, default behavior, and return format. It could be improved by mentioning error conditions or permission requirements, but overall it is sufficiently complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description adds significant meaning by explaining 'workspace' as a 'Workspace slug' and specifying default behavior ('If not provided, uses the default workspace'). This goes beyond the schema definition.
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 'List all members in a BitBucket workspace', specifying the verb and resource. It distinguishes from sibling tools like 'search_workspace_users' by focusing on listing all members rather than searching for specific users, providing clear differentiation.
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 explains when to use the tool ('see all users who have access to a workspace') and its usefulness ('finding reviewers or understanding team membership'). It implies context but does not explicitly state when not to use it or list alternatives, which would be helpful for deeper 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 explains the action's purpose and that it returns a confirmation. But it lacks details on permissions, side effects, or whether changes are reversible, which are important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (under 100 words) and well-structured with a usage note and bulleted Args. It could be slightly more front-loaded but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and low schema coverage, the description covers the tool's purpose, parameters, and return value. It lacks error handling details but provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args section is essential. It explains each parameter's meaning (e.g., 'pr_id: Pull request ID') and optionality, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Request changes on a pull request' and explains it is for indicating changes are needed before approval. This distinguishes it from sibling tools like 'approve_pull_request' and 'add_pull_request_comment'.
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 advises to always include a comment explaining what needs to change, providing clear usage guidance. However, it does not explicitly contrast when to use this tool instead of alternatives like 'add_pull_request_comment'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default state filter (OPEN), default limit (10), and fallback context for repository/workspace. Lacks mention of error cases, pagination, or ordering, but for a simple list tool this is adequate. No annotations present, so description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with a clear opening sentence then structured Args section. Every sentence adds value, no fluff.
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 output schema exists (so return values need not be detailed), the description covers parameters, defaults, and filter options well. Could mention maximum limit or additional behavior like ordering, but overall sufficient for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter's purpose (repository slug, workspace slug, state filter with enumerated values, limit). Adds meaning beyond the schema's types and defaults, including contextual defaults.
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 'List pull requests in a BitBucket repository' with a specific verb and resource. It distinguishes from sibling tools like get_pull_request (single PR) and create_pull_request by implying a list operation, and adds default behavior context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides basic guidance ('Use this tool to see pull requests in a repository') and defaults, but does not explicitly differentiate from alternatives like get_pull_request for a single PR or mention when not to use it. More explicit comparisons would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the search scope (content and tags) and return format (JSON list). However, it does not mention edge cases like no results, pagination, or performance implications. The description is adequate but lacks depth for a read-only search 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 extremely concise: one sentence for purpose, one for usage context, a bullet list for parameters, and a line for return. Every sentence earns its place, and the structure is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, 1 required, output schema exists), the description covers all essential aspects: purpose, when to use, parameters with explanations, and return type. It is complete for an agent to correctly invoke the tool.
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 0%, but the description provides explicit explanations for each parameter: query, workspace, and repository. This adds meaning beyond the schema, which only shows types and defaults. The description clarifies what each parameter does, effectively compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches memories by keyword, specifying it searches content and tags. It distinguishes usage by providing a specific context: 'Use this before reviewing PRs or making suggestions to check for existing standards or learnings.' This makes the purpose distinct from sibling tools like 'list_memories' or 'get_relevant_memories'.
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 explicitly says when to use it: before reviewing PRs or making suggestions. It provides clear context, but does not explicitly mention when not to use or compare with alternatives like 'get_relevant_memories'. Nonetheless, it gives actionable 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?
No annotations provided, so description carries full burden. It discloses partial update behavior ('Only provide the parameters you want to change') and return type, but lacks details on prerequisites, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a header, a usage line, an Args list, and a Returns line. Every sentence adds value, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple update operation and presence of an output schema, the description covers partial updates, parameter details, and return value. It lacks mention of error handling or constraints but is sufficient for a basic update tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section with clear explanations for all four parameters (repository, description, is_private, workspace), adding significant meaning beyond schema types and titles.
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 updates repository settings in BitBucket, modifying metadata like description or visibility. It distinguishes from sibling tools (create, delete, get) by focusing on 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?
It explicitly says 'Use this tool to modify repository metadata', providing clear context. However, it does not mention when not to use it or name alternatives (e.g., for creating or deleting).
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?
Describes the action and return value, but with no annotations, it lacks details on side effects, persistence, or idempotency. Adequate but could be more thorough.
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?
Well-structured with a short main description, bulleted use cases, and clear Args section. Every sentence is informative and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage scenarios, parameter details, and return value. Given the complexity and output schema, it provides all necessary context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema coverage, the description compensates fully by explaining each parameter with examples and hints, such as listing category options and tag formatting, which adds significant 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 'Store a new memory/learning for future reference' and provides specific use cases, distinguishing it from related tools like search_memories or list_memories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (remember standards/patterns from PRs, code reviews, etc.) and lists common use cases. Does not mention when not to use or alternatives like remember_from_pr_comment, but still provides strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: auto-detection of branches, default reviewers, smart destination selection, and the option to close source branch. It does not mention side effects or destructive actions, but the description is sufficiently transparent.
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 moderately long but well-structured with a clear purpose statement, a workflow section, and parameter descriptions. It front-loads the main purpose. While it could be slightly more concise, the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 0% schema coverage, and no annotations, the description is thorough. It covers parameter meanings, defaults, and the return type. The workflow for adding reviewers adds contextual completeness, making it suitable for an agent to 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 description coverage is 0%, so the description must compensate. It includes an Args section that adds meaning: for source_branch (uses current git branch), destination_branch (defaults to 'development'), and reviewer_account_ids (comma-separated list from search_workspace_users). This adds significant value beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new pull request' and provides specific details about merging changes between branches. It distinguishes this tool from siblings like add_pull_request_comment or approve_pull_request by focusing on creation.
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 a clear workflow for adding reviewers and mentions auto-detection of source branch and smart destination selection. It lacks explicit when-not-to-use guidance but gives sufficient context for appropriate usage.
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 discloses key behavioral traits: it indicates the tool reads configuration (implied by 'get'), explains that reviewers are automatically added unless excluded, and notes default context usage for parameters. It does not mention permissions or error handling, but the behavior is adequately conveyed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear opening statement, a usage hint, and a structured Args section. Every sentence serves a purpose, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple read operation and the presence of an output schema, the description covers the essential aspects: what the tool does, when to use it, parameter details, and return format. It lacks error scenarios or advanced context, but it is complete enough for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates by explaining the purpose of each parameter ('Repository slug', 'Workspace slug') and their default behavior ('If not provided, uses current...context'). This adds significant value beyond the schema's basic type information.
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 default reviewers for a repository, with a specific verb and resource. It distinguishes itself from sibling tools by focusing solely on default reviewers.
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 explains when to use the tool ('to see which users are automatically added as reviewers when creating pull requests') and provides context about reviewer inclusion. However, it does not explicitly mention when not to use it or list alternatives.
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 provided, so description bears full burden. It correctly indicates the tool is read-only (get) and non-destructive. It clarifies the scope (both general and inline comments). Missing details like pagination or ordering, but overall transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences plus a minimal Args/Returns section. Every sentence provides useful information without redundancy. The structure separates purpose, usage, and parameter descriptions clearly.
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 list tool with an output schema, the description is thorough enough. It explains input parameters with defaults and context, and briefly describes what is returned (list of comments with content, authors, locations). Could mention ordering or pagination, but sufficient for typical use.
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 0%, but description adds value by explaining each parameter's purpose and default behavior (e.g., repository and workspace fallback to current context). This goes beyond the schema, which only has types and titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all comments on a pull request' with a specific verb and resource. It distinguishes from sibling tools like 'add_pull_request_comment' and 'get_pull_request' by specifying it retrieves comments, including both general and inline code review comments.
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 explicitly says 'Use this tool to review comments, feedback, and discussions on a pull request.' This provides clear usage context. While it doesn't explicitly list when not to use or alternatives, the sibling context and comments about inclusion of both comment types give adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly warns that deletion is destructive, requires confirm=true, and describes the return behavior (confirmation message or error if confirm not True). Additional details like irreversible effects or permission requirements are missing but the core behavior is covered.
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 well-structured: a short intro, a prominent warning, usage instructions, parameter list, and return info. Every sentence is meaningful and earns its place, with no redundant content.
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 destructive nature and presence of an output schema, the description provides essential context: the confirm requirement, default values for repository/workspace, and return type. It could be slightly enhanced by mentioning potential errors or prerequisites but is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description includes an 'Args' section that explains each parameter: branch_name, confirm (including the safety requirement), repository, and workspace. This adds significant meaning beyond the raw schema, compensating fully for the lack of 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 begins with a clear verb+resource statement: 'Delete a branch from a BitBucket repository.' It distinctly separates this from sibling tools like create_branch or get_branch by explicitly naming the action and resource.
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 explicitly states when to use: 'Use this tool only when the user explicitly requests to delete a branch and has confirmed the deletion.' It warns about the destructive nature and the confirm parameter but does not mention alternative tools for similar operations.
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?
The description prominently warns 'WARNING: This is a destructive operation that cannot be undone.' and explains the safety measure of the confirm parameter. With no annotations, it covers destructive nature and irreversible 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 well-structured with warning, usage guidance, args list, and return note. Every sentence adds value with no 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 destructive tool, it covers key concerns (irreversible, confirm required) and mentions return type. However, it lacks details on error cases or behavior with invalid inputs, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description carries full burden. It explains each parameter: repository slug, confirm must be true, workspace optional with default. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a repository from BitBucket' with a specific verb and resource. It distinguishes from sibling tools like create_repository and update_repository.
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 explicitly says 'Use this tool only when the user explicitly requests to delete a repository and has confirmed the deletion.' It provides clear context for when to use, though it does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses return format (JSON with branch name or error) and acknowledges git repository requirement. Lacks details on permissions or side effects but is adequate for a read-only 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?
Four concise sentences covering purpose, usage, and return value. No redundant information, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description covers usage context, return format, and error handling. Completely sufficient for this simple tool.
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?
No parameters exist, so schema coverage is 100%. Description adds meaning by explaining what the tool returns, which is absent from the empty schema. Baseline 4 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?
Description clearly states 'Get the current git branch name', distinguishing from sibling `get_branch`. Provides specific verb and resource with context of auto-detecting source branch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends use before creating pull requests to detect current branch. Does not mention when to avoid or alternatives like `get_branch` for other branches, but context is sufficient.
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 full burden. It states the tool returns a JSON object with user details and email addresses, implying a read-only operation. While it could explicitly mention being non-destructive or safe, the behavior is straightforward for a 'get' 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 concise, with a single paragraph and bullet points for use cases. It is front-loaded with the main purpose and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is an output schema (not shown), the description does not need to detail return structure. It adequately explains the tool's function and return type. The sibling tools are diverse, and this tool stands alone, so no additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 as per guidelines. The description clarifies that no input is needed and confirms the output context, adding meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the authenticated user's account information including email addresses. It uses a specific verb (Get) and resource (authenticated user's account information), and distinguishes itself from sibling tools that focus on repositories, pull requests, branches, etc.
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 explicitly lists when to use this tool (verifying account, getting email addresses, getting account_id for self-assignment). While it doesn't mention when not to use it, the context of sibling tools provides alternative options, and the use cases are concrete.
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 full burden. It discloses the return format (JSON list with branch names and target commit info) and implies a read-only operation. Additional details like pagination or rate limits could enhance transparency.
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 well-structured with a brief summary, clearly labeled args, and a returns section. It is concise and each sentence adds value.
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 simplicity of the tool and the presence of an output schema (not shown), the description provides essential info: purpose, parameters, and return structure. It could optionally mention ordering or behavior with many branches, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains all three parameters: repository, workspace, and limit, including defaults and behavior when omitted (e.g., using current repo/workspace). This adds significant value beyond the schema alone.
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 lists branches in a BitBucket repository, including additional details like names and latest commit information. It is distinct from sibling tools like get_branch (single branch) and create_branch (creation).
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 explicitly says 'Use this tool to see available branches in a repository,' providing clear context. It does not explicitly mention when not to use or alternatives, but the purpose is unambiguous.
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 fully handles disclosure. It states 'Returns the raw diff output,' which is accurate for a read operation. No side effects are mentioned, but none are expected.
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 brief (3 sentences plus parameter list) and front-loaded with purpose. No unnecessary words, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple operation, input schema with 3 parameters, and presence of an output schema, the description covers all necessary aspects: purpose, parameters, and return value. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a dedicated 'Args:' section that adds meaning beyond the input schema: it explains 'repository' and 'workspace' as slugs and notes default behavior when not provided. Since schema description coverage is 0%, this compensation is excellent.
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: 'Get the diff/changes for a pull request' and 'see what code changes are included in a pull request.' It uses a specific verb-resource pair and differentiates from sibling tools like get_pull_request and get_pull_request_comments.
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 includes 'Use this tool to see what code changes are included in a pull request,' providing clear usage context. However, it does not explicitly exclude when not to use it or list alternatives, though the sibling tool names imply the distinction.
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 provided, so description carries full burden. Clearly indicates a read operation ('Get detailed information'). No mention of destructive behavior, authorization, or rate limits, but sufficient for a retrieval 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?
Well-structured with sections (summary, usage, args, returns). No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, parameter descriptions, return value (JSON object with complete details). Output schema exists, so brief return description is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning: 'repository: Repository slug...' and 'workspace: Workspace slug. If not provided, uses the default workspace.' Fully compensates for missing 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?
Clearly states 'Get detailed information about a specific BitBucket repository.' Specifies resource (repository) and action (get details). Distinguishes from sibling tools like 'get_repository_contents' and 'list_repositories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this tool when you need full details about a repository,' providing clear context. Doesn't explicitly state when not to use it or name alternatives, but inference is straightforward.
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 provided, but description transparently states it returns a JSON object with directory listing or file contents. Mentions default ref (HEAD). Does not discuss side effects or auth, but as a read operation, it is sufficiently transparent.
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?
Highly concise: one opening sentence, bullet-style use cases, and structured Args block. No redundant information. Front-loaded with essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with 4 parameters, no schema descriptions, and no annotations. Covers all parameters, defaults, and return type. Output schema exists, so return details are complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that meaningfully explains all four parameters, including defaults and semantics (e.g., 'empty string for root', 'default: HEAD'). Fully compensates for lack of 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?
Clearly states 'Get file or directory contents from a BitBucket repository' with specific verb and resource. Explains use cases for browsing, viewing structure, and reading contents. Distinguishes from sibling get_file_content by covering both files and directories.
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 explicit context: 'Use this tool to browse repository contents, view file structure, or read file contents.' Mentions navigation to specific paths and refs. However, does not specify when not to use it or mention alternative tools like get_file_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: cache-first strategy, automatic caching of results, partial matching support, and the behavior when multiple matches are found. This goes beyond the basic schema information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~150 words) and well-structured: a one-sentence summary followed by caching info, use cases, parameter details, and return value. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and an output schema (not shown), the description covers all essential aspects: purpose, caching, use cases, parameter meanings, and return format. It is complete for a search tool of moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds rich context for all three parameters: 'query' supports partial matches, 'workspace' defaults to the default workspace, and 'check_memory_first' controls caching behavior. This is highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for users in a BitBucket workspace by name.' It specifies the verb (search), resource (users), and scope (workspace), distinguishing it from siblings like 'list_workspace_members' which lists all members without searching.
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 explicit use cases (adding reviewers, mentioning users, finding account IDs) and implies when to use it. However, it does not explicitly mention when not to use it or suggest alternatives like 'list_workspace_members' for listing all users.
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:

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

Score Badge

Copy to your README.md:

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

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/clikader/bitbucket-python-mcp'

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