about_credit_gpsWhat this server is, what it deliberately does not do, and where its limits are. Call it when someone asks what Credit GPS is, who made this, whether their data is stored, or why an answer stopped short.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| what | Yes | ||
| limits | Yes | ||
| privacy | Yes | ||
| product | Yes | ||
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, indicating a safe, read-only operation. Description adds transparency about its scope: 'what it deliberately does not do, and where its limits are,' and explains it can address 'why an answer stopped short,' providing context on behavior beyond 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?
Two sentences, front-loaded with purpose and followed by concrete examples. No waste.
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?
With no parameters and an output schema present, the description fully covers when and why to use the tool. It explicitly states its limits and provides trigger phrases. Nothing is missing.
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?
Tool has zero parameters, so there is nothing for the description to add beyond schema. The description doesn't need to explain any parameters. Baseline of 4 is exceeded because the description fully handles the tool's invocation context.
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?
Explicitly states the tool's purpose: 'What this server is, what it deliberately does not do, and where its limits are.' Provides concrete trigger conditions: 'Call it when someone asks what Credit GPS is, who made this, whether their data is stored, or why an answer stopped short.' Distinguishes from sibling credit tools by being meta-information.
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?
Clear instruction on when to invoke: 'Call it when someone asks what Credit GPS is, who made this, whether their data is stored, or why an answer stopped short.' Implicitly excludes other topics, which are covered by sibling tools. Though it doesn't name alternatives explicitly, the conditions are specific.
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.
Each tool targets a distinct Canadian credit question, from mechanics to calculators. Overlapping payment/utilization tools are clearly separated by current status (reported_snapshot), what-if (simulate_paydown), and recommendation (next_move). No two tools would return the same answer to the same query.
Names are consistently snake_case and descriptive, but they mix noun phrases (close_card_impact, reported_snapshot) with verb-led phrases (find_statement_close_date, simulate_paydown). The pattern is readable and predictable, with minor grammatical inconsistency.
At 16 tools the server is one over the ideal 3-15 range, but each tool covers a distinct topic or calculation. The count feels heavy yet justified by the breadth of Canadian credit mechanics and calculators.
The surface covers foundational mechanics, retention, missed payments, newcomers, products, statement timing, and several calculators, so core workflows are supported. Obvious gaps remain around disputes, fraud alerts, and authorized-user questions, but these are workarounds rather than dead ends.