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?
Explains side effects: config setup leads to permanent non-expiring connection, while token paste is session-only. Clarifies that calling with no args returns a link. This adds context beyond annotations (which already include idempotentHint: true). It doesn't cover error cases but adequately discloses behavior.
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 information-dense but organized as a single run-on sentence. It front-loads the purpose and provides practical usage notes. Slightly could be broken into clearer sentences, but it remains efficiently communicated.
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 it's a simple one-parameter authentication tool with no output schema, the description covers the needed context: flow, arguments, and side effects. It could mention what the response looks like (though not required), but is complete enough for an agent to use it correctly.
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 defines 'token' as a string with no description, so the description fully compensates by explaining the expected JWT format, the use of the token parameter, and the behavior when omitted (no args returns link). This adds significant meaning beyond the 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 states the tool's function: authenticate for MCP.AI by logging in via browser and copying an access token. It specifies the two modes (config-based permanent and session-based) and how to invoke each. Though it doesn't explicitly differentiate from sibling tools, the purpose is unambiguous and distinct.
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?
Provides clear guidance on when to use config-based vs session-based login and how to obtain the link with no args. It could be improved by mentioning when not to use this tool or if alternatives like 'connect' might be relevant, but the usage context is well explained.
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.
The three gcp_billing_* tools are clearly distinct in purpose, but authenticate, connect, and toolkit_info overlap around authentication and connection status, which could cause confusion. The marketplace tool additionally bundles many unrelated capabilities into one entry, blurring the tool boundaries.
Naming is inconsistent: billing tools mix noun-style names like gcp_billing_cost with verb-style names like gcp_billing_list_accounts, while the remaining tools use bare single-word names with no shared prefix. There is no predictable convention across the set.
Nine tools is a reasonable absolute count, but only three of them are actually GCP Billing-specific. The other six are generic platform, marketplace, and utility tools, making the set feel bloated relative to the server's stated billing purpose.
The GCP Billing surface covers basic cost queries, top services, and account listing, which handles simple read-only workflows. However, it lacks deeper billing capabilities such as budgets, export management, or detailed account operations, and the unrelated platform tools do not address those gaps.