Skip to main content
Glama
badchars

osint-mcp-server

by badchars

m365_userrealm

Detect Microsoft 365 tenant authentication type by analyzing a domain's user realm to identify namespace type, federation brand, and authentication endpoints for security assessment.

Instructions

Detect authentication type for a domain's Microsoft 365 tenant. Returns namespace type (Managed/Federated), federation brand name, and auth endpoints.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesDomain to check user realm for

Implementation Reference

  • The core logic for the m365_userrealm tool, which performs a request to Microsoft's getuserrealm.srf endpoint to detect if a domain is Managed or Federated.
    export async function m365UserRealm(domain: string): Promise<M365UserRealmResult> {
      try {
        const res = await fetch(
          `https://login.microsoftonline.com/getuserrealm.srf?login=test@${encodeURIComponent(domain)}&json=1`,
        );
        if (!res.ok) return { domain, found: false };
    
        const data = await res.json();
    
        // NameSpaceType 0 = Unknown, 1 = Managed, 2 = Federated
        let namespaceType: string | undefined;
        if (data.NameSpaceType === "Managed" || data.NameSpaceType === 1) namespaceType = "Managed";
        else if (data.NameSpaceType === "Federated" || data.NameSpaceType === 2) namespaceType = "Federated";
        else if (data.NameSpaceType !== undefined) namespaceType = String(data.NameSpaceType);
    
        return {
          domain,
          found: namespaceType !== undefined,
          namespaceType,
          federationBrandName: data.FederationBrandName,
          federationActiveAuthUrl: data.AuthURL ?? data.STSAuthUrl,
          cloudInstanceName: data.CloudInstanceName ?? data.CloudInstanceIssuerUri,
        };
      } catch {
        return { domain, found: false };
      }
    }
  • The registration and definition of the m365_userrealm tool, including its schema and execution handler.
    const m365UserRealmTool: ToolDef = {
      name: "m365_userrealm",
      description: "Detect authentication type for a domain's Microsoft 365 tenant. Returns namespace type (Managed/Federated), federation brand name, and auth endpoints.",
      schema: {
        domain: z.string().describe("Domain to check user realm for"),
      },
      execute: async (args) => json(await m365UserRealm(args.domain as string)),
    };
  • The interface definition for the result returned by m365UserRealm.
    interface M365UserRealmResult {
      domain: string;
      found: boolean;
      namespaceType?: string; // "Managed" or "Federated"
      federationBrandName?: string;
      federationActiveAuthUrl?: string;
      cloudInstanceName?: string;
    }
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. It describes what the tool returns (namespace type, federation brand name, auth endpoints) but doesn't mention important behavioral aspects like rate limits, authentication requirements, error conditions, or whether this is a read-only operation. For a tool that likely queries external Microsoft services, this lack of behavioral context is significant.

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 extremely concise and front-loaded with all necessary information in two efficient sentences. Every word earns its place - the first sentence states the purpose, the second specifies the return values. There's no wasted verbiage or redundant information.

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 tool's single parameter with full schema coverage and no output schema, the description provides adequate but minimal context. It explains what the tool does and what it returns, but lacks important operational details like error handling, rate limits, or authentication requirements that would be helpful for an agent using this in production. The absence of annotations increases the need for more complete behavioral description.

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 a clear parameter description for 'domain'. The tool description doesn't add any additional parameter semantics beyond what's already in the schema. This meets the baseline expectation when schema coverage is complete, but doesn't provide extra value like format examples or validation rules.

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 tool's purpose: 'Detect authentication type for a domain's Microsoft 365 tenant' with specific outputs (namespace type, federation brand name, auth endpoints). It distinguishes itself from sibling tools by focusing on Microsoft 365 authentication detection rather than DNS, WHOIS, or other OSINT functions. However, it doesn't explicitly contrast with the 'm365_tenant' sibling tool, which might have overlapping functionality.

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. While the purpose is clear, there's no mention of when this tool is appropriate compared to other Microsoft 365 tools (like 'm365_tenant') or other authentication detection methods. The agent must infer usage context from the tool name and description alone.

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/badchars/osint-mcp-server'

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