MCP.AI for IDE agents (Cursor, etc.): log in in the browser, copy the access token. Best: add it to this server's config as a header Authorization: Bearer <token> for a permanent, non-expiring connection. Or paste it here for a session-only login: call with { token: "" } after the user pastes, or with no args to get the link.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description reveals important behavior: no args returns a login link, passing a token creates a session-only login, and config-header setup provides a permanent non-expiring connection. It clearly sets expectations about the two modes and their persistence. It does not contradict the annotations.
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 and packs in the main modes and call forms without wasted words. The use of 'Best:' and 'Or' helps structure the two options. It is slightly dense but remains readable and appropriately sized.
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 one-parameter tool with no output schema, the description covers how to invoke it and what each invocation mode accomplishes. It does not discuss invalid tokens or error handling, but those are not essential for basic selection and invocation. Overall, it is complete enough for an agent to use.
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 only declares an optional string `token` with no description, so the description must carry the meaning. It explains that `token` is the pasted JWT access token and that omitting it yields a login link. This adds meaningful semantics beyond the bare schema.
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 identifies the tool as authentication for MCP.AI in IDE agents, explaining browser login and access token handling. It gives specific actions (log in, copy token, pass token, or call with no args to get a link) rather than just repeating the name. It does not explicitly differentiate from the sibling 'connect' tool, so it stops short of a 5.
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 gives concrete usage instructions: add the token as an Authorization header for a permanent connection, or paste it for session-only login. It also specifies call shapes: `{ token: "<jwt>" }` or no arguments to get the link. It lacks explicit when-not-to-use guidance relative to sibling tools, so it is not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes, especially the aws_billing_* group. The main ambiguity is between 'connect' and 'toolkit_info', both of which report connection status, and 'authenticate' overlaps slightly with connection management. However, descriptions are detailed enough to reduce misselection.
The aws_billing_* tools follow a consistent prefix pattern, but the rest are wildly inconsistent: authenticate, connect, marketplace, report_bug, show_version, toolkit_info. There's no uniform verb-noun convention, and mixed styles (snake_case vs plain words) make the set feel chaotic.
With 10 tools, the count is within the acceptable range. However, the server name suggests AWS Billing, yet only 4 tools are billing-related while the other 6 are generic MCP platform utilities. This scope mismatch makes the count feel inappropriate for the stated purpose.
For an AWS Billing server, the surface is missing critical operations: no budgets, alerts, cost allocation tags, or write actions (e.g., creating reports). The read-only cost, forecast, and anomalies cover only basic visibility. The presence of unrelated platform tools further dilutes billing completeness.