Skip to main content
Glama
mwhesse

Dataverse MCP Server

by mwhesse

Convert Owner Team to Access Team

convert_owner_team_to_access_team

Convert an owner team to an access team to change record ownership and sharing capabilities. This irreversible action modifies how records owned by the team are managed.

Instructions

Converts an owner team to an access team, changing how the team can be used for record ownership and sharing. WARNING: This action cannot be undone and affects how records owned by this team are managed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
teamIdYesID of the owner team to convert to access team

Implementation Reference

  • The handler function that implements the core logic of the tool. It takes the teamId parameter and calls the Dataverse 'ConvertOwnerTeamToAccessTeam' action, returning success or error response.
    async (params) => {
      try {
        await client.callAction('ConvertOwnerTeamToAccessTeam', {
          TeamId: params.teamId
        });
    
        return {
          content: [
            {
              type: "text",
              text: `Successfully converted owner team to access team.`
            }
          ]
        };
      } catch (error) {
        return {
          content: [
            {
              type: "text",
              text: `Error converting team: ${error instanceof Error ? error.message : 'Unknown error'}`
            }
          ],
          isError: true
        };
      }
  • Defines the tool's title, description, and input schema using Zod for validating the required 'teamId' parameter.
    {
      title: "Convert Owner Team to Access Team",
      description: "Converts an owner team to an access team, changing how the team can be used for record ownership and sharing. WARNING: This action cannot be undone and affects how records owned by this team are managed.",
      inputSchema: {
        teamId: z.string().describe("ID of the owner team to convert to access team")
      }
    },
  • src/index.ts:209-209 (registration)
    Registers the tool by invoking the exported registration function from team-tools.ts with the MCP server and Dataverse client instances.
    convertOwnerTeamToAccessTeamTool(server, dataverseClient);
  • The exported function that performs the tool registration, including the tool name, schema, and handler implementation.
    export function convertOwnerTeamToAccessTeamTool(server: McpServer, client: DataverseClient) {
      server.registerTool(
        "convert_owner_team_to_access_team",
        {
          title: "Convert Owner Team to Access Team",
          description: "Converts an owner team to an access team, changing how the team can be used for record ownership and sharing. WARNING: This action cannot be undone and affects how records owned by this team are managed.",
          inputSchema: {
            teamId: z.string().describe("ID of the owner team to convert to access team")
          }
        },
        async (params) => {
          try {
            await client.callAction('ConvertOwnerTeamToAccessTeam', {
              TeamId: params.teamId
            });
    
            return {
              content: [
                {
                  type: "text",
                  text: `Successfully converted owner team to access team.`
                }
              ]
            };
          } catch (error) {
            return {
              content: [
                {
                  type: "text",
                  text: `Error converting team: ${error instanceof Error ? error.message : 'Unknown error'}`
                }
              ],
              isError: true
            };
          }
        }
      );
    }
Behavior4/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds critical context: the action 'cannot be undone' (destructive behavior) and 'affects how records owned by this team are managed' (impact on related data). This goes beyond the basic 'convert' action, though it could benefit from details on permissions or error conditions.

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 front-loaded with the core action in the first sentence, followed by a critical warning. Both sentences earn their place by providing essential operational and risk information without redundancy or fluff, making it highly efficient and well-structured.

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

Completeness4/5

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

Given the tool's complexity (irreversible conversion affecting record management), no annotations, and no output schema, the description does a good job covering key behavioral aspects like destructiveness and impact. However, it lacks details on prerequisites (e.g., required permissions) or output expectations, leaving minor gaps for the 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 has 100% description coverage, with the 'teamId' parameter clearly documented. The description does not add any additional meaning or syntax details beyond what the schema provides, such as format examples or validation rules. According to the rules, with high schema coverage, the baseline is 3.

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 specific action ('converts'), the resource ('owner team'), and the outcome ('to access team'), with explicit mention of the functional change ('changing how the team can be used for record ownership and sharing'). It distinguishes itself from siblings like 'create_dataverse_team' or 'update_dataverse_team' by focusing on a specific type of team conversion rather than creation or general updates.

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 context through the WARNING about irreversibility and effects on record management, suggesting it should be used cautiously for teams involved in ownership. However, it does not explicitly state when to use this tool versus alternatives (e.g., when to convert vs. create a new team) or provide clear exclusions, leaving some ambiguity for the agent.

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/mwhesse/mcp-dataverse'

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