Provides tools for managing AT&T telecom accounts, including viewing account overview, usage details, bill history, paying bills, and checking device upgrade eligibility.
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., "@@striderlabs/mcp-att check my account overview"
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 (Model Context Protocol) server for AT&T telecom account management. Automates att.com using Playwright with optional Browserbase cloud browser support.
Tool | Description |
| Current plan, balance due, and usage summary |
| Detailed data / call / text usage breakdown |
| Initiate a one-time bill payment |
| View past bills |
| Check device upgrade eligibility for a line |
Related MCP server: TimeCard MCP
npm install @striderlabs/mcp-attOr use the tarball directly:
npm install /path/to/striderlabs-mcp-att-1.0.0.tgzAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"att": {
"command": "npx",
"args": ["-y", "@striderlabs/mcp-att"],
"env": {
"BROWSERBASE_CDP_URL": "wss://connect.browserbase.com?apiKey=YOUR_KEY"
}
}
}
}Set the BROWSERBASE_CDP_URL environment variable to connect to a Browserbase cloud browser session:
BROWSERBASE_CDP_URL="wss://connect.browserbase.com?apiKey=YOUR_BROWSERBASE_API_KEY" node dist/index.jsIf BROWSERBASE_CDP_URL is not set, a local headless Chromium browser is launched automatically.
npm run build
node dist/index.jsVariable | Required | Description |
| No | Browserbase CDP WebSocket URL. If omitted, launches a local headless browser. |
get_account_overviewReturns current plan name, account number, balance due, due date, and data usage summary.
Input:
{
"username": "your-att-email@example.com",
"password": "your-password"
}get_usage_detailsReturns data used/remaining, talk minutes, and text message counts for the current billing period.
Input:
{
"username": "your-att-email@example.com",
"password": "your-password"
}pay_billNavigates to the payment page and pre-fills the amount. Does not automatically submit the payment — manual confirmation is required for security.
Input:
{
"username": "your-att-email@example.com",
"password": "your-password",
"amount": 85.00,
"payment_method": "Visa ending in 4242"
}get_bill_historyReturns a list of past bills with dates and amounts.
Input:
{
"username": "your-att-email@example.com",
"password": "your-password"
}check_upgrade_eligibilityChecks whether a line is eligible for a device upgrade and, if not, when it becomes eligible.
Input:
{
"username": "your-att-email@example.com",
"password": "your-password",
"line_number": "2125551234"
}Credentials are passed per-call and are never stored or logged.
The pay_bill tool intentionally does not auto-submit payments; it requires manual confirmation.
Use Browserbase or another cloud browser provider so credentials are never processed on your local machine.
npm install
npm run build # compile TypeScript → dist/
npm run dev # run with ts-node (requires ts-node)
npm pack # create tarballMIT
Check whether a line on the AT&T account is eligible for a device upgrade, including the eligible date and any upgrade fees. Requires AT&T login credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | AT&T account password | |
| username | Yes | AT&T account username or email address | |
| line_number | No | Optional: phone number of the specific line to check (e.g. '2125551234') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses authentication requirements, which is useful, and hints at the output (eligible date and fees). However, it does not explicitly state whether this is a read-only operation or if there are any side effects, relying on the verb 'check' to imply safety.
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, focused sentence that front-loads the action and purpose, then adds relevant details (eligible date, fees, credentials). There is no fluff or redundant information.
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 tool with three parameters and no output schema, the description is mostly complete: it explains the purpose, output highlights, and authentication. However, it does not describe the behavior when the optional line_number is omitted, nor does it fully detail the return structure beyond eligible date and fees, leaving some room for ambiguity.
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 description covers 100% of parameters, so the baseline is 3. The description adds little beyond the schema, only implicitly connecting 'line' to the optional line_number parameter. It does not provide additional semantic detail about the parameters, so it remains at the baseline.
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 specifies the tool's function: checking upgrade eligibility for a line on an AT&T account, including eligible date and upgrade fees. This is a specific verb+resource+scope that distinguishes it from sibling tools like get_account_overview or pay_bill.
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 clear context for when to use the tool (to check upgrade eligibility) and notes a prerequisite (AT&T login credentials). However, it does not explicitly mention alternatives or when not to use it, which would have made it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of the AT&T account including current plan, balance due, and usage summary. Requires AT&T login credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | AT&T account password | |
| username | Yes | AT&T account username or email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses a key behavioral trait: AT&T login credentials are required. The action 'get' implies a read-only operation, but it doesn't detail error handling, rate limits, or what happens with invalid credentials.
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?
Two sentences, front-loaded with the primary purpose, no filler. The second sentence adds the prerequisite efficiently, making the description concise and well-structured.
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 tool with two parameters and no output schema, the description adequately covers the purpose, included summary contents, and the auth prerequisite. It lacks usage guidance and return format details, but this is acceptable given the tool's 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?
Schema description coverage is 100%, with username and password already described. The description's mention of 'AT&T login credentials' simply reinforces the schema but adds no new parameter meaning beyond what the schema 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 it retrieves a summary of the AT&T account, listing specific contents (current plan, balance due, usage summary). This specific verb+resource distinguishes it from siblings like get_usage_details and get_bill_history, which target narrower aspects.
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 implies usage for obtaining an overall account summary but provides no explicit guidance on when to choose this over sibling tools like get_usage_details or get_bill_history. The prerequisite (requires AT&T login credentials) is mentioned but not as a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View past AT&T bills including dates and amounts. Requires AT&T login credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | AT&T account password | |
| username | Yes | AT&T account username or email address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the authentication requirement, which is a meaningful behavioral trait, but it does not confirm read-only operation or explain any side effects. The word 'View' implies read-only but is not explicit.
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 two short sentences, front-loaded with the core purpose, and contains zero extraneous information. Every word earns its place.
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 view tool with only two parameters and no output schema, the description adequately covers purpose and prerequisites. It mentions that bills include dates and amounts, giving the agent a reasonable expectation of output. It could be enhanced by noting any limitations (e.g., date range or bill status), but it is fundamentally complete.
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%, and the parameter descriptions already explain username and password. The description adds the context that these are AT&T login credentials, but that's redundant with the schema. Since schema fully documents parameters, the baseline of 3 applies.
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's function: 'View past AT&T bills including dates and amounts.' This uses a specific verb ('View') and resource ('past AT&T bills'), and it distinguishes from sibling tools like get_usage_details (usage data) and pay_bill (payments).
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 mentions a key prerequisite ('Requires AT&T login credentials') but does not explicitly compare with alternatives or state when to use this tool over siblings. Usage context is implied but not directly communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed breakdown of data, call, and text usage for the current billing period. Requires AT&T login credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| password | Yes | AT&T account password | |
| username | Yes | AT&T account username or email address |
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 mentions the need for login credentials, but does not explicitly state that this is a read-only operation, what happens with invalid credentials, or any side effects. For a get tool, more transparency about its non-destructive nature would be expected.
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 two sentences, directly states the purpose, and includes the key prerequisite. It is front-loaded with the action and scope, with no 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?
Given the tool's simplicity and lack of output schema, the description adequately covers the returned content (data, call, text usage) and the time scope (current billing period). It also mentions required credentials. However, it could be more complete by explicitly noting the read-only nature or possible absence of output for empty usage.
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 both username and password described. The description does not add additional meaning beyond the schema, so a baseline 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 tool gets a detailed breakdown of data, call, and text usage for the current billing period. This specific verb+resource+scope distinguishes it from sibling tools like get_account_overview or get_bill_history.
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 implies usage when you need current usage details, but it does not explicitly say when to use this tool versus alternatives. The mention of AT&T login credentials is a prerequisite, not usage guidance against other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Initiate a one-time bill payment on the AT&T account. For security, the final payment confirmation must be completed manually. Requires AT&T login credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Payment amount in USD (e.g. 75.50) | |
| password | Yes | AT&T account password | |
| username | Yes | AT&T account username or email address | |
| payment_method | No | Optional: name or label of the saved payment method to use |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It clearly discloses that the final payment confirmation must be completed manually (indicating the tool only initiates, not completes), and that login credentials are required. This adds meaningful security and process context beyond a simple action statement.
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 two sentences long, front-loaded with the main purpose, and includes only essential additional information (security requirement, auth requirement). Every sentence contributes meaning, with no repetition or filler.
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 tool with no output schema and no annotations, the description provides adequate context: it explains the action, the key manual confirmation step, and credential requirements. It could provide more detail about post-call expectations (e.g., response format), but the manual confirmation hint gives the agent a clear workflow signal.
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 100%, so the schema already documents all parameters (username, password, amount, payment_method). The description does not add additional parameter-level semantics beyond what is in the schema, such as constraints on amount or how payment_method is used. Baseline 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 action ('Initiate a one-time bill payment'), the resource ('AT&T account'), and differentiates this as the only payment action among siblings, which are all read-only (get_account_overview, get_usage_details, get_bill_history, check_upgrade_eligibility). This makes the purpose unambiguous and distinguishable.
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 implies when to use the tool (to pay a bill) and provides clear context about the payment process. However, it does not explicitly name alternatives or state when not to use it. The manual confirmation note serves as a usage warning, but no explicit when-not or alternative tool comparison is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0check_upgrade_eligibilityget_account_overviewget_bill_historyget_usage_detailspay_billEach tool has a clearly distinct purpose: account overview, usage details, bill payment, bill history, and upgrade eligibility. There is no overlap or ambiguity in their functions.
All tool names follow a consistent verb_noun pattern in snake_case (get_account_overview, get_usage_details, pay_bill, get_bill_history, check_upgrade_eligibility). The verbs are uniform and descriptive.
With 5 tools, the server is well-scoped for the AT&T account management domain. Each tool covers a distinct need without unnecessary bloat or minimalism.
The tools cover core account management tasks: viewing overview, usage, bill history, paying bills, and checking upgrade eligibility. Minor gaps like autopay management or plan changes are missing but not critical for basic operations.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP Server for agents to onboard, pay, and provision services autonomously with InFlow
Remote MCP server for AI.TV creators — delegate account operations to your AI agent over MCP.
MCP server for Autumn — read customers, plans, balances & invoices; track usage and attach plans.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/markswendsen-code/mcp-att'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
