Skip to main content
Glama
deenesjakoruzh
soulberto

@slorenzot/mcp-azure

by soulberto
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

ado_configure

Configure Azure DevOps connection using personal access tokens (PAT) to manage work items, sprints, and project data through the MCP server.

Instructions

Configura la conexión a Azure DevOps con token de acceso personal (PAT).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
organizationYesURL de la organización (ej: https://dev.azure.com/mi-org)
projectYesNombre del proyecto
patYesToken de acceso personal (PAT) de Azure DevOps

Implementation Reference

  • src/index.ts:193-216 (handler)
    The handler function for 'ado_configure' that establishes the Azure DevOps connection.
    async ({ organization, project, pat }) => {
  const authHandler = azdev.getPersonalAccessTokenHandler(pat);
  connection = new azdev.WebApi(organization, authHandler);
  workItemTrackingApi = null;
  coreApiClient = null;
  currentProject = project;
  currentPat = pat;
  currentOrg = organization;

  // Verificar conexión
  try {
    const connData = await connection.connect();
    return {
      content: [
        {
          type: "text",
          text: `Conexión establecida exitosamente.\n- Organización: ${organization}\n- Proyecto: ${project}\n- Usuario autenticado: ${connData.authenticatedUser?.providerDisplayName || "N/A"}`,
        },
      ],
    };
  } catch (error: any) {
    connection = null;
    throw new Error(`Error al conectar: ${error.message}`);
  }
  • src/index.ts:181-217 (registration)
    The tool registration for 'ado_configure' using server.tool.
    server.tool(
  "ado_configure",
  "Configura la conexión a Azure DevOps con token de acceso personal (PAT).",
  {
    organization: z
      .string()
      .describe("URL de la organización (ej: https://dev.azure.com/mi-org)"),
    project: z.string().describe("Nombre del proyecto"),
    pat: z
      .string()
      .describe("Token de acceso personal (PAT) de Azure DevOps"),
  },
  async ({ organization, project, pat }) => {
    const authHandler = azdev.getPersonalAccessTokenHandler(pat);
    connection = new azdev.WebApi(organization, authHandler);
    workItemTrackingApi = null;
    coreApiClient = null;
    currentProject = project;
    currentPat = pat;
    currentOrg = organization;

    // Verificar conexión
    try {
      const connData = await connection.connect();
      return {
        content: [
          {
            type: "text",
            text: `Conexión establecida exitosamente.\n- Organización: ${organization}\n- Proyecto: ${project}\n- Usuario autenticado: ${connData.authenticatedUser?.providerDisplayName || "N/A"}`,
          },
        ],
      };
    } catch (error: any) {
      connection = null;
      throw new Error(`Error al conectar: ${error.message}`);
    }
  }
  • src/index.ts:184-192 (schema)
    The Zod schema definition for 'ado_configure' input parameters.
    {
  organization: z
    .string()
    .describe("URL de la organización (ej: https://dev.azure.com/mi-org)"),
  project: z.string().describe("Nombre del proyecto"),
  pat: z
    .string()
    .describe("Token de acceso personal (PAT) de Azure DevOps"),
},

Tool Definition Quality

C2.9/5.0
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 tool configures a connection with a PAT, implying it's a setup/mutation operation that likely stores credentials. However, it doesn't disclose critical behaviors: whether the configuration is persistent, if it overwrites existing settings, what authentication scope the PAT needs, or any rate limits/errors. For a tool handling sensitive credentials with zero annotation coverage, 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, efficient sentence in Spanish that directly states the tool's purpose without any fluff. It's front-loaded with the core action and resource, making it easy to parse. Every word contributes to understanding the tool's function.

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 complexity (a configuration tool with 3 required parameters for sensitive credentials), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., success confirmation, error details), how the configuration is used by sibling tools, or behavioral aspects like persistence. For a credential-handling mutation tool, more context is needed to guide safe and effective use.

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 description mentions configuring with a 'token de acceso personal (PAT)', which aligns with the 'pat' parameter in the schema. However, with 100% schema description coverage, all parameters (organization, project, pat) are already well-documented in the schema itself (e.g., organization URL format, project name, PAT definition). The description adds minimal value beyond what the schema provides, meeting the baseline for high coverage.

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 ('Configura' - configures) and the resource ('conexión a Azure DevOps'), specifying it's for setting up a connection with a personal access token (PAT). It distinguishes itself from siblings that perform operations on work items, attachments, comments, etc., by focusing on configuration rather than data manipulation. However, it doesn't explicitly contrast with other configuration tools (none listed), keeping it from a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a PAT beforehand), when it should be invoked (e.g., at session start), or what happens if called multiple times. Given the sibling tools are all operational (e.g., ado_create_work_item), it's implied this is for setup, but no explicit usage context is provided.

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/soulberto/mcp-azure'

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