Skip to main content
Glama
Tiberriver256

Azure DevOps MCP Server

get_me

Retrieve the authenticated user's details including ID, display name, and email from Azure DevOps.

Instructions

Get details of the authenticated user (id, displayName, email)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • Main handler function for the get_me tool. Calls Azure DevOps Profile API to get authenticated user info (id, displayName, email). Throws if not Azure DevOps Services URL.
    export async function getMe(connection: WebApi): Promise<UserProfile> {
      try {
        if (!isAzureDevOpsServicesUrl(connection.serverUrl)) {
          throw new AzureDevOpsValidationError(
            'The get_me profile endpoint is only available for Azure DevOps Services',
          );
        }
    
        const baseUrls = resolveAzureDevOpsBaseUrls(connection.serverUrl);
        const organization = baseUrls.organization;
    
        if (!organization) {
          throw new AzureDevOpsValidationError(
            'Could not extract organization from Azure DevOps Services URL',
          );
        }
    
        // Get the authorization header
        const authHeader = await getAuthorizationHeader();
    
        // Make direct call to the Profile API endpoint
        // Note: This API is in the vssps.dev.azure.com domain, not dev.azure.com
        const response = await axios.get(
          `https://vssps.dev.azure.com/${organization}/_apis/profile/profiles/me?api-version=7.1`,
          {
            headers: {
              Authorization: authHeader,
              'Content-Type': 'application/json',
            },
          },
        );
    
        const profile = response.data;
    
        // Return the user profile with required fields
        return {
          id: profile.id,
          displayName: profile.displayName || '',
          email: profile.emailAddress || '',
        };
      } catch (error) {
        // Handle authentication errors
        if (
          axios.isAxiosError(error) &&
          (error.response?.status === 401 || error.response?.status === 403)
        ) {
          throw new AzureDevOpsAuthenticationError(
            `Authentication failed: ${error.message}`,
          );
        }
    
        // If it's already an AzureDevOpsError, rethrow it
        if (error instanceof AzureDevOpsError) {
          throw error;
        }
    
        // Otherwise, wrap it in a generic error
        throw new AzureDevOpsError(
          `Failed to get user information: ${error instanceof Error ? error.message : String(error)}`,
        );
      }
    }
  • Helper function that constructs the authorization header using either PAT (Basic) or Azure Identity/Azure CLI (Bearer) authentication.
    async function getAuthorizationHeader(): Promise<string> {
      try {
        // For PAT authentication, we can construct the header directly
        if (
          process.env.AZURE_DEVOPS_AUTH_METHOD?.toLowerCase() === 'pat' &&
          process.env.AZURE_DEVOPS_PAT
        ) {
          // For PAT auth, we can construct the Basic auth header directly
          const token = process.env.AZURE_DEVOPS_PAT;
          const base64Token = Buffer.from(`:${token}`).toString('base64');
          return `Basic ${base64Token}`;
        }
    
        // For Azure Identity / Azure CLI auth, we need to get a token
        // using the Azure DevOps resource ID
        // Choose the appropriate credential based on auth method
        const credential =
          process.env.AZURE_DEVOPS_AUTH_METHOD?.toLowerCase() === 'azure-cli'
            ? new AzureCliCredential()
            : new DefaultAzureCredential();
    
        // Azure DevOps resource ID for token acquisition
        const AZURE_DEVOPS_RESOURCE_ID = '499b84ac-1321-427f-aa17-267ca6975798';
    
        // Get token for Azure DevOps
        const token = await credential.getToken(
          `${AZURE_DEVOPS_RESOURCE_ID}/.default`,
        );
    
        if (!token || !token.token) {
          throw new Error('Failed to acquire token for Azure DevOps');
        }
    
        return `Bearer ${token.token}`;
      } catch (error) {
        throw new AzureDevOpsAuthenticationError(
          `Failed to get authorization header: ${error instanceof Error ? error.message : String(error)}`,
        );
      }
    }
  • Schema definition for get_me tool - an empty object (no parameters required), using Zod validation.
    import { z } from 'zod';
    
    /**
     * Schema for the get_me tool, which takes no parameters
     */
    export const GetMeSchema = z.object({}).strict();
  • Tool registration definition - registers 'get_me' with its description and JSON schema.
    export const usersTools: ToolDefinition[] = [
      {
        name: 'get_me',
        description:
          'Get details of the authenticated user (id, displayName, email)',
        inputSchema: zodToJsonSchema(GetMeSchema),
      },
    ];
  • Request routing: isUsersRequest checks if the tool name is 'get_me', and handleUsersRequest dispatches to the getMe function.
    export const isUsersRequest: RequestIdentifier = (
      request: CallToolRequest,
    ): boolean => {
      const toolName = request.params.name;
      return ['get_me'].includes(toolName);
    };
    
    /**
     * Handles users feature requests
     */
    export const handleUsersRequest: RequestHandler = async (
      connection: WebApi,
      request: CallToolRequest,
    ): Promise<{ content: Array<{ type: string; text: string }> }> => {
      switch (request.params.name) {
        case 'get_me': {
          const result = await getMe(connection);
          return {
            content: [{ type: 'text', text: JSON.stringify(result, null, 2) }],
          };
        }
        default:
          throw new Error(`Unknown users tool: ${request.params.name}`);
      }
    };
Behavior3/5

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

No annotations provided, so the description carries full burden. It implies a read-only operation ('Get details') but does not disclose authentication requirements, rate limits, or potential side effects. For a simple read tool, it 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.

Conciseness5/5

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

The description is a single concise sentence that front-loads the verb and purpose. Every word serves a purpose with no wasted space.

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

Completeness4/5

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

Given no output schema and a simple tool, the description adequately lists the returned fields (id, displayName, email). It could mention possible additional fields or error conditions, but it is complete enough for typical use.

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

Parameters4/5

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

The tool has zero parameters and input schema coverage is 100%. Per guidelines, 0 params yields a baseline of 4. The description adds no parameter information, which is appropriate as none are needed.

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

Purpose5/5

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

The description clearly states the tool retrieves details of the authenticated user, listing specific fields (id, displayName, email). The verb 'Get' and resource 'authenticated user' are specific and distinct from siblings, which focus on repositories, pull requests, etc.

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 guidance on when to use this tool vs alternatives, but the purpose is self-evident as there are no other user info tools among siblings. The description does not provide when-not or alternative scenarios.

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

Install Server

Other Tools

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/Tiberriver256/mcp-server-azure-devops'

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