Carbon Copy MCP Server

Official

by CarbonCopyInc

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.1
Disambiguation4/5
Most tools have clear, distinct purposes (positions vs. portfolio vs. traders vs. orders). However, get_portfolio_history and get_pnl_history have overlapping names despite explicit description disambiguation, and get_trader vs. get_trader_performance could be misselected if read quickly.
Naming Consistency4/5
The set predominantly uses consistent verb_noun snake_case (get_, list_, close_, follow_, etc.). Minor deviations include the bare noun 'health' and the slightly awkward 'batch_update_traders' alongside 'update_trader', but the overall pattern is predictable.
Tool Count4/5
At 21 tools, the set is on the heavier side but remains reasonable for a copy-trading platform. Each tool handles a distinct resource or action, and the count does not feel bloated.
Completeness5/5
The domain is well-covered: full trader lifecycle (discover/follow/update/pause/resume/unfollow), portfolio and P&L reporting, position management with closing, order lookup, and account access. No critical operations appear missing.
Average 3.9/5 across 21 of 21 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true. Description adds no behavioral context about partial failures, atomicity, or permission requirements beyond the redundant 'update' wording.
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?
One sentence of 11 words, front-loaded with the verb 'Update', and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Batch operation with a nested array parameter and no output schema. Description gives no information about response format, error handling, or partial update behavior, making it inadequate for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. Field names like maxCopyAmount and copyPercentage are self-explanatory only at a surface level; no meaning or usage guidance is provided for these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'update', identifies resource 'settings across multiple followed traders', and specifies batch nature with 'in one request'. This clearly distinguishes it from sibling tool update_trader which handles a single trader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies batch usage via 'multiple followed traders' but does not explicitly state when to prefer this over update_trader or provide exclusions. Usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already covers the safety profile, so the bar is lower. The description adds minimal behavioral context, only stating that it searches and ranks traders. It does not disclose result formatting, pagination, or default sorting behavior, but it does not contradict the annotations either.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, making it appropriately concise. However, given the tool has six parameters, this brevity is borderline under-specified; still, it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is very sparse for a tool with six parameters and no output schema. It does not explain how discover_traders relates to siblings like list_traders, nor does it describe ranking logic or result types. The annotation provides safety, but the description lacks sufficient context for an agent to make a fully informed choice.
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 for all six parameters, so the schema carries the parameter semantics. The description itself does not mention parameters, but given the high schema coverage, the baseline of 3 is appropriate.
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 uses a specific verb phrase 'search and rank' with the resource 'traders', clearly indicating a discovery operation. It also adds the context 'available to follow', which helps differentiate from simple listing. However, it does not explicitly distinguish from the sibling tool list_traders, leaving some ambiguity.
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 like list_traders or get_trader. It lacks any contextual cues about use cases, prerequisites, or exclusion conditions, leaving the agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotation readOnlyHint=false indicating mutation, the description does not disclose side effects, required authentication, reversibility, or duplicate-follow behavior. It adds little value beyond the title.
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 a single sentence that immediately states the action and target, with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no output schema and minimal annotations, the description lacks behavioral context (what happens after starting, whether it can be reversed, etc.). It is sufficient for selection but not for clear invocation expectations.
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 covers 100% of parameters with descriptions, and the description doesn't elaborate on them. It clarifies that wallet is the trader's address, but doesn't handle additional semantics like maxCopyAmount or notificationsEnabled, which are already documented in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'start copy-trading' and identifies the resource (a Polymarket trader) and the input (wallet address). It clearly distinguishes from sibling update/unfollow/pause tools.
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 like update_trader or unfollow_trader. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already communicates that this is a safe read operation, so the description does not need to restate that. The description adds minimal behavioral context beyond the tool's name—'performance metrics and history' is vague and does not clarify what specific data is returned, whether it is aggregated, or if it includes time-series details.
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 a single, front-loaded sentence with no unnecessary words. It directly states the action and target, earning a perfect conciseness score.
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?
The tool is simple with one parameter and a read-only annotation, but the description lacks specificity about the output structure or the exact metrics included. Without an output schema, an agent would not know whether the result is a single object or a time series, leaving a moderate gap in completeness.
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% coverage for the single parameter 'wallet', with a clear description of 'The Polymarket wallet address of the trader.' The tool description adds no additional parameter information, so the baseline score of 3 applies.
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 uses the specific verb 'Retrieve' and identifies the resource as 'performance metrics and history' for a trader, clearly stating the tool's function. However, it does not distinguish this from closely related siblings like get_pnl_by_trader or get_pnl_history, which also deal with trader performance metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it retrieves performance metrics and history, but it provides no explicit guidance on when to use this tool over alternatives. With siblings like get_pnl_by_trader and get_portfolio_history, the absence of exclusionary or comparative notes leaves the choice ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the context that this is a copy-trade order, but it does not describe return format, error behavior, or any other behavioral traits. No contradiction with annotations.
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 a single, well-structured sentence that directly states the tool's purpose with no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-ID retrieval tool, the description plus annotations adequately convey the core function. However, it lacks any detail about the return value and does not reference related tools (e.g., list_orders), which would enhance completeness.
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% coverage for the single id parameter, already describing it as 'The order ID to retrieve.' The description reinforces 'by ID' but adds no additional semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' and clearly identifies the resource as 'details about a specific copy-trade order by ID'. The 'by ID' qualifier distinguishes this from sibling list_orders, which would list orders.
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 explicit guidance on when to use this tool versus alternatives like list_orders. Usage is only implied by the tool's name and ID parameter, with no mention of cases where list_orders would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful behavioral context beyond the annotations: it states that 'status=closed currently returns an empty set' and that positions are mark-to-market. This is valuable because the schema allows closed/all statuses but the implementation has a caveat. Annotations declare readOnlyHint=true, which aligns with the 'Retrieve' verb. No contradictions found.
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 a single sentence that front-loads the core purpose and includes the most important caveat. There is no wasted text; every word contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description conveys the main purpose and a key behavioral quirk. It does not explain the return fields, but the term 'positions' plus the schema's parameter documentation offer sufficient context. The annotation readOnlyHint further clarifies the safety profile. It is complete enough for most use cases, though a brief mention of the response shape would have been ideal.
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 already provides 100% coverage of parameter descriptions, so the baseline is 3. The description does not add any details about parameter formats or types beyond what the schema provides. It only mentions 'optional filtering' generically, which does not increase meaning beyond the schema.
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 uses a specific verb ('Retrieve') and resource ('live open portfolio positions') with a clear scoping detail (mark-to-market). It also distinguishes itself by noting the behavior of status=closed. However, it does not explicitly differentiate from sibling tools like get_portfolio, which may serve a similar purpose.
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 does not mention when to use this tool versus alternatives such as get_portfolio or get_portfolio_history. There is no explicit when-to-use, when-not-to-use, or exclusion criteria. The usage context (live positions) is implied but not contrasted with options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, and the description adds that it sells shares back to the market, which is useful context. However, it does not disclose potential partial closes (via the 'shares' parameter), market impact, or that the action is irreversible beyond what the annotation implies.
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 a single, concise sentence with no unnecessary words. It is front-loaded with the primary action and resource, making it easy to parse quickly.
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?
The tool has 5 parameters and no output schema, so the description should provide some context about behavior and outcomes. It covers the basic action but omits edge cases like partial closes, the optional 'outcome' parameter, and what the response contains. The schema fills in parameter details, but overall completeness is moderate given the financial action.
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% descriptor coverage for all parameters, so the baseline is 3. The description does not add any additional meaning or clarify parameter interactions beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Close') and resource ('open position') and explains the mechanism ('selling shares back to the market'). It clearly distinguishes from sibling tools like get_positions, which only list positions, and there is no other close tool in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when an open position exists, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions (e.g., when to use sell orders directly). The context is clear but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description confirms this with 'Retrieve'. It adds useful context by specifying 'your account' (self-scoped) and the kind of data returned (wallet address, balance, settings). However, it does not disclose any additional behavioral details such as authentication requirements or rate limits, though the annotations cover the basic safety profile.
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 a single sentence with no filler. It delivers the core purpose, scope, and examples of returned data in an immediately readable format, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and the annotations that clarify read-only behavior, the description provides sufficient context: it names the resource, scope, and contents. It could arguably mention that it returns data for the authenticated user's own account, but the phrase 'your...account' already implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description's mention of what will be returned (wallet address, balance, settings) adds meaning beyond the schema. With zero parameters, the baseline is 4, and the description provides a helpful overview of the conceivable return fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and clearly identifies the resource as 'your Carbon Copy account details', listing wallet address, balance, and settings. This distinguishes it from sibling tools like get_portfolio or get_positions, which focus on different data domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when you need the current user's account information, but it offers no explicit guidance on when to prefer it over alternatives like get_portfolio or get_trader. There are no stated exclusions or alternative suggestions, so usage context is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation, and the description does not contradict that. It adds a small amount of context by specifying 'realized' P&L and grouping by market, but does not disclose additional behaviors like return format, pagination, or time range. This meets the baseline for annotations but offers limited extra transparency.
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 a single, front-loaded sentence that directly states the tool's purpose without any wasted words. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description carries the burden of explaining the return value. It does state the output is a breakdown of realized P&L grouped by market, which gives a reasonable idea of the result shape. For a simple no-parameter read-only tool, this is fairly complete, though it could mention time range or filtering, which are not applicable here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the input schema provides no fields to document. The baseline for 0 parameters is 4, and the description adds sufficient context about what the output will contain (realized P&L per market), so there is no missing parameter information to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'breakdown of realized P&L grouped by each market.' It distinguishes itself from sibling tools like get_pnl_by_trader (by trader) and get_pnl_history (history over time) by specifying the market grouping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need P&L by market) but does not explicitly mention alternatives or exclusions. There is no direct 'use this instead of X' guidance, though the market grouping is clear enough to differentiate from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it 'Retrieve[s]' data, which aligns with readOnlyHint=true, and lists the included fields (total value, P&L, allocation). However, it does not add context beyond the annotation, such as data freshness, currency, or whether positions are included. The annotation already covers safety, so the description provides only minimal additional behavioral context.
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 a single sentence that is concise and front-loaded with the main action ('Retrieve the current portfolio summary'). It provides the key informational fields without unnecessary words or repetition, making it an efficient and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple read-only tool with no parameters, an read-only annotation, and no output schema. The description adequately explains the return contents (total value, P&L, allocation) and clarifies it is a 'current' summary. It could be slightly more explicit about data freshness or base currency, but for a tool of this complexity it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete. The baseline for 0 parameters is 4, and the description does not need to explain any parameters. It correctly avoids inventing parameter details where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and names the resource ('portfolio summary') while detailing what it includes: total value, P&L, and allocation. This clearly distinguishes it from siblings like get_portfolio_history (history) and get_positions (positions), which cover different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'current' implies this is a snapshot tool, but the description does not explicitly state when to use it over alternatives like get_pnl_by_trader or get_positions. There is no mention of when not to use it or discussion of sibling tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to cover safety. It adds the constraint that the trader must be one you are following, which is not in the schema or annotations, providing useful behavioral context beyond what structured data offers.
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 a single sentence that front-loads the action and contains zero unnecessary words. It is concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter and strong annotations, the description is mostly complete. However, it does not specify what 'details' are returned or include any return format, which would be helpful given there is no output schema.
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?
Schema description coverage is 100% for the single 'wallet' parameter, so the schema already explains the parameter. The description adds no extra parameter semantics, making the baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('details about a specific trader'), and the phrase 'you are following' distinguishes it from list/discover tools. It clearly states what the tool does and is not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need details about a specific trader you follow, but it does not explicitly state when to use this tool versus alternatives like get_trader_performance or list_traders. No exclusions or alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering the safety profile. The description adds the copy-trade scope and filter options but does not disclose behavioral details such as default limit, sorting, or pagination continuation beyond what the schema states.
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 a single, front-loaded sentence that packs the key details: list, copy-trade orders, optional status, pagination, and date range. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description is sufficient: it identifies the resource and filter options. It could be improved by pointing to get_order for single-order retrieval or describing pagination continuation, but it is not incomplete.
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?
Schema description coverage is 100% for all five parameters. The description's mention of 'status filter, pagination, and date range' only mirrors the schema field descriptions without adding deeper meaning or context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieve') and resource ('copy-trade orders'), and indicates a list operation which distinguishes it from the sibling tool get_order. The optional status filter, pagination, and date range provide specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for fetching multiple orders with optional filters, providing clear context. However, it does not explicitly mention when to use get_order for a single order or exclude other tools, so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as a mutating (readOnlyHint=false) and idempotent operation. The description adds one useful behavioral nuance—that the follow relationship remains intact—but does not disclose other potential side effects or reversibility. This is adequate but not rich, aligning with the baseline for annotated tools.
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 a single sentence that is front-loaded with the action and contains no extraneous information. It is as concise as possible while still conveying the essential distinction from unfollowing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter mutation tool with idempotent annotation, the description covers the core behavior (pausing copy-trading without unfollowing). It does not mention return values or how to undo via resume_trader, but these are not essential for such a straightforward operation, making it sufficiently complete.
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% coverage for the single 'wallet' parameter, so the schema already explains its meaning. The description does not add any additional parameter-level detail, meriting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('pause') and a clear resource ('copy-trading for a specific trader'), and explicitly states 'without unfollowing them,' which distinguishes it from siblings like unfollow_trader and resume_trader. This is a precise and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (to temporarily pause copy-trading) and contrasts it with unfollowing, giving a clear alternative. However, it does not explicitly state when not to use it or provide other exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the precondition 'previously paused' which is useful beyond the annotations. However, the annotations already indicate this is a write and idempotent operation, so the description adds limited extra behavioral context beyond the scope constraint.
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 a single clear sentence with no filler words. It effectively communicates the action and scope in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 annotations covering idempotency and mutability, the description adequately conveys the operation and its precondition. It could mention potential error cases (e.g., if trader is not paused) but that is not essential for this low-complexity tool.
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 already enumerates the one parameter 'wallet' with a clear description. The tool description reinforces the 'previously paused' context but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Resume' and identifies the resource 'copy-trading' for a 'previously paused trader.' This clearly distinguishes it from sibling tools like pause_trader or follow_trader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously paused trader' provides clear context that this tool is intended for traders already paused via pause_trader. It implies the correct usage scenario, though it doesn't explicitly state exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the destructiveHint annotation and adds that the trader is removed from the follow list. However, it does not disclose whether existing open positions are closed or left untouched, nor any other side effects, providing only marginal added context beyond the annotation.
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 a single, concise sentence that immediately conveys the tool's purpose and effect. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, destructive action with annotations and full schema coverage, the description adequately states the outcome. A minor gap is the lack of clarity on what happens to existing copy-trade positions, but this is not critical given the sibling tools dedicated to position management.
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 provides a complete description of the 'wallet' parameter (100% coverage), and the tool description adds no additional meaning to that parameter. The baseline of 3 applies because the schema carries the semantic weight.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific action verbs ('Stop copy-trading', 'remove') and names the resource ('a trader') and scope ('from your follow list'). It clearly distinguishes this from sibling tools like follow_trader, pause_trader, and resume_trader by indicating a permanent stop and removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when the user wants to stop copy-trading and unfollow. It doesn't explicitly contrast with pause_trader or resume_trader, but the action is self-explanatory, offering clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and idempotentHint=true, so the description doesn't need to repeat those. It adds the prerequisite that the trader must be followed, but it does not disclose potential side effects, required permissions, or the behavior when optional fields are omitted.
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 a single sentence with no redundancy. Every word adds value, clearly conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the clear schema, annotations (including idempotentHint), and no output schema, the description provides sufficient context for an update operation. It could mention the optional-field update behavior, but the combination of schema and annotations covers most needs.
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?
Schema description coverage is 100%, with each parameter already having a clear description (e.g., 'New maximum USDC amount per trade'). The tool description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Update') and the resource ('copy-trading settings') for a specific target ('a trader you are following'). This distinguishes it from sibling tools like follow_trader, pause_trader, and batch_update_traders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a trader you are following' establishes a clear precondition for use, implying it should not be used to start following someone. However, it does not explicitly name alternatives or state when not to use this tool vs. batch_update_traders or pause_trader.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, which already declares this as a safe read operation. The description adds context about the data being 'realized P&L' and grouped by trader, but does not disclose other behavioral traits like response format, pagination, or any data scoping limitations. With annotations covering the safety profile, this level of detail is adequate but not rich.
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 a single, concise sentence that immediately states the action and resource. It contains no filler words or unnecessary details, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with no output schema, the description is sufficiently complete. It explains what the tool returns (a breakdown of realized P&L grouped by trader) without needing to cover input parameters. It does not describe the exact output format, but this is not heavily required given the simplicity of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (vacuous). Per the rubric, a baseline of 4 applies. The description adds semantic context about what the output represents (grouped P&L), but there are no parameter details to elaborate on, so no additional information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Get') and resource ('breakdown of realized P&L') and specifies the grouping dimension ('by each trader you copy'). It distinguishes itself from sibling tools like 'get_pnl_by_market' by explicitly stating the grouping key, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: when you need P&L broken down per trader in your copy portfolio. It does not explicitly mention when not to use it or name alternatives (e.g., 'get_pnl_by_market'), but the context is clear enough for an agent to infer the appropriate scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description doesn't need to repeat that. It adds value by disclosing the return format ('snapshots with realized/unrealized P&L breakdown'). No contradictions with annotations are present.
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 two sentences totaling 24 words. It front-loads the action and resource, then adds a brief behavioral detail. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two optional parameters, the description adequately covers the return value ('snapshots with realized/unrealized P&L breakdown') and purpose. No output schema exists, so this return description is important and is provided. Minor gaps like units or exact snapshot format are 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description itself adds no parameter-specific meaning, but both parameters are fully documented in the schema (days with range, interval with enum/default). Thus the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clear resource 'time-series portfolio P&L data' and a stated purpose 'for charting performance over time.' It also mentions the realized/unrealized breakdown, distinguishing it from sibling tools like get_pnl_by_trader or get_pnl_by_market by focusing on portfolio-level data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for charting performance over time' provides clear context for when this tool is appropriate. While it doesn't explicitly mention alternatives or exclusions, the context is sufficient for an agent to understand its primary use case, especially given sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds the specific focus on 'health and availability,' providing some context beyond annotations, but it does not describe return format, error behavior, or use cases. This is a moderate contribution.
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 a single concise sentence that immediately conveys the tool's purpose. It is front-loaded, free of fluff, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check with no parameters and strong annotations, the description is largely sufficient. However, since there is no output schema, the description could have clarified what the response looks like (e.g., status code, JSON body). The current text conveys the core intent without specifying return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, leaving nothing for the description to add. The baseline score of 4 for 0-parameter tools is appropriate; the description correctly does not mention parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the health and availability of the Carbon Copy API.' It uses a specific verb ('Check') and identifies a distinct resource (API health), which differentiates it from the many data/action sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to verify API health/availability, but it does not explicitly state when to use it or mention alternatives. Given that no sibling tool serves this purpose, the context is clear, though explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context about pagination and optional date filtering, which goes beyond the annotations. It does not contradict annotations.
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?
Two sentences, no fluff, and front-loaded with the main action. The second sentence provides essential alternative guidance, earning its place. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with no output schema, the description effectively communicates the return type ('individual trade records'), pagination, and date filters. It lacks details on sorting or defaults, but the schema covers parameters, making it adequately complete for the complexity.
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?
All 4 parameters are fully described in the schema, covering 100% of parameter semantics. The description's mention of 'paginated' and 'optional date filtering' loosely maps to cursor/limit and since/until, but adds little beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Retrieve' and names the resource 'copy-trade history (individual trade records)', clearly distinguishing it from get_pnl_history which covers portfolio value. This makes the purpose exceptionally clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to use get_pnl_history for portfolio value over time, providing a direct alternative and exclusion. The description also implies when to use this tool (when individual trade records are needed), so usage context is well established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds 'currently following' scope, which is a behavioral constraint not covered by the readOnlyHint annotation. It doesn't describe return format or pagination, but for a no-parameter read-only tool with annotations, this is adequate.
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 a single, front-loaded sentence with zero wasted words: 'List all traders you are currently following.' It is concise and easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, read-only annotation, and no output schema, this description is complete. It clearly states the action and the scope, leaving no ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is 100% by default. The description has no parameter details to add, and the baseline for zero-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('traders') with a clear scope ('currently following'). It distinguishes itself from sibling tools like discover_traders (which lists available traders) and get_trader (which retrieves a single trader).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently following' provides context that this tool is for viewing followed traders, not for discovery or individual lookups. However, it does not explicitly name alternatives or state when not to use it, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![carboncopy-mcp MCP server](https://glama.ai/mcp/servers/CarbonCopyInc/carboncopy-mcp/badges/card.svg)](https://glama.ai/mcp/servers/CarbonCopyInc/carboncopy-mcp)

Score Badge

Copy to your README.md:

[![carboncopy-mcp MCP server](https://glama.ai/mcp/servers/CarbonCopyInc/carboncopy-mcp/badges/score.svg)](https://glama.ai/mcp/servers/CarbonCopyInc/carboncopy-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/CarbonCopyInc/carboncopy-mcp'

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