Provides tools for interacting with GitHub's API, enabling operations such as listing repositories, creating issues, managing pull requests, and accessing user or repository data.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-server list my GitHub repositories"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
#MCP Server
Production-ready TypeScript Model Context Protocol (MCP) server exposing utility, GitHub, and Microsoft Teams tools over stdio.
Clean MCP server baseline for internal automation and integrations
GitHub and Microsoft Teams operational tooling in a single service
Strict TypeScript setup and minimal runtime surface
Related MCP server: Basic MCP Server
echo
get_time
github_status
github_authenticated_user
github_list_repos
github_create_issue
github_list_issues
github_get_file
github_create_pull_request
github_request
teams_send_message (webhook)
teams_send_card (adaptive card webhook)
teams_graph_status (Graph API)
teams_send_dm (Graph API)
Node.js 20+
npm 10+
cd mcp-server
npm install
copy .env.example .envPopulate .env before running.
GITHUB_TOKEN
TEAMS_WEBHOOK_URL
TEAMS_TENANT_ID
TEAMS_CLIENT_ID
TEAMS_CLIENT_SECRET
npm run dev — development mode with tsx
npm run build — compile to dist/
npm run start — run compiled server
npm run clean — remove dist/
npm run inspect — open MCP inspector
Development:
npm run devBuild + run:
npm run build
npm run startMCP stdio command:
node dist/index.jsDo not commit .env or secrets
Use least-privilege credentials for GitHub and Microsoft Graph
Review SECURITY.md before production use
See CONTRIBUTING.md and CODE_OF_CONDUCT.md.
Distributed under the MIT License. See LICENSE.
Returns exactly the text you send
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to echo |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description discloses basic behavior (echoes input) but omits any mention of safety, idempotency, or whether any transformations occur. For a trivial tool this is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core functionality with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple echo tool with no output schema, the description sufficiently covers the tool's purpose and behavior. No critical gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter 'text' as 'Text to echo'. The description adds no further semantic detail, but with 100% schema coverage, this is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Returns exactly the text you send' uses a specific verb ('returns') and resource ('the text you send'), clearly distinguishing it from sibling tools like get_time or github_*.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use echo versus other tools, nor any prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the current server time in ISO format
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 transparently states the output is ISO format. However, it could mention idempotency or lack of side effects, which are expected for a read-only tool. Still, it sufficiently discloses behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words. Efficiently communicates the tool's purpose and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description is sufficient. It provides the key information (what and format). Could mention synchronous nature, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (schema coverage 100%), so no additional parameter description is needed. Baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the current server time in ISO format. It uses a specific verb ('returns') and specifies the resource and format. No sibling tools are similar, so differentiation is not required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (when needing current time), but provides no explicit guidance on when not to use or alternatives. For a simple tool, this is adequate but lacks proactive context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the currently authenticated GitHub account
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates a read operation but lacks details beyond the obvious, such as authentication requirements (implicit), rate limits, or what constitutes 'GitHub account' (e.g., profile fields).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no extraneous information. Every word is necessary and adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and does not specify the return format or fields (no output schema). For a simple tool, this may suffice, but more detail on what the account object contains would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params), and the input schema fully covers this (100% coverage). According to guidelines, 0 params baseline is 4; no additional param info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and the specific resource 'currently authenticated GitHub account', making the purpose unambiguous. It distinguishes from sibling tools like github_list_repos or github_list_issues, which have different scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The utility is implied (get user info), but there is no mention of when not to use it or comparison to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a GitHub issue in a repository
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Issue body | |
| repo | Yes | Repository name | |
| owner | Yes | Repository owner, e.g. Ezzeay | |
| title | Yes | Issue title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure, but it only states the action without mentioning side effects, idempotency, authentication requirements, or whether the tool returns the created issue. This is insufficient for an agent to understand the implications of calling this tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no extraneous words. It is appropriately sized for a simple creation tool, though it could be slightly expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and 4 parameters, yet the description does not explain return values, error handling, or the expected outcome. It fails to provide a complete picture for an agent, especially given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the baseline is 3. The description does not add any additional meaning beyond what is already in the schema; it merely restates the action. No extra context for parameters like 'body' is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and resource ('a GitHub issue in a repository'), which is specific enough to distinguish from sibling tools like github_list_issues or github_create_pull_request. However, it does not elaborate on scope or context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, such as when to create an issue vs. a pull request. There are no prerequisites or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Opens a pull request on a GitHub repository
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | Branch to merge into (e.g. main) | |
| body | No | ||
| head | Yes | Branch to merge from | |
| repo | Yes | ||
| owner | Yes | ||
| title | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behaviors but only states the action without mentioning side effects (e.g., creating a PR triggers checks, comments) or authentication requirements. Critical safety and operation details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is brief but omits essential information. Conciseness should preserve completeness; here it sacrifices utility for brevity, making it under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (5 required), no output schema, and no annotations, the description is severely incomplete. It fails to convey return values, error scenarios, or relationships to other GitHub tools, leaving major gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 33% of parameters have schema descriptions (base and head). The tool description adds no extra meaning to parameters beyond stating the action, leaving the agent to infer semantics from param names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'opens' and the resource 'pull request on a GitHub repository'. It effectively distinguishes from sibling tools like github_create_issue or github_get_file, though it could be more specific about the context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., github_request for raw API calls) or prerequisites (e.g., existing repository, branch availability). The lack of context leaves the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads a file from a GitHub repository and returns its content as text
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Branch, tag or commit SHA (default: repo default branch) | |
| path | Yes | File path in the repo, e.g. src/index.ts | |
| repo | Yes | ||
| owner | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should fully disclose behavioral traits. It only implies a read operation but does not explicitly state that no modifications occur, missing authentication needs, rate limits, or error responses. The description falls short of necessary transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action. Every word is purposeful, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 4 parameters, no output schema, and no annotations, the description is too sparse. It does not cover error handling, file size limits, encoding, or what happens when the file does not exist. More context is needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: parameters 'ref' and 'path' have descriptions, while 'owner' and 'repo' do not. The tool description adds no extra meaning beyond the schema, but the missing parameters (owner, repo) are self-explanatory from the tool's name and context, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'reads', the resource 'file from a GitHub repository', and the outcome 'returns its content as text'. It distinguishes the tool from siblings like github_create_issue or github_request, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives. No when-to-use or when-not-to-use information is provided, and no mention of prerequisites or context that would help an agent decide between this and sibling tools like github_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists open issues for a given repository
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | ||
| owner | Yes | ||
| state | No | open | |
| per_page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description adds no behavioral details beyond the action. It does not mention pagination (per_page), error handling, authentication requirements, or rate limits. The schema provides some defaults but the description itself is silent on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient for reading. However, it sacrifices necessary detail, making it less effective. It is not overly verbose but could be more informative without length increase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters, the description is incomplete. It does not explain the return format, pagination behavior, ordering, or error responses. The agent lacks critical context for using the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only implies owner and repo parameters via 'for a given repository'. It does not explain state or per_page semantics. Since schema coverage is 0%, the description should compensate but fails to add meaning beyond what the schema structure provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists issues for a repository, with the verb 'lists' and resource 'issues'. However, it specifies 'open issues' as default, which is accurate but may mislead if the state parameter overrides it. It distinguishes from siblings by indicating a read operation on issues, unlike create or pull request tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like github_request or other issue-related tools. The sibling tools list is given but lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists repositories for the authenticated GitHub user
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| per_page | No | ||
| visibility | No | Repository visibility filter | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fails to disclose behavioral traits such as pagination, authentication requirements, or rate limits. Only states it lists for the authenticated user.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, single sentence with no extraneous text. Front-loaded with core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three optional parameters (pagination, visibility) and no output schema, the description lacks essential context like pagination behavior, defaults, or response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (visibility parameter documented). Tool description does not explain any parameters, so it adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'lists' and resource 'repositories' for the authenticated GitHub user. Distinguishes from sibling tools like 'github_list_issues'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or alternatives. Does not specify prerequisites or context for using this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a raw authenticated request to GitHub REST API. Use with caution.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | REST path like /repos/{owner}/{repo} | |
| method | Yes | ||
| paramsJson | No | Optional JSON object string for request parameters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions authentication and caution but omits details about rate limits, error handling, destructiveness, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no wasted words, and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It lacks guidance on response format, error behavior, permissions, and appropriate use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67% (two of three parameters have descriptions). The tool description adds no extra meaning beyond what is in the schema. The baseline for this coverage level is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends a raw authenticated request to the GitHub REST API, which distinguishes it from sibling tools that perform specific operations like listing issues or creating pull requests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use with caution' but does not explicitly explain when to use this tool versus the more specific sibling tools (e.g., github_list_issues, github_create_issue). No when-not or alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether GitHub token is loaded and authentication works
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It adequately states the tool performs a check (read operation) but does not mention side effects or error behavior. For a simple check, this is minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb and resource. No wasted words; highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no parameters, no output schema, and a straightforward purpose. The description completely covers the tool's function given its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description adds no parameter info because none exist. Baseline 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'checks' and identifies resource 'GitHub token/authentication'. Clearly distinguishes from sibling tools like github_authenticated_user, which retrieves user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., github_authenticated_user). No explicit context for when it should be invoked or when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether Microsoft Graph credentials are configured and working
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It indicates a read-only check but does not disclose potential outcomes, error behavior, or what 'working' entails. Adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, directly stating the purpose. No fluff, perfectly concise for a simple health check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks details about return values or success criteria. Since there is no output schema, some indication of what the agent can expect would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description correctly does not add parameter information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Checks' and the resource 'Microsoft Graph credentials' with scope 'configured and working'. It is specific and distinguishes from sibling tools like teams_send_message or github_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like github_status. It does not specify prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a rich Adaptive Card message to a Teams channel (title + body + optional link)
| Name | Required | Description | Default |
|---|---|---|---|
| body | Yes | Card body text | |
| title | Yes | Card title | |
| link_url | No | Optional action button URL | |
| link_label | No | Label for the action button |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the action without disclosing behavioral traits like permissions needed, whether the operation is destructive, rate limits, or error conditions. Minimal value added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence delivers core information without waste. Structure is front-loaded, presenting verb and key components efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks explanation of what an Adaptive Card is, how the channel is specified (likely from context), or return value/error handling. For a messaging tool with 4 parameters and no output schema, more context is needed for an AI agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters documented. Description adds context that link_url and link_label form an action button, which slightly enriches the schema. Meets baseline expectations but does not exceed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sends a rich Adaptive Card to a Teams channel with title, body, and optional link. However, it does not explicitly distinguish from siblings like teams_send_message for plain text, relying on the mention of 'Adaptive Card' to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 teams_send_dm or teams_send_message. No context on prerequisites, target channel identification, or scenarios where Adaptive Cards are preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a direct message (DM) to a specific Teams user by their email address
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Message text to send | |
| recipient_email | Yes | Email of the Teams user to DM |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the action (sends) but does not disclose potential side effects, authentication requirements, rate limits, or error handling (e.g., what if the user doesn't exist). Minimal value added beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler. All words are functional and the purpose is front-loaded. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema), the description is adequate but minimal. It lacks mention of return values, success/failure responses, or error conditions. Could be improved with brief behavioral notes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds no extra detail beyond what is already in the schema; it repeats 'by their email address' but does not provide additional semantics like formatting or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (sends), resource (direct message), and target (specific Teams user by email). It effectively distinguishes from sibling tools like teams_send_message and teams_send_card by explicitly mentioning DM.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., teams_send_message for channels). No prerequisites or exclusions mentioned, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sends a plain text message to a Microsoft Teams channel via incoming webhook
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Message text to send to Teams |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose all behavioral characteristics. It mentions 'via incoming webhook' but omits details like webhook configuration, rate limits, character limits, or error handling. The 'plain text' constraint is noted but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that immediately communicates the action and resource. Every word is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the action and parameter format. However, it lacks context about prerequisites (e.g., needing a webhook URL) and behavioral details expected from a tool with no annotations. Still adequate for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by specifying 'plain text' as the message format, which goes beyond the schema's 'Message text' description. This clarifies that rich formatting is not supported.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: sending a plain text message to a Teams channel via webhook. It specifies the resource and method, but does not explicitly differentiate from sibling tools like 'teams_send_card' or 'teams_send_dm' which send different content types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Given siblings for sending cards or direct messages, the description offers no criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a distinct function: utilities (echo, get_time), GitHub operations (create, list, read, status), and Teams messaging (send, status). The raw github_request is a fallback, but its distinct purpose is clear.
Tools use three different prefixes (none, github_, teams_), and within each, naming is mixed: verb_noun (create_issue, send_message) vs. noun-like (authenticated_user, status). The pattern is not fully consistent.
14 tools cover three distinct domains (utilities, GitHub, Teams) without being overwhelming. Each tool serves a clear purpose, and the count feels well-scoped for a multi-service integration.
For GitHub, common operations are present but missing updates/deletes and PR merging. For Teams, only sending is available (no reading, listing). The utilities are minimal. Notable gaps exist, but core workflows are covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that let you interact with Cycloid.io Internal Development Portal and Platform
A TypeScript MCP server for Home Assistant, enabling programmatic management of entities, automati…
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A simple Typescript MCP server built using the official MCP Typescript SDK and smithery/cli. This…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Ezzeay/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
