Skip to main content
Glama
maxronner

@maxronner/tea-mcp

by maxronner
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

Server Quality Checklist

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

  • Latest release: v1.2.1

  • Disambiguation5/5

    Each tool targets a distinct resource and action: issues have list/view/close/reopen/create, PRs have list/view/checkout/create/approve/reject/merge, plus comment creation and repo view/list. No two tools overlap in purpose.

    Naming Consistency4/5

    Most tools follow a resource_action pattern (tea_issue_view, tea_pr_merge), but there are deviations: 'tea_prs_list' uses plural 'prs' while others use 'pr', and 'tea_create_comment' uses action_resource instead of resource_action.

    Tool Count5/5

    15 tools is well-scoped for a Git hosting server covering repositories, issues, pull requests, and comments. Each tool earns its place without bloat or redundancy.

    Completeness4/5

    Core workflows are covered: issue lifecycle (create, view, list, close, reopen), PR lifecycle (create, view, list, merge, approve, reject, checkout), and comments. Minor gaps include lack of update/edit operations for issues and PRs, and no repo creation or deletion, but these do not cause major dead ends.

  • Average 3.3/5 across 15 of 15 tools scored.

    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 is passing

  • This repository is licensed under MIT License.

  • This repository includes a README.md file.

  • No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.

    Tip: use the "Try in Browser" feature on the server page to seed initial usage.

  • Add a glama.json file to provide metadata about your server.

  • If you are the author, simply .

    If the server belongs to an organization, first add glama.json to the root of your repository:

    {
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}

    Then . Browse examples.

  • Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

  • Behavior2/5

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

    With no annotations provided, the description carries the full burden. It only states 'List pull requests' and does not disclose defaults like state=open, limit=30, or pagination behavior. No safety or side-effect information is given beyond the implicit read-only nature of listing.

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

    Conciseness5/5

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

    The description is a single sentence with no redundant words, making it perfectly concise. It is front-loaded with the action and resource, and the sentence earns its place.

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

    Completeness2/5

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

    For a tool with 3 parameters, no annotations, and no output schema, the description is too thin. It omits that repo can be overridden, that state defaults to open, and what the response contains. The schema fills some gaps, but the description should provide the surrounding context for correct invocation.

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

    Parameters2/5

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

    Schema description coverage is only 33% (repo has a description, limit and state do not). The tool description adds no parameter semantics, failing to explain limit constraints or allowed state values. It only hints at the repo parameter via 'current repository'.

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

    Purpose4/5

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

    The description uses the specific verb 'List' and identifies the resource as 'pull requests', with scope 'current repository'. This clearly distinguishes it from sibling tools like tea_issues_list and tea_pr_view. However, the phrase 'current repository' is slightly misleading since the repo parameter allows listing PRs from any specified repository.

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

    Usage Guidelines2/5

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

    The description provides no guidance on when to use this tool versus alternatives, and does not mention filtering options such as state or limit. There is no reference to tea_pr_view for viewing details or tea_issues_list for issues, leaving the agent to infer usage from the tool name and schema.

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

  • Behavior2/5

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

    No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (reopen) but does not disclose potential side effects, permissions required, behavior when the issue is already open, or error conditions. For a mutation tool, this is a minimal disclosure.

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

    Conciseness5/5

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

    The description is a single, concise sentence: 'Reopen a closed issue'. It is front-loaded and contains no unnecessary words, earning a perfect score for conciseness.

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

    Completeness2/5

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

    For a mutation tool with no annotations and no output schema, the description is too sparse. It lacks contextual information about when to use it, potential side effects, and how it relates to sibling tools. The schema covers parameters but not the operational context, making the description incomplete for an agent.

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

    Parameters3/5

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

    The input schema covers 100% of parameters (repo and index) with clear descriptions, so the description does not need to add much. The description adds no additional semantic detail beyond the schema, which already explains 'Issue number to reopen' and 'Repository path'. Baseline 3 applies.

    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 ('Reopen') and the resource ('a closed issue'), providing a specific verb+resource combination. While it implicitly differentiates from sibling tools like tea_issue_close, it does not explicitly mention alternatives or scope, so it falls short of a 5.

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

    Usage Guidelines2/5

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

    The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what it does without any contextual framing or mention of related tools like tea_issue_view or tea_issue_close.

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

  • Behavior2/5

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

    With no annotations provided, the description carries full burden. It only states the mutation action but does not disclose side effects, reversibility (e.g., reopening possible), permissions, or response behavior. Minimal transparency beyond the bare 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?

    The description is a single, efficient sentence with no wasted words. It is appropriately sized for a simple tool, though not as rich as some alternatives. It is concise without being a tautology.

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

    Completeness3/5

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

    Given the simple tool with only two schema-documented parameters and no output schema, the description adequately states the core action. However, it lacks any additional context about usage scenarios or side effects, leaving room for improvement.

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

    Parameters3/5

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

    Schema description coverage is 100% for both parameters (repo, index), each already clearly documented. The description adds no parameter-specific meaning, which aligns with the baseline of 3 when schema covers all parameters.

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

    Purpose5/5

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

    The description 'Close an issue' uses a specific verb and resource, clearly distinguishing it from sibling tools like tea_issue_reopen. It directly states the action performed without ambiguity.

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

    Usage Guidelines2/5

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

    There is no guidance on when to use this tool versus alternatives. It does not mention that it complements tea_issue_reopen or any prerequisites, making it purely descriptive with no contextual direction.

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

  • Behavior2/5

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

    With no annotations provided, the description carries full responsibility for disclosing behavioral implications. It does not mention authentication requirements, whether the operation is reversible, or what response can be expected. The only trait implied is the creation itself, which is already clear from the name.

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

    Conciseness5/5

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

    The description is a single sentence, immediately front-loaded with the action and object, with no filler words. It is appropriately concise for a simple create operation.

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

    Completeness2/5

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

    Despite the detailed schema, the description lacks crucial context: it does not mention what the tool returns (no output schema), any side effects, or prerequisites like authentication or repository detection. Given 8 parameters and zero annotations, this leaves the agent with gaps in understanding the full invocation context.

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

    Parameters3/5

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

    All 8 parameters are fully described in the schema (100% coverage), so the description does not need to add parameter details. It adds no new meaning beyond the schema, so the baseline of 3 is appropriate.

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

    Purpose5/5

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

    The description uses a specific verb ('Create') with a clear resource ('a new issue') and scopes it to 'the current repository.' This clearly distinguishes it from sibling tools that list, view, close, or reopen issues.

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

    Usage Guidelines2/5

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

    No guidance is provided on when to use this tool versus alternatives, such as tea_create_comment or tea_issue_close. The description only states what it does without specifying prerequisites or exclusions.

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

  • Behavior2/5

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

    There are no annotations provided, leaving the description to carry the full behavioral burden. It only states the action without disclosing side effects (e.g., whether approval is recorded, whether it affects merge permissions, whether it is reversible, or what happens to existing approvals). This is insufficient for a state-changing tool.

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

    Conciseness5/5

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

    The description is a single, front-loaded sentence with zero filler or repetition. It is as concise as possible while still conveying the core action.

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

    Completeness2/5

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

    Given the lack of annotations and output schema, the description is too terse for a mutation tool. It omits important context such as the effect of approval on the pull request workflow, whether a comment is expected, and how the approval relates to merging or rejecting.

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

    Parameters3/5

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

    The input schema already covers all 3 parameters with descriptions (100% coverage), so the baseline is 3. The description adds no additional parameter-level context, but the schema is sufficient.

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

    Purpose5/5

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

    The description uses a specific verb ('Approve') with a clear resource ('a pull request'), which directly distinguishes it from sibling tools like tea_pr_reject and tea_pr_merge. It is unambiguous and action-oriented.

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

    Usage Guidelines2/5

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

    The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. An agent cannot tell whether approval should precede a merge or how it differs from rejection or commenting.

    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?

    There are no annotations, so the description carries full responsibility for disclosing behavioral traits. 'Merge a pull request' implies mutation but does not state that merging is a destructive write operation, may require special permissions, or that it triggers CI/CD or permanently alters repository history. It also doesn't mention reversibility or whether a custom title/message can be supplied (though that's in the schema). This is a significant transparency gap for a state-changing tool.

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

    Conciseness5/5

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

    The description is a single, short sentence that immediately states the action and target. It contains no filler, no restatement of the tool name, and no redundant information. It is appropriately sized for the tool's straightforward purpose, earning every word.

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

    Completeness2/5

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

    This is a mutation tool with no annotations, no output schema, and a description that only states the default action. The schema documents parameters, but the description does not explain side effects, success/failure behavior, or how this relates to the PR lifecycle (e.g., should be used after approvals, not on closed PRs). The agent is left without enough context to use the tool safely or decide when it's applicable.

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

    Parameters3/5

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

    The input schema provides descriptions for all 5 parameters (repo, index, style, title, message), giving 100% coverage. The description adds no parameter-specific meaning, so it relies entirely on the schema. Since schema coverage is high (>80%), the baseline is 3, and the description does not degrade or improve that score.

    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 'Merge a pull request' uses a specific verb ('merge') and a clear resource ('a pull request'). It unambiguously identifies the tool's action and distinguishes it from sibling tools like tea_pr_approve, tea_pr_reject, and tea_pr_create, which perform other PR-related actions.

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

    Usage Guidelines2/5

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

    No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., PR must be open, tests must pass) or situations where merging is not appropriate. The tool's purpose is clear but the description gives no usage context, unlike a well-documented tool that would state 'use this after approval' or 'do not use for draft PRs'.

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

  • Behavior2/5

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

    No annotations are provided, so the description must disclose behavioral traits. It only states 'List issues' and does not mention defaults (e.g., state, limit), pagination, return format, or the read-only nature of the 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 a single, short sentence with no unnecessary words. It earns its place by stating the core purpose clearly, making it highly concise and well-structured.

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

    Completeness2/5

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

    Given the tool has 5 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain parameter semantics or what the response looks like, making it incomplete for correct invocation.

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

    Parameters2/5

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

    Schema description coverage is only 20% (only 'repo' is described). The description adds no detail about 'limit', 'state', 'author', or 'labels', leaving these parameters semantically under-specified for an agent.

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

    Purpose5/5

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

    The description uses a specific verb 'List' and resource 'issues', and scopes to 'the current repository'. It clearly distinguishes from sibling tools like tea_issue_view (single issue) and tea_prs_list (pull requests).

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

    Usage Guidelines3/5

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

    The description implies usage when one needs to enumerate issues in a repository, but it gives no explicit guidance on when to use this versus alternatives like tea_issue_view, nor does it mention exclusions or prerequisites.

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

  • Behavior2/5

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

    No annotations are provided, so the description carries the full burden of disclosing behavior. It only says 'List', implying a read operation, but adds no details about pagination, rate limits, or how the optional parameters affect results. The statement adds minimal value beyond the tool name.

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

    Conciseness5/5

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

    The description is a single, front-loaded sentence with no wasted words. It clearly states the core purpose without redundancy, making it highly concise and well-structured.

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

    Completeness2/5

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

    Given the presence of optional parameters and absence of an output schema, the description should explain how params affect results or what the response contains. It does neither, making it incomplete for an agent to effectively use the tool.

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

    Parameters1/5

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

    Schema description coverage is 0%, and the description does not mention either `type` or `limit` parameters. It fails to add any contextual meaning to the schema, leaving the agent to infer parameter usage from the schema alone. This is a significant gap.

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

    Purpose5/5

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

    The description clearly specifies the verb 'List' and resource 'repositories you have access to', distinguishing it from sibling tools like tea_repo_view (single repo) and tea_issues_list (issues). It conveys both action and scope concisely.

    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 states the primary use case: listing accessible repositories. It provides clear context for when to use the tool, though it doesn't mention exclusions or alternatives. For a simple list operation, this is adequate.

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

  • Behavior2/5

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

    No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It does not mention that checking out a pull request locally likely modifies the local git working directory, creates branches, or could conflict with existing branches. This is a significant gap for a mutating 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 a single sentence, front-loaded with the essential action and resource. There is zero wasted wording, making it highly concise and easy to parse.

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

    Completeness2/5

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

    Given the tool's mutating nature (local git state), the lack of annotations and output schema, and only a one-line description, the tool is under-specified. It does not explain what 'checkout' entails (e.g., branch creation, potential conflicts), which is important context for an agent using this tool correctly.

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

    Parameters3/5

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

    Schema coverage is 100%: the schema already describes 'repo' as the repository path or slug with a default, and 'index' as the pull request number. The description adds no parameter-specific meaning beyond that, so the baseline of 3 applies.

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

    Purpose5/5

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

    The description 'Checkout a pull request locally' clearly states the action (checkout) and the resource (a pull request), with a specific scope (locally). It distinguishes itself from sibling tools like tea_pr_view or tea_pr_merge, which perform different operations on pull requests.

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

    Usage Guidelines3/5

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

    The description implies that this tool is used when one wants to check out a pull request locally, but it does not explicitly state when to use it versus alternatives or mention any prerequisites or exclusions. The context of sibling PR tools suggests it is the only checkout operation, but no explicit guidance 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?

    With no annotations available, the description carries the full burden of disclosing behavior. It only states the action 'request changes' without mentioning side effects (e.g., PR status update, notifications), permissions required, or reversibility. This is insufficient for a mutation tool.

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

    Conciseness5/5

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

    The description is a single, direct sentence with no redundant wording. It earns its place by clearly stating the action and resource, though it could benefit from additional behavioral detail.

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

    Completeness2/5

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

    Given the lack of annotations, output schema, and behavioral details, the description is incomplete. It does not explain the result of the operation, any prerequisites, or the impact on the PR workflow, which an AI agent would need to invoke the tool safely.

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

    Parameters3/5

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

    All three parameters (repo, index, reason) have descriptions in the schema, and the schema coverage is 100%. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

    Purpose5/5

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

    The description uses a specific verb ('request changes') and identifies the resource ('a pull request'), clearly distinguishing it from sibling tools like tea_pr_approve and tea_pr_merge. The tool name 'tea_pr_reject' aligns with the description, reinforcing the purpose.

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

    Usage Guidelines3/5

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

    The description provides no explicit guidance on when to use this tool instead of alternatives like tea_pr_approve or tea_pr_merge. The verb 'request changes' implies usage in code review contexts when modifications are needed, but no exclusions or conditions are stated.

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

  • Behavior2/5

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

    No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It only states the core action without mentioning side effects, permissions, authentication needs, or return behavior. For a mutation tool, this is a significant gap.

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

    Conciseness5/5

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

    The description is a single, clear sentence that immediately conveys the tool's purpose. There is no wasted verbiage, and it is well-structured for fast parsing.

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

    Completeness3/5

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

    The description is minimal but the schema fully documents parameters. However, with no annotations and no output schema, the description does not clarify what happens after a comment is added (e.g., return value, possible errors). For a simple mutation tool, this is an acceptable but not complete level of context.

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

    Parameters3/5

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

    The input schema has 100% coverage, providing descriptions for body, repo, and index. The description does not add any parameter semantics beyond what the schema already states. The baseline score of 3 applies here.

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

    Purpose5/5

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

    The description clearly states the action ('Add a comment') and the target resource ('issue or pull request'). This distinguishes it from sibling tools like tea_issue_view, tea_issue_close, and tea_pr_create, none of which handle comments. The purpose is unambiguous and specific.

    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 implicitly indicates when to use the tool (whenever a comment needs to be added), but it does not explicitly mention alternatives or exclusions. Since there is no sibling comment tool, the usage context is clear enough, but the guidance is not explicit as per the rubric.

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

  • Behavior2/5

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

    With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'view' implies a read-only operation, but it does not disclose authentication needs, error behavior, or what 'details' includes. No additional context is given beyond the generic verb, leaving the agent to guess about side effects or return behavior.

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

    Conciseness5/5

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

    The description is a single, front-loaded sentence that states the verb and resource immediately. It contains zero redundant words and is appropriately sized for a simple view 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?

    The tool is simple with two parameters and no output schema, so the description is functional but lacks return-value details or constraints beyond the schema. It does not specify what 'details' means or any edge cases, making it adequate but not fully complete.

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

    Parameters3/5

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

    The input schema covers 100% of parameters with descriptions for both 'repo' and 'index'. The tool description adds no extra meaning beyond the schema, so the baseline of 3 applies. The schema already explains the parameters adequately.

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

    Purpose5/5

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

    The description uses a specific verb 'view' with a resource 'pull request' and scope 'specific', clearly distinguishing it from sibling tools like tea_prs_list, tea_pr_create, tea_pr_merge, and other mutations. It precisely states what the tool does without ambiguity.

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

    Usage Guidelines3/5

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

    The description implies usage when needing details of a specific pull request, but it does not explicitly state when to choose this tool over alternatives or mention exclusions. Sibling tools exist for listing, creating, merging, etc., but no guidance is provided on when to use this tool vs them.

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

  • Behavior2/5

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

    No annotations are provided, so the description carries full burden for behavioral disclosure. The description only says 'View' which implies a read operation, but does not disclose what details are returned, whether it requires specific permissions, rate limits, or other behaviors. For a tool with no annotations, this is a significant gap.

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

    Conciseness5/5

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

    The description is a single, clear, front-loaded sentence. Every word earns its place, and there is no wasted or repetitive 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 tool's low complexity (2 parameters, no nested objects, no output schema), the description is reasonably complete. It clearly states the action and target. While it does not enumerate return fields, the verb 'view' implies retrieval of issue details, which is adequate for a simple read tool.

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

    Parameters3/5

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

    Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema: it says 'specific issue' but does not clarify that 'index' is the issue number (already in schema) or any additional parameter nuances. No extra value provided.

    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 'View details of a specific issue' clearly identifies the verb (view), resource (issue), and distinguishes it from sibling tools like tea_issues_list (which lists issues) and mutation tools like tea_issue_close. The word 'specific' correctly signals this is for a single issue, not a collection.

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

    Usage Guidelines3/5

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

    The description implies usage: when you need to see details of one issue, use this tool. However, it does not explicitly state when not to use it (e.g., for listing issues) or mention alternatives such as tea_issues_list. No exclusions or context beyond the basic purpose.

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

  • Behavior3/5

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

    With no annotations provided, the description carries the full burden of behavioral disclosure. 'View details' implies a read-only operation, but the description does not disclose other behaviors such as default repository handling (though the schema parameter description does mention it) or error conditions. It is minimally transparent but not misleading.

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

    Conciseness4/5

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

    The description is a single, concise sentence with no wasted words—it is efficient and front-loaded. However, it is extremely terse, which may limit the context provided, but for a simple tool this level of brevity is acceptable.

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

    Completeness3/5

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

    For a simple tool with one optional parameter and no output schema, the description states the core function but does not explain what 'details' are included or how the default repository is resolved (though that is in the parameter schema). It is adequate for basic tool selection but lacks richness.

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

    Parameters3/5

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

    The input schema has 100% parameter description coverage; the 'repo' parameter is well-documented with format and default behavior. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 applies.

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

    Purpose5/5

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

    The description uses the specific verb 'view' and identifies the resource as 'repository', clearly differentiating it from sibling tools like tea_issue_view and tea_pr_view. It unambiguously states what the tool does without any misleading or vague language.

    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?

    No explicit when-to-use or alternative tool guidance is provided. The usage is implied by the tool name and description: if you need to view repository details, this is the tool. However, there is no mention of when to prefer this over tea_repos_list or how it relates to other view 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 burden of behavioral disclosure. It states the primary effect (creating a PR) and introduces a preview mode that avoids creation, which is useful. However, it does not disclose auth requirements, failure modes, or what happens after creation (e.g., return value or side effects on branches).

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

    Conciseness5/5

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

    The description is a single sentence that is front-loaded with the action ('Create') and resource ('pull request'), and includes the key optional behavior. Every word earns its place with no padding.

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

    Completeness3/5

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

    Given the complexity of 9 parameters and no output schema or annotations, the description is minimal. It mentions the essential preview feature but leaves out context about how the tool behaves in detail, such as required parameters beyond title, how defaults work, or what a successful response looks like. It is adequate but not rich enough for a tool of this complexity.

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

    Parameters3/5

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

    Schema description coverage is 100%, so the baseline is 3. The schema already documents all 9 parameters with clear descriptions. The description does not add parameter-specific semantics beyond the preview mode, which is already covered by the 'preview' param default. No additional value.

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

    Purpose5/5

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

    The description clearly states the tool's primary action: 'Create a new pull request'. This is a specific verb + resource that distinguishes it from sibling tools like tea_prs_list, tea_pr_view, and tea_pr_merge. The optional preview mode is also mentioned, adding clarity without ambiguity.

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

    Usage Guidelines4/5

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

    The description implies use for creating pull requests and mentions the optional preview mode for reviewing changes first. It provides clear context for when to use this tool, but it does not explicitly state when not to use it or name alternative tools for other PR operations (e.g., merging, approving).

    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

tea-mcp MCP server

Copy to your README.md:

Score Badge

tea-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/maxronner/tea-mcp'

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