KalTrader MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct resource+action combination. The GET endpoints are differentiated by resource type (markets, events, series, orders, etc.), and write operations (create, amend, cancel, decrease, transfer) are scoped to specific resources. The paper trading tools are explicitly marked as simulated, and the meta tools (list/describe/call endpoint) serve a unique discovery purpose, so there is no meaningful ambiguity.
Naming Consistency4/5
The majority of tools follow a consistent get_* or verb_noun pattern (e.g., kalshi_get_market, kalshi_create_order_v2). However, there are minor deviations: 'kalshi_paper_order' and 'kalshi_paper_portfolio' lack a verb prefix, 'kalshi_stream_collect' reverses the verb, and 'kalshi_intra_exchange_instance_transfer' is a noun phrase. These are few relative to the total and do not significantly impede readability.
Tool Count1/5
With 60 tools, this server far exceeds the well-scoped threshold. Many endpoints could be served by the generic kalshi_call_endpoint or consolidated into parameterized tools. The count is an extreme mismatch for typical tool-set expectations and likely overwhelms an agent.
Completeness5/5
The tool surface is exceptionally complete for the Kalshi trading API, covering market data, order management (create, amend, cancel, decrease, batch), portfolio (balance, positions, fills, settlements), subaccounts, and paper trading. The generic kalshi_call_endpoint ensures that even endpoints without dedicated tools are accessible, leaving no obvious gaps.
Average 3.8/5 across 60 of 60 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 60 commits in the last 12 weeks
- No stable releases found
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the HTTP method and path ('Calls GET /portfolio/positions') and hints at a filtering behavior, which is slightly useful beyond the annotations. However, it does not disclose pagination behavior, return format, or any other operational details. Annotations already declare read-only and non-destructive, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, run-on sentence that mixes the tool's name with parameter-level details and an endpoint hint. It lacks clear front-loading and organization, making it harder to parse quickly.
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 tool with six parameters and no output schema, the description is insufficient. It does not explain what the response contains, how pagination works, or how to use filters effectively. The endpoint mention is helpful but does not fill the gaps.
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 describes all six parameters with 100% coverage. The description adds no new parameter information; it simply repeats the description of count_filter. Since the schema already provides complete semantics, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Get Positions', which clearly identifies the tool's action and resource, but the rest of the sentence is dedicated to describing the count_filter parameter rather than the tool's overall function. This muddles the purpose and makes it less distinct from sibling tools like get_orders or get_trades.
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?
No guidance is provided on when to use this tool versus alternatives. The description only mentions the HTTP endpoint and a parameter behavior, without explaining the typical use case, prerequisites, or exclusions.
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 annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds minimal behavioral detail beyond the endpoint path. It does not disclose the response format, pagination, or the meaning of historical data, so the agent still lacks key 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that directly states the purpose and endpoint. While somewhat terse, it is free of redundant or irrelevant content.
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 read-only API tool with optional parameters, the description should clarify what fee changes are, how the parameters affect the results, and how it differs from related tools. None of this is provided, leaving significant gaps for an agent to invoke the tool correctly.
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?
The schema has two parameters with no descriptions, and the description does not mention them at all. With 0% schema description coverage, the description carries the full burden and fails to explain series_ticker or show_historical.
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 identifies the resource 'Series Fee Changes' with the verb 'Get', and the HTTP endpoint reinforces the action. It distinguishes from sibling tool kalshi_get_event_fee_changes by the resource type (series vs event), though it does not explain what fee changes are.
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?
No guidance is provided on when to use this tool versus alternatives like kalshi_get_event_fee_changes. There is no mention of prerequisites, such as needing a series_ticker, or when to set show_historical.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds only 'Calls GET /milestones,' which is marginal; it does not disclose pagination behavior, rate limits, or result shape, and there is no output schema to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but structurally garbled—purpose, a parameter description, a format note, and an endpoint reference are run together without clear separation. 'Minimum start date to filter milestones.' reads as an orphaned sentence.
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 9-parameter tool with no output schema and a near-identical singular sibling (kalshi_get_milestone), the description fails to explain what a milestone is, what the response contains, or how this tool relates to its sibling. The schema covers parameters but not the broader context an agent 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%, so parameters are already well documented. The description's only parameter-related content ('Minimum start date... Format: RFC3339 timestamp') merely duplicates the minimum_start_date schema description and adds no new semantic value.
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 opens with 'Get Milestones,' a clear verb+resource pair that identifies the list operation. However, it does not differentiate from the sibling tool kalshi_get_milestone, and the following fragments about minimum_start_date add confusion rather than scope.
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?
No guidance is given on when to use this tool versus kalshi_get_milestone or other list tools. It doesn't mention polling use cases (despite min_updated_ts) or pagination strategy, leaving the agent to infer usage from the schema alone.
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 indicate a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds behavioral constraints like mutually exclusive timestamp filters, but it also has a discrepancy: it omits the 'paused' status that appears in the schema. It reveals the HTTP endpoint but doesn't describe return format or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured: a brief first sentence followed by fragmented bullet rules and a broken markdown table. It is longer than needed and hard to parse, failing to front-load the most important 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?
With 14 parameters and no output schema, the description should explain what the response contains and any pagination behavior. It doesn't mention the return payload or overall behavior beyond filtering. The filter compatibility rule is only partially communicated, leaving gaps in understanding for an agent.
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%, so the baseline is 3. The description adds a compatibility table for timestamp filters and status filters, but the table is malformed and largely duplicates information already in the schema (e.g., min_updated_ts incompatibility). It does add the rule that only one status filter may be supplied, which isn't in the schema, but the added value is limited.
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 clearly states the action ('Get Markets') and resource (markets), and mentions filtering by status. However, it doesn't explicitly differentiate from sibling tools like kalshi_get_market (singular) or kalshi_get_events, so it's clear but not fully distinguishing.
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 such as kalshi_get_market or kalshi_get_events. It only lists filter constraints, not usage context or exclusions.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe read. The description adds only 'Calls GET /structured_targets' and repeats page_size bounds already present in the schema. It does not disclose response format, pagination behavior, or any limitations beyond schema-encoded constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but structurally awkward: 'Get Structured Targets Page size (min: 1, max: 2000) Calls GET /structured_targets.' It jumbles the purpose with a parameter detail, making it less scannable. It earns a middle score because it is one line and front-loads the main verb, but the structure could be cleaner.
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?
With 5 optional parameters, no output schema, and the presence of sibling tools, the description is too thin. It doesn't explain what structured targets are, what the response contains, how cursor pagination works, or how filters behave. The name implies listing, but the description leaves the agent with gaps for a moderately complex read operation.
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%, so all 5 parameters are fully documented in the schema. The description's only parameter-related note ('Page size (min: 1, max: 2000)') adds no new meaning beyond what the page_size schema already provides. 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 'Get Structured Targets' with a specific verb and resource. It distinguishes itself from the sibling tool 'kalshi_get_structured_target' (singular) by indicating a plural list operation, and it names the exact endpoint 'GET /structured_targets'.
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?
There is no guidance on when to use this tool versus alternatives. It doesn't mention that it's for listing multiple targets, how it relates to the singular 'kalshi_get_structured_target', or any context about filters/pagination being optional.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds 'Calls GET /portfolio/deposits,' which merely reinforces the read-only nature and provides no additional behavioral context such as pagination behavior, rate limits, or response format beyond what the schema offers.
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 short and front-loaded, but the first sentence 'Get Deposits Endpoint for getting the member's deposit history' is slightly redundant. The second sentence adds the concrete endpoint reference, which is valuable for invocation.
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?
As a read-only list endpoint, the description plus schema pagination details are sufficient for correct invocation. It doesn't explain the return structure, but the schema's cursor description implies a paginated response, and 'deposit history' conveys the general output.
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?
Both limit and cursor are fully described in the schema, covering 100% of parameters with explicit meanings and defaults. The description adds no parameter-specific details, so it relies entirely on 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 clearly states it retrieves the member's deposit history and names the exact endpoint (GET /portfolio/deposits). It is specific to deposits, distinguishing it from siblings like kalshi_get_withdrawals, though it doesn't explicitly reference that alternative.
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?
No guidance is provided about when to use this tool versus alternatives. It only restates the function without contextual exclusions or mention of related tools such as kalshi_get_withdrawals.
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds meaningful context about the meaning of null override fields and the fact it calls GET /events/fee_changes. It does not disclose pagination behavior, rate limits, or response format, but given the read-only nature, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise but awkwardly structured. It begins with a repeat of the tool name, then a run-on explanation, and ends with the HTTP call. It includes useful details about null override semantics but could be tightened into more focused sentences. The structure is not terrible, but it is not well front-loaded or elegantly organized.
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 relatively simple (a read-only GET) and the annotations cover safety. The description explains the core domain concept (override on series fee structure) and the endpoint. However, it omits any mention of pagination despite having limit and cursor parameters, and there is no output schema to clarify return structure. For a tool with this complexity, it is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters, with descriptions for limit and cursor but not for event_ticker. The description does not mention any parameters or their purpose. It only explains the conceptual model of fee overrides, not how to use the event_ticker parameter or how pagination parameters interact. This leaves a significant gap in parameter understanding.
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 clearly identifies the tool as fetching event fee changes, with a specific HTTP endpoint. It adds context that these are overrides on the parent series' fee structure, which helps distinguish from the sibling tool kalshi_get_series_fee_changes. However, it starts with a repeated title and could be more explicit about the resource scope.
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 that this tool is for event-level fee overrides rather than series-level fees, giving some usage context. It does not explicitly state when to use this tool versus alternatives, nor does it mention pagination or other selection criteria. Sibling tools like kalshi_get_series_fee_changes exist, but the description does not directly compare or contrast.
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 destructiveHint=false, and the description mentions 'GET' which aligns with read-only behavior. It adds minimal context about 'historical track' but does not disclose pagination behavior, time range defaults, or other response details. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences. The first sentence states the action and resource, while the second provides the exact endpoint. The word 'Endpoint' is mildly redundant, but the description is front-loaded and free of unnecessary detail.
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?
With 7 optional filter parameters and no output schema, the description is too sparse to give the agent a full picture of the tool's capabilities. It doesn't explain what settlements are, how pagination works, or what the response contains. The schema covers parameters but lacks an overview that the description should provide.
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, so the description does not need to explain them. The description adds no parameter-specific semantics, which is acceptable given the schema's completeness. Baseline 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 clearly states the tool retrieves the member's settlements historical track and calls GET /portfolio/settlements. It distinguishes from siblings by focusing on settlements and the specific endpoint. The phrase 'Get Settlements Endpoint' is slightly redundant with the tool name but not misleading.
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 kalshi_get_fills or kalshi_get_trades. It does not mention use cases, exclusions, or prerequisites. While it implies usage for settlement history, it lacks explicit contextual direction.
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 destructiveHint=false, and the description does not contradict this. It adds the HTTP method and path (GET /portfolio/orders/{order_id}), which confirms the read-only nature but provides no details on return format, errors, or authentication. With annotations covering the safety profile, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loaded with the purpose. It avoids unnecessary fluff, though 'Endpoint' is slightly redundant. Overall, it is efficient and easy to scan.
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?
This is a simple read-only getter with one parameter and no output schema. The description provides the endpoint and a basic purpose, but lacks any explanation of what the response contains or how it relates to other order endpoints. It is marginally adequate for the complexity level.
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% with order_id described as 'Order ID'. The description only references the parameter in the endpoint path, adding no new meaning beyond the schema. Baseline score of 3 is appropriate because the schema fully documents the parameter.
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 clearly states the tool retrieves a single order, using 'Get' as the verb and specifying 'single order' to distinguish from list endpoints like kalshi_get_orders. The inclusion of the endpoint path reinforces the resource. Minor redundancy with 'Endpoint' but overall specific.
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?
No guidance on when to use this tool versus kalshi_get_orders or other related tools. The 'single order' wording implies the scope but does not explicitly state exclusions or alternatives, so the agent gets no directional support.
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?
Annotations indicate this is a write operation (readOnlyHint false) and non-destructive. The description adds no behavioral details beyond the purpose, such as authentication, balance requirements, or side effects, so it offers little beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It's front-loaded and efficient.
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?
Given there's no output schema and this is a mutating operation, the description should explain what happens on success, prerequisites, or return values. It only states the endpoint, leaving the response and behavioral context undocumented.
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 schema descriptions cover 100% of parameters, so the description doesn't need to compensate. The description doesn't add parameter details, but baseline 3 applies given high schema coverage.
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 clearly states the tool transfers funds within the same account, using a specific verb and resource. The phrase 'within the same account' differentiates it from subaccount transfer tools, though it doesn't explicitly name alternatives.
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 for intra-account transfers but provides no explicit guidance on when to use this vs. subaccount transfer or other alternatives. Context is present but exclusions are missing.
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?
Annotations indicate readOnlyHint=true and destructiveHint=false, so the agent knows it's a safe, read-only operation. However, the description adds no additional behavioral context such as response format, pagination, or side effects. The only extra is the HTTP endpoint, which is not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but includes a redundant first sentence ('Get Exchange Schedule Endpoint for getting the exchange schedule') which essentially restates the tool name. The second sentence adds a useful endpoint detail.
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 no parameters and read-only annotation, but the description does not describe what the exchange schedule contains or what the response looks like. Since there is no output schema, the agent lacks information about the return value, making this minimally adequate but not 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 input schema has no parameters, so there is nothing for the description to explain. The baseline for 0 parameters 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 clearly states the tool retrieves the exchange schedule and specifies the exact endpoint (GET /exchange/schedule). This is a specific verb+resource that distinguishes it from sibling tools like kalshi_get_exchange_status which deals with status rather than the schedule.
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?
There is no guidance on when to use this tool versus alternatives. It simply states what it does without mentioning alternative approaches, prerequisites, or use cases.
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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds some context by explaining what incentives are and the underlying API endpoint ('Calls GET /incentive_programs'), but it does not disclose additional behavioral details such as pagination behavior, rate limits, or what fields are returned. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: 'Get Incentives List' is awkwardly phrased and partially repeats the tool name. It uses three sentences; the third sentence about the API endpoint could be seen as extra, though it adds specificity. The structure is front-loaded with the purpose, but the wording could be tightened.
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?
For a read-only list tool with good annotations and fully described parameters, the description is reasonably complete. It explains what incentives are and mentions the endpoint. However, it does not describe the return format or any pagination behavior, which could be relevant given the limit/cursor parameters. Since no output schema exists, a bit more detail about the response would have been helpful.
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 having its own description and enums. The description only says 'optional filters,' which adds no meaning beyond the schema. Since the schema fully documents all parameters, the baseline of 3 is appropriate; the description provides no extra semantic value.
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 clearly states the tool's purpose: 'List incentives with optional filters' and clarifies what incentives are ('rewards programs for trading activity on specific markets'). The verb 'Get/List' and the resource 'incentives' are specific, and the tool name aligns with the resource, distinguishing it from sibling tools that handle other resources. However, the awkward phrasing 'Get Incentives List' slightly detracts from otherwise clear purpose clarity.
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—it tells you what the tool does and that filters are optional—but it does not explicitly state when to use this tool over alternatives or mention any exclusions. No comparison with sibling tools is provided, so guidance is only implied by the resource name and description.
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 discloses that the tool transfers funds and calls POST /portfolio/subaccounts/transfer, which conveys a mutating action. Annotations already indicate readOnlyHint=false and destructiveHint=false, but the description does not elaborate on potential side effects, error conditions, or whether the transfer is reversible. It adds a bit of context beyond annotations but not rich behavioral detail.
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 concise and well-structured: three sentences covering purpose, subaccount ranges, and exchange_index, followed by the endpoint. No redundant information or filler. Every sentence contributes meaningful detail.
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 mutation tool with no output schema and sparse annotations, the description covers the key domain concepts: subaccount numbering, exchange_index, and the POST endpoint. It does not mention idempotency (though the schema covers client_transfer_id) or clarify the distinction from sibling transfer tools, leaving a small gap in context.
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%, so the schema already documents all parameters. The description adds clarifying context for subaccount numbering and exchange_index (e.g., 'Set exchange_index to apply the transfer on a specific exchange shard'), which is helpful but not essential given the schema's thoroughness. It earns a baseline 3.
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 clearly states the tool's function: 'Transfers funds between the authenticated user's subaccounts.' It provides a specific verb and resource, and adds detail about subaccount numbering. However, it does not differentiate from sibling tools like kalshi_intra_exchange_instance_transfer, which also involves transfers.
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 gives parameter-level guidance ('Use 0 for the primary account, or 1-63') and explains exchange_index, but it lacks any guidance on when to choose this tool over alternatives. No exclusions or alternative recommendations are provided.
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 indicate readOnlyHint=false and destructiveHint=false, so the write nature is known. The description adds useful context about rate limits and tier-based write budgets, and specifies the HTTP endpoint. However, it does not disclose potential side effects like financial risk or partial-failure behavior, so it only partially compensates beyond 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 two sentences, front-loaded with purpose, and includes a relevant link and endpoint. Every sentence provides useful information without fluff, making it appropriately concise and well-structured.
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?
Despite the complex batch-order schema, the description is thin. It lacks information about response format, error handling, partial-failure semantics, or prerequisites like authentication/funding. While the input schema is rich, the absence of output schema and minimal description leave the tool incomplete for an agent to use confidently.
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 describe the 'orders' parameter or its structure. It merely says 'batch of event-market orders', adding no meaning beyond the input schema. Since schema coverage is low and the description does not compensate, the parameter semantics are poor.
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 submits a batch of event-market orders using the V2 request/response shape, which distinguishes it from sibling tools like single-order creation or batch cancellation. The verb 'submit' and resource 'orders' are specific, and the mention of 'event-market' adds 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 this is the batch-order endpoint, so an agent can infer to use it when multiple orders need to be placed. However, it does not explicitly compare alternatives like kalshi_create_order_v2 or mention when not to use it, lacking clear 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=true and destructiveHint=false, establishing the safety profile. The description adds the HTTP method and endpoint path, which is minor extra context, but it does not disclose any additional behavior such as response format, caching, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Get Exchange Status Endpoint for getting the exchange status' repeats the same idea. The endpoint information is valuable, but the phrasing could be tighter.
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 status endpoint, the description is adequate. However, since there is no output schema, it would benefit from a hint about what the response contains (e.g., 'returns a timestamp and status indicator'), but the current text is acceptable for a simple status check.
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 is empty, so the baseline is high. The description adds no parameter details because none exist; it correctly focuses on the action rather than 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 retrieves exchange status, with a specific verb ('Get') and resource ('Exchange Status'). It also identifies the exact API endpoint (GET /exchange/status), distinguishing it from sibling tools like kalshi_server_info or kalshi_get_exchange_schedule.
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?
No guidance is provided on when to use this tool versus alternatives. It does not mention related tools such as kalshi_server_info or kalshi_get_exchange_schedule, nor does it describe any prerequisites or typical use cases.
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 and destructiveHint=false, covering safety. The description adds valuable non-obvious behavior: only yes and no bids are returned (no asks), with a clear explanation of the binary market equivalence. This goes beyond the annotations and helps the agent predict the response shape. No annotation contradiction is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately sized but starts with a redundant phrase ('Get Market Orderbook Endpoint for getting the current order book') and ends with an ellipsis, making it feel unfinished. The explanation of the bid/ask equivalence is valuable but could be tightened. Overall, it is not as concise or polished as it could be.
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 complete schema coverage and safety annotations. The description adds essential context about the orderbook structure (price levels, quantities, order counts) and the rationale for bid-only responses, which is particularly useful since there is no output schema. It does not mention the depth parameter, but that is well-documented in the schema, so the description is sufficiently complete for this 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?
All parameters (ticker, depth) have complete descriptions in the input schema, so the schema does the heavy lifting (100% coverage). The description only mentions the ticker via the endpoint path and does not elaborate on depth or any parameter semantics beyond the schema. Thus, the description adds no extra parameter meaning, keeping this at the baseline of 3.
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 clearly states it gets the current order book for a specific market with specific verb ('Get') and resource ('Market Orderbook'). It also explains the bid-only content, making the purpose unambiguous. However, it does not explicitly contrast with the sibling tool 'kalshi_get_market_orderbooks' (plural), so it misses the distinguishing statement that would earn a 5.
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 provides context about the data returned and explains that asks are implicit from yes bids, which implies when this tool is useful. However, it does not explicitly state when to use this versus alternatives like the plural orderbook endpoint or the market endpoint, nor does it give exclusions. Usage guidance is largely implied rather than 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 destructiveHint=false, covering the safety profile. The description adds the API endpoint and the scope ('for all subaccounts'), but does not provide additional behavioral context such as response format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief but contains redundancy: the leading 'Get Subaccount Netting' restates the tool name, and the phrasing is awkward. The useful content is compact but not as polished as it could be.
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, zero-parameter tool, the description adequately conveys what it does and provides the API path. However, it does not describe the return structure, which could 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.
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%, so there is nothing to explain. The baseline for 0 params is 4, and the description does not need to add parameter information.
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 'Gets the netting enabled settings for all subaccounts,' providing a specific verb and resource. It implicitly distinguishes itself from the sibling 'kalshi_update_subaccount_netting' by focusing on retrieval.
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?
No guidance is given on when to use this tool versus alternatives such as 'kalshi_update_subaccount_netting' or other subaccount getters. The description does not mention any prerequisites or exclusion criteria.
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, so destructive behavior is known. The description adds the HTTP DELETE method, the specific endpoint path, and a rate-limit constraint on batch size, which are useful. However, it does not disclose partial success behavior or error handling, so it only marginally adds to the annotation coverage.
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 three-sentence description is efficient and well-structured: it front-loads the purpose, then adds a rate-limit caveat, and finally states the HTTP endpoint. Every sentence earns its place with no redundancy or filler.
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 description covers purpose, HTTP method, and a key constraint, but because there is no output schema, it fails to describe the response shape (the phrase 'V2 response shape' is vague) or behavior on partial cancellation. Given the nested array complexity, a more complete description would benefit from mentioning response semantics.
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 single top-level parameter 'orders' has 100% schema description coverage, including detailed explanations for nested fields (order_id, subaccount, market_ticker, exchange_index). The description itself adds no parameter-specific meaning, so a baseline 3 is appropriate per the rubric.
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 cancels a batch of event-market orders using the V2 response shape, and it gives the exact HTTP DELETE endpoint. This distinguishes it from the single-order cancel tool (kalshi_cancel_order_v2) and the batch create tool (kalshi_batch_create_orders_v2) via the verb 'cancelling' and the word 'batch'.
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 for batch cancellations and mentions the batch size constraint tied to rate limits, but it does not explicitly say when to prefer this over kalshi_cancel_order_v2 or when not to use it. The rate-limit link gives context but no explicit 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds minimal behavioral context (mentions 'raw and formatted forecast numbers' and the GET method) but does not disclose potential rate limits, pagination, or response format details.
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 concise at two sentences and front-loads the purpose. The first sentence is slightly redundant ('Get... for getting...'), which prevents a perfect score, but it is efficient and free of unnecessary detail.
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 tool with complete schema coverage and safety annotations, the description is adequate. It clearly states the endpoint and the type of data returned, though it does not detail the response structure, which is acceptable given no output schema and the straightforward nature of the 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?
All six parameters have descriptions in the schema (100% coverage), so the schema already documents their meaning. The description adds no additional parameter-level semantics beyond what is already 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 clearly names the specific resource (Event Forecast Percentile History) and action (Get), distinguishing it from sibling tools like kalshi_get_event by its focus on historical forecast values at percentiles. The inclusion of the exact API endpoint further reinforces the purpose.
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?
Usage context is implied by the resource type and endpoint, but there is no explicit guidance on when to choose this tool over alternatives or any exclusions. It does not reference sibling tools or state conditions for use.
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 destructiveHint=false, covering the safety profile. The description adds context about the return content (filters, scopes, competitions, ordered sports) but does not disclose further behavioral traits like pagination, rate limits, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is poorly structured and repetitive. It starts with 'Get Filters for Sports' which duplicates the tool name, then immediately repeats the idea in 'Retrieve available filters organized by sport.' There is a missing space and period after 'Sports' and 'Calls' lacks a subject. The content is not concise and would benefit from rewriting.
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 has no parameters, no output schema, and basic read-only annotations, the description is fairly complete. It explains what the endpoint returns and mentions the API call, which is sufficient for a simple retrieval tool, though it lacks extra detail about the structure of the response.
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 baseline is 4. The description provides useful information about what is returned, and since there are no parameters to document, no additional semantic explanation 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 states the tool retrieves filters for sports, with the specific scope of organizing filters by sport and including scopes and competitions. It also distinguishes itself from sibling tools by mentioning the ordered list of sports for display, making the purpose specific and non-tautological.
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 explains what the tool does but does not explicitly state when to use it versus alternatives. It implies usage for retrieving sport filter options, but lacks explicit when/when-not guidance or mention of alternative 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds conceptual context (price-time priority for queue position) and the GET endpoint, but does not disclose pagination, response structure, or default subaccount behavior beyond schema. With annotations covering safety, this 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with useful definition, but the first sentence contains redundancy ('Get Queue Positions for Orders' then 'for getting queue positions'). Still, it is front-loaded and not overly verbose.
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?
The description covers the core concept, endpoint, and scope (all resting orders), which is sufficient for a read-only query with optional filters. No output schema exists, but the description doesn't explain return shape; nevertheless, the combination of annotations and schema provides enough context for most use cases.
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% with clear descriptions for all three optional parameters. The description does not add parameter-specific guidance, which is acceptable given high coverage; it only states the general purpose of all resting orders.
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 fetches queue positions for all resting orders, with a specific verb and resource. It differentiates from singular variants by specifying 'all resting orders' and also defines the meaning of queue position, leaving no ambiguity about its function.
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 phrase 'all resting orders' implies the tool is for querying all orders rather than a specific one, but it does not explicitly mention alternatives such as the singular get_order_queue_position tool or specify when to use filtering parameters. Guidance is implied, 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 destructiveHint=false, and the description reinforces this with 'Calls GET /series'. It adds contextual value by explaining what a series is, but does not disclose additional behaviors like pagination, rate limits, or response size. With annotations covering the safety profile, a score of 3 is appropriate.
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 compact and front-loaded with the endpoint purpose, followed by a helpful example. The first sentence is slightly redundant ('Get Series List Endpoint for getting data') but the overall length is appropriate and every sentence adds value. No unnecessary fluff.
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 description explains the core concept of a series and states the endpoint's purpose, which is useful for a discovery tool. However, with no output schema and only 40% parameter documentation, it lacks guidance on how filters behave, what the response contains, or any pagination/ordering semantics. It is minimally sufficient but not rich enough for complex filtering scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description does not compensate. It generically mentions 'specified filters' but provides no detail on what tags, category, include_product_metadata, or min_updated_ts do. The two parameters that have descriptions in the schema are not elaborated further, leaving the agent without meaningful guidance for the other three.
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 'Gets data about multiple series with specified filters' and explicitly identifies the endpoint ('Calls GET /series'). It differentiates this list/browse endpoint from sibling tools like get_series (single series) and provides an illustrative example of series types, leaving no doubt about its 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 states the tool allows you to 'browse and discover available series templates by category', giving clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the use case is well implied and distinct from related single-series endpoints.
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 destructiveHint=false, so the description adds the endpoint call and pagination detail. However, it does not disclose auth requirements, rate limits, or transfer-specific behaviors beyond what annotations cover. No contradiction found.
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 short and front-loaded with the tool name, but the first phrase 'Get Subaccount Transfers' is redundant with the tool name. Overall it is efficient and conveys key information in two sentences.
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 paginated list tool with read-only annotations and full schema coverage, the description is sufficient. It specifies the endpoint and the resource, making the tool's purpose and behavior clear despite lacking an 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 coverage for parameters is 100% with descriptions for limit and cursor already in the schema. The description only mentions 'paginated' without adding new semantic detail, matching the baseline for full schema coverage.
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 'Gets a paginated list of all transfers between subaccounts for the authenticated user', specifying both the action and the resource. It distinguishes itself from sibling tools like kalshi_apply_subaccount_transfer by focusing on read-only retrieval of transfers.
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 for listing subaccount transfers but does not explicitly mention alternatives or when not to use it. It provides context about pagination and the authenticated user, but lacks exclusionary guidance relative to sibling tools.
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 and destructiveHint=false, so the description is not required to restate safety. It adds meaningful behavioral context: the timestamp is approximate, there is typically a short delay, and it specifies exactly which data endpoints are covered. This goes beyond annotations and helps the agent understand the reliability and scope of the value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and not tightly front-loaded. The opening 'Get User Data Timestamp' is a restatement of the tool name, and the delay/WebSocket context, while useful, is placed before the core explanation. The description could be more concise by stating the purpose first and trimming redundancy, though it is not excessively long.
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 timestamp endpoint with no output schema, the description provides sufficient context: it explains what the timestamp represents, which endpoints it validates, and notes the approximate nature. It does not specify the exact return format, but with no output schema and a simple value, this is reasonably complete. The context about delays and WebSocket adds operational value.
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% (vacuously, since there are no properties). No parameter-level explanation is needed. The description does not need to compensate for undeclared parameters, so the baseline of 4 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 clearly identifies the tool's purpose: providing an approximate timestamp for when user data (balance, orders, fills, positions) was last validated. It names the specific endpoints covered and the HTTP call. However, it does not explicitly contrast itself with sibling tools, so it falls slightly short of full distinction.
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 includes usage context: there is a delay in API data, and it recommends combining responses with WebSocket data for accuracy. This implies when the timestamp might be useful, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The guidance is more about API usage in general than about this specific tool's selection.
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, so the destructive nature is known. The description adds the HTTP method/path and the reduced response shape, which is useful technical context, but it does not disclose other behavioral traits such as irreversibility, prerequisites, or error behavior. It adds some value beyond annotations but not rich detail.
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 three sentences long, front-loaded with the tool's purpose, and every sentence contributes information (endpoint, response shape, HTTP method). 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 single-order cancellation tool with four parameters and no output schema, the description provides the essential action, endpoint, and response shape. It leverages schema descriptions for parameters and annotations for destructive behavior. Minor gaps include not explaining when to use V2 vs. batch cancel, but the overall context is sufficient for a well-defined operation.
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 75%, and most parameters have clear descriptions in the schema (e.g., subaccount, market_ticker). The tool description does not add additional meaning beyond what the schema provides, so it earns the baseline score for high coverage. The description mentions the return fields but not parameter usage details.
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 tool as the V2 endpoint for cancelling event-market orders, using a specific verb ('cancelling') and resource ('orders'). It distinguishes itself from related tools like batch_cancel_orders_v2 by emphasizing the V2 response shape and the specific return fields.
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 use for single order cancellation with the V2 response shape, but it does not explicitly state when to prefer this over alternatives such as batch_cancel_orders_v2 or the original cancel endpoint. No exclusions or alternative options are mentioned, leaving the usage context somewhat implicit.
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?
With annotations already declaring readOnlyHint=true and destructiveHint=false, the description adds useful context: returns values in cents, requires 'read::portfolio_balance' scope, and calls a specific endpoint. This goes beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, information-dense sentences. No fluff, each sentence contributes purpose, output unit, auth, and endpoint details. Well-structured and front-loaded.
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 endpoint with no required parameters and no output schema, the description covers the essentials: what it returns, in what units, and the auth scope. Could mention response field names but not necessary for invocation.
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 schema provides descriptions for both parameters (subaccount and exchange_index), and the description does not elaborate on them. With 50% schema coverage and no required params, the baseline 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 clearly states the tool's function: getting the balance and portfolio value of a member, with values in cents. It also specifies the API endpoint, distinguishing it from sibling tools like kalshi_get_subaccount_balances.
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?
No explicit guidance on when to use this tool versus alternatives. The scope requirement is mentioned but not framed as a usage condition. No mention of alternative tools for similar balance queries.
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 destructiveHint=false, covering the safety profile. The description adds the specific endpoint path and the scope of aggregation, which is useful context, but it does not disclose any additional behavioral traits such as rate limits, timezone handling, or response format. With annotations present, this is acceptable 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?
Two concise sentences: one for purpose and one for the exact endpoint. No filler or redundancy. Every word earns its place.
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 data retrieval tool with rich schema and annotations, the description is sufficient for an agent to understand what the tool does and select it appropriately. It includes the aggregation scope and endpoint, but omits details about return format or any constraints on the time range, though those are less critical given the 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%, so the baseline is 3. The description does not elaborate on parameters, but the schema already provides clear descriptions for all five parameters, including the enum for period_interval. Description adds no extra semantic value 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 clearly states it returns aggregated candlestick data across all markets for a specific event, using the verb 'Get' and identifying the specific endpoint. This distinguishes it from the sibling tool kalshi_get_market_candlesticks, which likely targets a single market.
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 for event-level candlestick data ('across all markets corresponding to an event'), but it does not explicitly contrast this with market-level alternatives or state when not to use it. No alternative tools are named, so guidance is implied rather than 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 destructiveHint=false, so the safety profile is covered. The description adds context about events being dynamically created and calls the GET endpoint, but does not disclose pagination behavior, rate limits, or other operational details. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains redundancy: 'Get Multivariate Events' and 'Retrieve multivariate (combo) events' say the same thing. The overall length is acceptable, but the wasted repetition prevents a higher score.
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 endpoint with a comprehensive schema and annotations, the description adequately covers the core purpose and primary filters. However, it lacks explicit differentiation from sibling event tools and does not guide on pagination or nested market options, though these are in the 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%, so the baseline is 3. The description mentions filtering by series and collection ticker, which maps to two parameters, but adds no additional meaning beyond the schema for limit, cursor, or with_nested_markets.
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 resource as multivariate (combo) events with the verb 'Get'/'Retrieve'. It distinguishes from sibling event tools by emphasizing the dynamic creation from collections and filtering by series/collection ticker.
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?
It provides clear context for when to use this tool—when multivariate/combo events are needed—but lacks explicit exclusions or alternatives. The description implies usage rather than detailing when not to use it versus kalshi_get_events or other siblings.
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 indicate a safe read operation, and the description adds meaningful context by explaining the return structure (a mapping of series categories to tags) and confirming the HTTP method. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but contains redundancy: 'Get Tags for Series Categories' and 'Retrieve tags organized by series categories' say nearly the same thing. It also embeds the title-like phrase awkwardly. A cleaner structure would merge these into one sentence.
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 no-input, read-only tool with existing annotations and no output schema, the description covers the essential purpose, return value, and endpoint. It does not mention alternatives or exclusions, but given the tool's simplicity, it is adequately 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, and the schema fully covers this (100% coverage). The description itself doesn't need to explain parameters, and the baseline of 4 for no-parameter tools is appropriate here.
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 retrieves tags organized by series categories and returns a mapping. It specifies the endpoint (GET /search/tags_by_categories) and the resource, making it distinct from sibling tools that focus on other data types.
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?
No explicit usage guidance is provided. The phrase 'can be used for filtering and search functionality' describes the data's purpose, not when to call this tool versus alternatives like kalshi_get_filters_for_sports. There is no mention of when to use it or when not to use it.
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 read-only and non-destructive hints are already provided by annotations. The description adds the HTTP method and endpoint, which is useful but minimal. It doesn't describe pagination behavior, response format, or any caveats beyond the schema parameters.
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 wasted words. The first states purpose, the second gives the exact API endpoint. Compact and front-loaded, every sentence earns its place.
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 pagination params, the description plus schema and annotations are adequate. It lacks an output schema, but the description implies the return is withdrawal history. It could mention pagination behavior, but the schema already covers it, so this is sufficient.
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%—both limit and cursor have detailed descriptions in the schema. The tool description doesn't add any additional parameter context, so it relies on the schema, which already handles semantics. 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 tool retrieves the member's withdrawal history, with a specific verb 'Get' and resource 'withdrawals'. It also names the exact endpoint (GET /portfolio/withdrawals), distinguishing it from sibling tools like deposits or balance.
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 withdrawal history) but doesn't explicitly compare it to alternatives or state when not to use it. Sibling tools like deposits are obvious alternatives, but no exclusions or differentiators are mentioned.
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 only indicate readOnly=false and destructiveHint=false. The description adds valuable behavioral context: explains that 'count' is the updated total/max fillable count (already filled + desired resting), states the HTTP method and path, and clarifies that behavior matches v1. This goes well beyond annotation-only information.
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 three sentences, each earning its place: purpose, count semantics, and endpoint/shape clarification. No fluff or repetition, and the most important information is front-loaded.
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 schema thoroughly documents all 9 parameters, but there is no output schema and the description does not mention the response shape or error conditions. It also does not distinguish this from the sibling kalshi_decrease_order_v2, which could cause selection confusion. Operational context is partially complete but has clear gaps.
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 detailed parameter docs. The description text mostly reinforces what the schema already states about 'count' semantics. Since the schema handles parameter meaning, the description adds little incremental value, justifying 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 clearly states the tool's purpose: amending the price and/or max fillable count of an existing event-market order. It distinguishes itself from siblings by using the specific verb 'amend' and noting the V2 request/response shape, as well as referencing the exact endpoint. This makes it easy to tell apart from create/cancel/decrease tools.
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?
Usage is implied: if you need to change an existing order's price or count, use this tool. The description mentions consistency with v1 endpoints but does not explicitly differentiate from alternatives like kalshi_decrease_order_v2 or cancel+create workflows. No exclusions or when-not-to-use guidance is provided.
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 discloses the HTTP method and endpoint path and notes the future deprecation, but it does not cover authentication requirements, live trading implications, or error behavior. Annotations only provide basic read/write hints, so the description adds some context but not enough for a live-order tool.
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?
Three concise sentences deliver purpose, migration guidance, and endpoint info without redundancy. Every sentence contributes a distinct, useful piece of information.
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 complex (14 parameters, no output schema), yet the description omits what response to expect, preconditions like API credentials or available funds, and typical failure modes. It covers the endpoint and migration but leaves gaps for a live order submission 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 description does not explain any parameters, but the input schema already provides detailed descriptions for most fields (e.g., `side`, `count`, `price`, `time_in_force`, `self_trade_prevention_type`). With ~64% schema coverage, the schema carries the parameter burden, and the description adds no extra meaning.
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 it creates event-market orders using the V2 request/response shape, identifies the specific endpoint path, and distinguishes itself from the legacy endpoint via deprecation guidance. This differentiates it from sibling tools like kalshi_batch_create_orders_v2.
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?
It explicitly advises migration from the legacy `/portfolio/orders` endpoint, providing a clear directive on when to use this tool. However, it does not mention alternatives such as `kalshi_batch_create_orders_v2` for multiple orders or `kalshi_paper_order` for testing, so exclusions are incomplete.
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 description doesn't need to repeat safety. It adds useful context about the GET endpoint path and the historical cutoff behavior, but doesn't discuss response structure or edge cases. With annotations covering the safety profile, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the primary purpose and includes relevant domain context. The two sentences explaining what an event is are helpful but slightly verbose; overall, it remains tight and no sentence is wasted.
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 GET tool with two well-documented parameters, this description is complete enough: it provides the endpoint path, the key historical cutoff nuance, and domain background. No output schema exists, but the absence of return format details 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters with detailed descriptions (100% coverage), so the baseline is 3. The description reinforces event_ticker by mentioning 'by its ticker' but adds no extra meaning beyond the schema, especially for with_nested_markets.
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 gets event data by ticker, defines what an event is, and highlights a distinguishing capability (all events accessible, even historical ones). This differentiates it from sibling event-specific tools like kalshi_get_event_metadata or kalshi_get_events.
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 provides clear context for when to use the tool: to retrieve a single event's data via its ticker. It also notes that all events are accessible, including those past the historical cutoff. However, it does not explicitly mention alternatives or when not to use it, stopping short of 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's mention of calling GET provides only marginal additional behavioral context. It does not disclose error behavior, permissions, or rate limits. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences are compact, but the first sentence is slightly redundant: 'Get Event Metadata Endpoint for getting metadata...' repeats the tool name and purpose. Still, the description is focused and front-loaded with the key action.
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 metadata-fetching tool with one parameter and an annotation indicating read-only safe operation, the description provides the endpoint, return scope (metadata only), and differentiates it from full-event retrieval. It omits response structure, but that is not essential for this simple context.
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 schema fully covers the only parameter (event_ticker) with a description, and the description's reference to 'by its ticker' adds no distinct meaning beyond the schema. With high schema coverage, the 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 it retrieves metadata for an event by its ticker, and explicitly says it returns only the metadata information, distinguishing it from sibling kalshi_get_event (full event data). The HTTP endpoint is also given, reinforcing the exact resource.
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 conveys the intended use case by noting it returns only metadata, which implies using this tool when metadata alone is needed versus the full event from kalshi_get_event. However, it does not explicitly name alternatives or state exclusions, so it stops short of full guidance.
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is established. The description adds the API path (GET /markets/{ticker}) and domain context about market attributes, but it does not disclose other behaviors such as error handling, rate limits, or data completeness. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three sentences that are front-loaded with purpose and include domain context and the endpoint. Slight redundancy in 'Get Market Endpoint for getting data' but not enough to distract. Well-structured for quick comprehension.
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 one parameter and no output schema, the description covers purpose, domain concept (binary outcome market with prices, volume, settlement rules), and the endpoint. It does not detail error scenarios, but that is not critical for this straightforward operation.
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 description for the only parameter ('ticker': 'Market ticker'), covering 100% of parameters. The description reiterates that the tool fetches by ticker but does not add details about ticker format, examples, or accepted values 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 clearly states the tool gets data about a specific market by its ticker, with a concrete verb ('Get') and resource ('market'). It differentiates from siblings like kalshi_get_markets (plural) by emphasizing 'a specific market.' The underlying endpoint is also specified.
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 a single market based on ticker, which is clear enough for most use cases. However, it does not explicitly name alternatives (e.g., kalshi_get_markets for multiple markets) or provide exclusion criteria, so it earns a 4 rather than 5.
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 and destructiveHint=false, and the description does not contradict this. It adds the useful behavioral nuance about historical data availability, which is meaningful context beyond the annotations. However, it does not describe response format or rate limits, but the bar is lower with readOnlyHint present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise but awkwardly phrased, e.g., 'Get Market Candlesticks Time period length of each candlestick in minutes.' It mixes purpose and parameter details in the opening, and the structure could be clearer. Still, it contains only essential information, though redundancy with the schema exists.
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?
With no output schema, the description should ideally explain what the response contains. It does not describe OHLCV fields or pagination, but it does note the historical cutoff and provides a link for details. Given the tool's simplicity and read-only nature, this is adequate but not 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?
Schema description coverage is 100%, so the schema carries full parameter details. The description repeats the period_interval valid values (1, 60, 1440) without adding new meaning. It does not introduce any additional parameter semantics beyond what the schema already provides.
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 clearly states the tool gets market candlesticks for a specific market via a concrete endpoint, providing a specific verb and resource. It does not explicitly differentiate from sibling tools like kalshi_batch_get_market_candlesticks, though the name and endpoint imply single-market scope.
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?
Explicitly provides an alternative for historical data: 'Candlesticks for markets that settled before the historical cutoff are only available via GET /historical/markets/{ticker}/candlesticks.' This tells the agent when NOT to use this tool and where to go instead, which is strong guidance.
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?
Beyond the readOnlyHint annotation, the description discloses key behavioral traits: it returns only yes bids and no bids (no asks), explains the binary market equivalence, and provides a concrete example. This adds significant context about the response structure and rationale.
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 somewhat lengthy but each sentence adds value, explaining the order book behavior and example. It is front-loaded with the core purpose. A slightly more concise version could earn a 5.
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?
There is no output schema, so the description carries the burden of explaining return shape. It partially does so by describing yes/no bids and price levels, but the truncated ending leaves the quantity field incompletely specified. Overall, it provides enough context for a read-only, single-parameter 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 schema already fully documents the 'tickers' parameter with a clear description and constraints. The description does not add parameter-specific details beyond the schema, 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 tool fetches the current order books for multiple markets in a single request, using a specific verb and resource. It distinguishes from the sibling singular orderbook tool by emphasizing 'multiple markets' and the single-request efficiency.
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 for fetching orderbooks for multiple markets, but does not explicitly contrast with the alternative kalshi_get_market_orderbook for a single market. It lacks clear when-to-use vs alternatives guidance.
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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the endpoint 'GET /milestones/{milestone_id}', which is mildly informative but doesn't disclose behaviors like return format, errors, or data scope. No contradiction with annotations, but minimal added value beyond what annotations provide.
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 two sentences and concise. The first sentence is slightly redundant ('Get Milestone Endpoint' + 'getting data about'), but it still conveys the purpose. The second sentence provides the concrete API call, which is useful. No extra fluff, so it earns a solid score.
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 a single parameter and strong annotations, the description is reasonably complete. It doesn't explain the response structure, but no output schema exists, and the read-only nature plus the clear endpoint partially compensate. It could mention what 'milestone data' includes, but the tool is simple enough that this is a minor gap.
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% with the parameter 'milestone_id' described as 'Milestone ID'. The description doesn't add meaning beyond the schema—it merely restates that the milestone is fetched 'by its ID'. With high schema coverage, the description doesn't need to compensate significantly, so a 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 it gets data for a specific milestone by ID, using the verb 'getting' with the resource 'milestone'. It distinguishes from the sibling kalshi_get_milestones by emphasizing 'specific' and 'by its ID', making it unambiguous which tool to use for a single milestone.
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 usage: you need a milestone ID to fetch that specific milestone. It doesn't explicitly mention alternatives like kalshi_get_milestones for listing all, but the distinction is clear enough from the wording. This is more than just implicit; it sets the context for when to use this tool.
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 destructiveHint=false, so the agent knows this is a safe read operation. The description adds the HTTP endpoint and a conceptual explanation of series, but does not disclose response behavior, errors, or other operational details. It provides moderate value beyond annotations.
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 front-loads the purpose and then adds useful explanatory context about what a series is. While the series explanation is somewhat verbose, it is not excessive and helps the agent understand the domain. The endpoint call is a minor 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 getter with two parameters and no output schema, the description covers the essential information: what the tool does, the key series concept, and the endpoint. It does not describe the response format, but the absence of an output schema reduces that burden. It is reasonably complete for an agent.
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% and both parameters are well-described in the schema. The description does not add significant parameter semantics beyond what is already in the schema, so the baseline 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 clearly identifies the action (getting data about a specific series by its ticker) and distinguishes it from sibling tools like kalshi_get_series_list by emphasizing specificity. It also provides a clear definition of what a series is, reinforcing the tool's 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 implies when to use this tool (when you have a specific series_ticker and need details about that series template) and provides context that differentiates it from list-style endpoints. However, it does not explicitly name alternative tools or state exclusions, so it falls short of a 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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the fact that it calls a GET endpoint, which is consistent with the annotations. However, it does not disclose any additional behavioral context such as error handling, rate limits, or specific return structure. With annotations covering the safety profile, a 3 is warranted.
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 two sentences long, direct, and front-loaded with the tool's purpose. The phrase 'Get Structured Target Endpoint' is somewhat redundant with the tool name, but it does not repeat unnecessary information. The explicit endpoint call is a useful addition. It is concise and well-structured, earning a 4 for efficiency with minor 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 tool with a single parameter and no output schema, the description is fairly complete. It identifies the resource, the endpoint, and the input. However, it does not explain what a 'structured target' is or what fields the returned data contains, which could be helpful given the niche term. The simplicity of the tool and the presence of annotations make this a minor gap, so a 4 is given.
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 the single parameter structured_target_id, describing it as 'Structured target ID.' The tool description adds no further detail about the parameter format, source, or examples, but the schema already documents it. Baseline 3 is appropriate since the schema does the heavy lifting.
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: 'Get Structured Target Endpoint for getting data about a specific structured target by its ID.' It uses the specific verb 'get' and the resource 'structured target by ID,' which distinguishes it from the sibling tool kalshi_get_structured_targets (plural) that presumably lists all targets. The explicit endpoint call reinforces the 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 implies the use case: when you need data about a specific structured target identified by its ID. It does not explicitly mention when not to use it or name alternatives like kalshi_get_structured_targets for listing, but the context is clear and unambiguous. A score of 4 is appropriate for 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 destructiveHint=false, indicating a mutating but non-destructive operation. The description adds the specific endpoint (PUT /portfolio/subaccounts/netting) and the subaccount number range, but does not disclose additional behaviors such as response format, permissions, or side effects. This aligns with the annotated safety profile and adds limited extra context.
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 relatively concise at three sentences, but the first phrase 'Update Subaccount Netting' is redundant with the tool name and the following sentence. The inclusion of the API endpoint is useful and the structure is front-loaded with the primary action. Minor redundancy prevents a perfect score.
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 two-parameter mutation tool, the description covers the action, the resource, the subaccount numbering, and the endpoint. However, with no output schema, it does not explain what the response will contain (e.g., success message or updated setting). Despite this, the overall context is sufficient for a basic update operation.
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 complete descriptions for both parameters (subaccount_number and enabled) with 100% coverage. The description repeats the subaccount numbering guidance ('Use 0 for the primary account, or 1-63') without adding new meaning beyond the schema. Since the schema covers everything, the baseline 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 clearly states the tool's function: 'Updates the netting enabled setting for a specific subaccount.' It identifies the specific resource (netting setting) and action (update), and distinguishes itself from siblings like kalshi_get_subaccount_netting by being the mutation counterpart.
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 provides clear context for when to use this tool: to modify netting settings for a subaccount. It does not explicitly mention alternatives or exclusions, but the sibling tools and the verb 'updates' imply its distinct role. It also gives practical guidance on subaccount numbering (0 for primary, 1-63 for subaccounts).
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?
With no annotations, the description carries the behavioral burden. It describes the tool as showing schema, implying a read-only behavior, but doesn't state whether it fetches live data or is fully local, nor any potential errors. Basic transparency is present, but depth is limited.
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, front-loaded with the primary purpose, each sentence earning its place. No fluff, clear and efficient.
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 introspection tool with no output schema, the description covers purpose, scope, and usage reasonably well. It doesn't detail error cases or specific response format, but given the tool's simplicity and clear sibling context, it's nearly 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?
Schema coverage is 100%, with the single parameter 'endpoint' already having a detailed description (tool name, operation ID, or path with examples). The description adds no further parameter-specific meaning, so it appropriately sits at the baseline.
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 shows the full input schema for one Kalshi endpoint, listing every path, query, and body field with type and description. It distinguishes itself from siblings like kalshi_call_endpoint (which executes) and kalshi_list_endpoints (which lists endpoints).
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?
Explicitly says 'Look here before calling kalshi_call_endpoint', giving a clear when-to-use context. It doesn't explicitly mention alternatives or when not to use, but the primary use case is strongly conveyed.
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?
No annotations are provided, so the description carries the full burden. It discloses the tool's scope (searches all endpoints, including non-loaded ones) and return fields (method, path, toolset, loaded status). However, it does not mention auth, rate limits, pagination, or whether it makes a network call. For a simple discovery tool, this 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 two sentences, front-loaded with the core purpose. The first sentence defines what it does; the second gives usage guidance and return values. Every sentence earns its place with no redundancy or filler.
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?
With no output schema, the description compensates by listing the return fields (method, path, toolset, dedicated-tool status). It also provides the usage flow with kalshi_call_endpoint. For a search/discovery tool with 3 optional parameters, this is complete enough, though it could mention default limit behavior (handled by schema) or pagination.
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 67%, so the baseline is 3. The description does not add parameter-level detail beyond what the schema provides for 'search' and 'toolset', and it does not address 'limit' at all. The description's mention of 'keyword' aligns with the existing 'search' param description but adds no new semantics.
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: 'Search every Kalshi API endpoint, including ones not currently loaded as their own tool.' It uses a specific verb ('Search') and resource ('every Kalshi API endpoint'), and differentiates itself from siblings by explicitly covering endpoints that lack dedicated tools, with a clear relationship to kalshi_call_endpoint.
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?
Provides explicit usage guidance: 'Use this to find an endpoint by keyword, then call it with kalshi_call_endpoint.' This indicates when to use the tool (discovery) and names a companion tool for the follow-up. It does not explicitly mention when not to use it or enumerate alternatives, but the context is clear enough for an agent to select it appropriately.
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?
No annotations are present, so the description carries the full burden for behavioral disclosure. It mentions that dedicated tools validate arguments but does not disclose auth requirements, rate limits, potential side effects of raw calls, or error behavior–significant gaps for a generic passthrough tool.
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?
Three tight, front-loaded sentences deliver the core purpose, path base, and usage preference without any filler. Every sentence earns its place.
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 description is adequate for tool selection but not fully complete. There is no output schema, and no behavioral details about responses, authentication, or failure modes are provided. Given the tool's generic nature, more caveats about raw endpoint access would improve completeness.
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?
Schema coverage is 75%, and the description adds meaningful context: the base path for 'path' and a concrete example. The 'body' and 'query' schemas are self-explanatory. The method enum covers allowed values, though the description does not elaborate on method-specific nuances.
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 calls any Kalshi API endpoint directly, positioning it as a generic fallback. It distinguishes itself from the many dedicated sibling tools by noting it handles endpoints with 'no dedicated tool loaded.'
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?
Explicit guidance is provided: paths are relative to /trade-api/v2, with an example ('/markets'), and a clear preference is given to dedicated tools because they validate arguments. This tells the agent exactly when to use this tool instead of siblings.
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 indicate a non-read-only, non-destructive operation; the description aligns with that and adds useful behavioral details: subaccounts are numbered sequentially from 1, the limit of 63 numbered accounts, and the HTTP method POST. This goes beyond the annotations to explain what happens during creation.
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 compact and includes essential facts in a few sentences. However, it begins with a redundant 'Create Subaccount' heading that repeats the action from the following sentence, which slightly detracts from structure. Overall, it is efficient.
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 simple nature (one optional parameter, no output schema), the description adequately covers purpose, prerequisites, limits, and HTTP endpoint. It does not describe the response format, but that is a minor omission for a creation tool where the created resource's identity can be inferred from the numbering rules.
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 describes exchange_index with 100% coverage, including default behavior. The description does not mention this parameter, adding no semantic value beyond the schema. Since schema coverage is high, 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?
Description clearly states the action: 'Creates a new subaccount for the authenticated user.' The verb 'Create' and resource 'subaccount' are specific and distinguish it from sibling tools that update, transfer, or query subaccounts. The description leaves no ambiguity about the tool's function.
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?
Provides usage context by noting the Advanced API tier requirement and the maximum number of subaccounts (63 + primary). It does not explicitly name alternatives, but the creation action is self-evidently distinct from sibling tools. This is 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds valuable context about the historical cutoff and the exclusion of multivariate events, which are useful behavioral traits beyond the annotations. No contradictions exist.
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 relatively short and front-loaded with the core purpose ('Get all events'). It includes necessary caveats and alternatives without excessive detail. The only minor redundancy is starting with 'Get Events' immediately followed by 'Get all events', which slightly hurts 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 has 9 parameters and no output schema, the description provides sufficient context: it states the endpoint, exclusions, and historical cutoff behavior. It does not detail the response structure, but the tool name and schema strongly imply a list of events, and parameter descriptions cover pagination and filtering. Overall, it is complete enough for effective use.
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 9 parameters have detailed descriptions in the schema (100% coverage), so the description does not need to repeat them. It adds no additional meaning beyond what the schema provides, keeping the score at the baseline for high schema coverage.
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 it retrieves all events while explicitly excluding multivariate events, which distinguishes it from the sibling tool kalshi_get_multivariate_events. The phrase 'Get all events' is a specific verb+resource statement, and the historical cutoff note clarifies 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 provides an explicit alternative for multivariate events ('use the GET /events/multivariate endpoint'), which directly guides tool selection. It also notes that all events are accessible regardless of historical cutoff, implying comprehensive coverage. However, it does not mention when to use this over other event-related tools like kalshi_get_event.
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 destructiveHint=false, so the tool's safety profile is clear. The description adds the endpoint and the inclusion of the primary account, which is helpful context. However, it does not disclose the return structure or any other behavioral details, so it provides only marginal value beyond 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the actual purpose in the second sentence and the endpoint in the third. The first sentence is somewhat redundant with the tool name, but overall the text is short and front-loaded, with no wasteful 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 simple parameterless GET endpoint, the description sufficiently conveys what it does and its scope. The lack of an output schema means the description does not need to explain return values, and the tool's straightforward nature makes this adequate. It could mention what balance fields are returned, but that is a minor gap.
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 zero parameters, so a baseline of 4 is appropriate. The description's mention of 'all subaccounts including the primary account' is a semantic qualifier rather than a parameter, and no parameter-level detail 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 opens with 'Get All Subaccount Balances' – a clear verb+resource pairing – and further specifies 'all subaccounts including the primary account,' which distinguishes it from sibling tools like kalshi_get_balance. It also names the exact endpoint, making the action 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 states the tool's scope ('all subaccounts including the primary account'), giving clear context for when to use it over account-specific balance tools. It does not explicitly name alternatives or exclusions, but the scope is informative enough for an agent to select it appropriately.
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 this as a safe read operation (readOnlyHint=true, destructiveHint=false). The description adds valuable context beyond annotations, including that block trades are included by default, that the response is paginated, and the specific fields returned (ticker, price, quantity, timestamp). This adds meaningful behavioral detail.
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 reasonably concise and front-loaded, starting with the core purpose. It includes some redundancy ('Get Trades Endpoint for getting all trades') and has a truncated phrase ('defaults to…'), but overall it efficiently covers key points without excessive fluff.
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 no output schema, the description adequately informs the agent about the response contents (market ticker, price, quantity, timestamp) and covers pagination and block trade filtering. It is slightly incomplete due to the truncated defaults text, but otherwise covers the essential context for a read-only list endpoint.
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%, so the baseline is 3. The description does reference the 'limit' and 'is_block_trade' parameters but does not add significant meaning beyond what the schema already documents. The schema descriptions are thorough, so the description adds marginal value in this dimension.
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 gets all trades for all markets, specifying the verb 'Get', the resource 'Trades', and the scope ('all markets'). This distinguishes it from sibling tools like kalshi_get_fills, which presumably handles user-specific fills.
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 provides clear usage context: it explains that block trades are included by default and how to filter them, and mentions pagination with the limit parameter. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
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?
With no annotations, the description carries the full burden. It discloses the one-shot nature, the connect-list-disconnect lifecycle, and that it returns messages. This is useful behavioral context. It does not mention authentication requirements, message format, or behavior when no messages arrive, but for a read-only stream capture the core behavior is well covered.
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, immediately states the core function, and avoids any filler. It front-loads the verb and resource, then adds scope and behavioral nuance without bloat. Every sentence earns its place.
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 WebSocket stream tool with 4 parameters and no output schema, the description covers the essential context: what it captures, that it is one-shot, and the time-boxed nature. It does not detail parameter interactions (e.g., max_messages vs duration, required channels for orderbook_delta), but the schema partially covers this. Overall, it is sufficiently informative for an agent to understand the tool's role and basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%; channels and market_tickers have descriptions, but max_messages and duration_seconds do not. The description adds only an indirect hint with 'for the window you ask for' (referring to duration) and 'few seconds.' It fails to explain the interplay between max_messages and duration_seconds, or which channels require market_tickers. This is a significant gap for a 4-parameter tool.
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 a specific action: 'Watch Kalshi's WebSocket feed... and return the messages that arrive.' It identifies the resource (WebSocket feed) and distinguishes itself from sibling REST tools by emphasizing real-time streaming and one-shot capture. The phrase 'not an ongoing subscription' further clarifies its unique 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?
It provides a clear use case: 'Useful for seeing live order book changes, trades, or your own fills as they happen.' It also states when not to use it (for ongoing subscriptions), implying for persistent streaming you should look elsewhere. However, it does not explicitly name alternative tools like get_market_orderbook or get_trades for historical/snapshot needs, so some guidance is implicit rather than explicit.
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 set readOnlyHint=false and destructiveHint=false, indicating a non-read-only mutation. The description adds the specific behavior (decreasing remaining count) and the HTTP method/path ('Calls POST /portfolio/events/orders/{order_id}/decrease'), which provides useful context beyond the annotations. It does not go into error conditions or side effects, but the added context justifies a 4.
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, front-loaded with the core purpose, and contains no filler. The second sentence delivers the critical constraint and endpoint, making it both concise and informative.
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 6-parameter tool with comprehensive schema descriptions and no output schema, the description is largely complete. It explains the action, the constraint, and the endpoint. A minor gap is the absence of a note on when to use this instead of cancel/amend, but given the schema's richness, this is not a significant omission.
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 high (83%), so the schema already documents all parameters including the 'exactly one of' constraint on reduce_by/reduce_to. The description repeats this constraint but does not add new semantic meaning. With the schema doing the heavy lifting, a baseline 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 clearly states the specific action: 'decreasing the remaining count of an existing event-market order using the V2 request/response shape.' This distinguishes it from siblings like kalshi_cancel_order_v2 (which cancels an order) and kalshi_amend_order_v2 (which may change other fields). The explicit endpoint path reinforces the tool's 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?
Provides a clear usage constraint: 'Exactly one of `reduce_by` or `reduce_to` must be provided.' This tells the agent how to invoke the tool correctly. However, it does not explicitly state when to prefer this tool over alternatives like cancel or amend, so it lacks exclusionary guidance.
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 and destructiveHint=false, so the safety profile is covered. The description adds value by explaining the historical data cutoff and the meaning of a fill, which are not derivable from annotations alone.
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 compact: two sentences and a link. It front-loads the purpose and provides the critical historical caveat without unnecessary verbiage.
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 straightforward read endpoint, the description covers the core concept, the endpoint, and the historical limitation. The schema documents all parameters, so the lack of response format details is acceptable though not fully comprehensive.
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 of the 7 parameters well-documented. The description does not add extra parameter details, so the baseline of 3 is appropriate since the schema carries the semantic load.
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 'getting all fills for the member' and defines what a fill is. It also distinguishes from the historical fills endpoint by naming the alternative `GET /historical/fills`, making the tool's scope 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 provides an important usage boundary: fills before the historical cutoff are only available via a different endpoint. It also notes the underlying REST call, but doesn't explicitly compare against sibling tools like kalshi_get_trades, so some guidance is implicit.
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 this as a safe read operation. The description adds behavioral context by explaining that queue position is determined by price-time priority and represents the amount of orders ahead in the match queue. It also specifies the HTTP method, reinforcing the read-only nature. No mention of error handling or rate limits, but the added context suffices.
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 plus the endpoint, with no redundancy. It front-loads the purpose, then explains the concept, and ends with the API call. Every sentence contributes 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 single-parameter read-only tool with no output schema, the description explains what the tool returns (queue position as a count of orders to be matched). It omits details like error responses or exact return type, but for this complexity level, it is adequate. The read-only annotation and clear endpoint make it self-sufficient.
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 schema fully describes the sole parameter (order_id as a string with description 'Order ID'), giving 100% coverage. The description does not add further detail about the parameter's format or constraints beyond referencing it in the endpoint path. Baseline applies.
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 tool as retrieving an order's queue position using a specific verb ('Get') and resource ('order queue position'). It explains the meaning of queue position, distinguishing it from the sibling tool 'kalshi_get_order_queue_positions' by focusing on a single order via order_id. The inclusion of the HTTP endpoint further clarifies the 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 provides context on when this tool is relevant: when checking how many orders need to match before a specific order is filled. It does not explicitly name alternatives or state when not to use it, but the singular 'order' and order_id parameter imply single-order queries, contrasting with the plural sibling. This is clear context without 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?
With no annotations, the description must convey safety/behavior itself. It does disclose that only resting orders can be canceled and that cash is released, which is valuable. However, it omits details like idempotency, error conditions, or whether canceled orders are irreversible, so it falls short of full 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?
Two concise sentences, front-loaded purpose, 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 low-complexity tool with fully documented schema, the description covers purpose, a key behavioral consequence (cash release), and a practical prerequisite. It's slightly thin on return values and error scenarios but sufficient for a paper trading helper.
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?
Schema covers both parameters fully with descriptions and an example. The description adds the tip to retrieve order IDs via kalshi_paper_portfolio, augmenting the schema's information.
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 specifies the action ('Cancel'), the object ('resting simulated order'), and the consequence ('release cash'), which distinguishes it from live cancel tools (kalshi_cancel_order_v2) and paper order/portfolio siblings.
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?
It explicitly directs users to kalshi_paper_portfolio for order IDs, providing clear context for using the required parameter. It doesn't explicitly contrast with live cancel tools, but the word 'simulated' implies the paper context, earning a 4 rather than 5.
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?
No annotations are provided, so the description carries full disclosure burden. It reveals a non-obvious side effect: calling this tool brings the portfolio up to date, settling markets and matching resting orders, which is critical for an agent to know before invoking it. It stops short of detailing sequence or edge cases, but the core behavioral trait is clearly stated.
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?
Three sentences deliver the main purpose, usage scenario, and side effect with no filler. The first sentence packs the valuation components, and each subsequent sentence adds necessary context (when to call, what happens).
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 4-parameter, no-output-schema tool, the description covers what it returns, why to use it, and its state-updating nature. It lacks a formal return structure, but the enumerated components give sufficient guidance. The side-effect disclosure is especially valuable for a tool that appears read-only at first glance.
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 covers 75% of parameters with descriptions, but the tool description itself adds no parameter-specific semantics. It mentions output fields rather than explaining fill_limit or how include_fills/include_orders affect behavior, so it does not compensate for fill_limit's missing description.
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 explicitly states the tool values a simulated portfolio against live prices and enumerates the valuation components (cash, positions, P&L, fees, total return). It distinguishes itself from siblings like kalshi_paper_order or kalshi_get_positions by focusing on portfolio valuation with mark-to-market, not order placement or live positions.
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?
It explicitly says 'Call this to monitor paper positions over time,' giving a clear use case. It also explains that it updates the portfolio state (settled markets pay out, resting orders match), which tells users when to call it for simulation advancement. However, it does not name alternative tools or say 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and does well by explicitly stating that positions, orders, and history are discarded, and that it wipes back to a fresh cash balance. This discloses the destructive nature beyond what the schema 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?
Two concise sentences, with the main action and key effects front-loaded. Every word earns its place and no unnecessary detail is included.
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 tool with 3 parameters and no output schema, the description covers purpose, effects, and a usage example. It doesn't mention the delete option, but the schema already covers it, so completeness is adequate.
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 adds a minor hint via the example 'paper trade $50' (starting balance), but does not elaborate on the delete or portfolio parameters beyond what the schema already says.
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 creates or wipes a simulated portfolio, with specific effects (discarding positions, orders, history). It distinguishes itself from sibling paper tools like paper_order and paper_portfolio by focusing on reset/creation.
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?
Provides a clear use case: 'Use this to start a new experiment, for example "paper trade $50".' This gives context for when to use it, though it doesn't explicitly mention when not to use it or name alternative 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?
With no annotations, the description carries the burden. It does disclose that the tool reports configuration details and implies read-only behavior via 'Report,' but it does not explicitly state safety, side effects, or what happens if the server is unreachable. The information provided is useful but not deeply transparent.
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, front-loaded with the main purpose, and both sentences earn their place—one for scope, one for usage guidance. No fluff or 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 low-complexity, zero-parameter diagnostic tool, the description covers what it reports and when to use it. It does not describe the exact output structure, but since there is no output schema, the enumerated report categories provide sufficient context. It is complete enough for an agent to select and invoke correctly.
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 there are no parameter semantics to clarify. The description appropriately focuses on the tool's purpose and output; the baseline of 4 for a zero-parameter tool applies.
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 a specific verb ('Report') and resource ('how this server is configured'), then enumerates exactly what aspects are covered: environment, API key, toolsets, and limits. This distinguishes it from sibling tools that focus on market data or order operations.
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 explicitly says 'Check this first if a call fails unexpectedly,' providing a clear when-to-use instruction as a diagnostic first step. It does not mention alternatives or when-not-to-use, but the context is strong enough for a clear recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses significant behavioral traits: response limits, grouping behavior, and the optional synthetic candlestick logic including its algorithmic details. This goes well beyond the annotation's simple read-only declaration.
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 concise, with three bullet-style sentences plus an endpoint reference. It front-loads the purpose, lists key constraints in a scannable format, and contains no filler or 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?
Given a read-only batch tool with no output schema, the description covers essential aspects: limits, grouping, and the optional synthetic behavior. It does not describe the candlestick data structure, but that is likely predictable from the domain, and the input schema is thoroughly documented. This is sufficiently complete but not exhaustive.
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?
Schema coverage is 100%, so baseline is 3. The description adds value by explicitly highlighting the include_latest_before_start parameter and explaining its price-continuity purpose, which supplements the schema's own detailed description. This earns a 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 clearly states the tool retrieves candlestick data for multiple markets via a batch endpoint, using specific verbs like 'Batch Get' and 'retrieving'. It distinguishes itself from sibling tools by emphasizing 'multiple markets' and the 100-ticker limit.
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 usage for fetching data across multiple markets, with explicit limits (up to 100 tickers, 10,000 candlesticks) and grouping by market_id. However, it does not explicitly name alternatives or state when not to use it, though batch vs. single-market context is clear from sibling names.
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 and destructiveHint=false, covering the safety profile. The description adds behavioral context about the historical cutoff and the guarantee that resting orders are always available, which goes beyond annotations. It does not describe pagination or response format, but that is secondary for a read-only list endpoint.
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 four sentences and wastes no words. It starts with the action, lists the key constraint, mentions the historical alternative, and includes a documentation link. Every sentence serves a 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 tool's moderate complexity (8 optional params, no output schema), the description covers the key behavioral nuance (historical cutoff) and lists statuses. It does not describe the response structure, but the endpoint path and tool name imply the return of order objects. Schema covers parameters well, so the description is sufficient for an agent to invoke it correctly.
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 100% parameter coverage, so baseline is 3. The description adds value by specifying the valid status values (resting, canceled, executed) that the schema leaves as 'Possible values depend on the endpoint.' This extra detail clarifies the most important parameter.
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 gets orders and restricts them by status (resting, canceled, executed). It also specifies the exact API endpoint 'GET /portfolio/orders', making the resource unambiguous. This differentiates it from the singular 'kalshi_get_order' and historical orders endpoint.
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?
The description explicitly states when not to use this tool: canceled or fully executed orders before the historical cutoff must use 'GET /historical/orders'. It also notes resting orders are always available, providing clear usage context and an alternative endpoint. This is strong when/when-not guidance.
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 and destructiveHint=false, so the safety profile is covered. The description adds useful context: the FCM restriction, the rare applicability, and that the value is in cents. It does not describe return format, but for a simple read-only endpoint the coverage 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 concise: three sentences each add value—purpose, audience/usage, and API path. No filler or repetition.
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 read-only endpoint with no parameters and no output schema, the description is fully sufficient. It includes the endpoint path, the restrictive audience, and the return units, making it complete for an agent to select and invoke.
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 schema coverage is 100% by definition. Per the baseline for 0 params, this scores 4. The description adds context about units (cents) and the audience, which enriches understanding of the operation.
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 gets the total value of resting orders in cents, with a specific verb and resource. It also provides the exact API endpoint, distinguishing it from sibling tools that cover other portfolio/order data.
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?
Explicitly states this endpoint is intended only for FCM members (rare) and advises that if uncertain, it probably does not apply. This gives clear when-to-use guidance and an exclusion, even without naming alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels. It discloses that no real order/money is involved, that prices/fills track the live exchange, that market orders walk the book and incur taker fees, that limit orders can rest and fill later, and that portfolios are created with a configurable starting balance. This is exemplary behavioral disclosure.
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 moderately long but every sentence earns its place: it explains the simulated nature, market/limit behavior, fees, portfolio lifecycle, and references reset. It is well-structured, front-loaded with the key point, and free of fluff.
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?
Despite no output schema, the description covers all critical user-facing aspects: how orders execute, fees, fill behavior, settlement basis, portfolio creation, and side/price semantics. It gives a complete mental model for using the tool correctly, which is especially valuable given the 8 parameters and 3 required fields.
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?
Schema coverage is 100%, so description bonus is limited. Still, the description adds meaning beyond the schema for several parameters: explains side semantics (buying NO equals selling YES), describes market vs. limit order execution tied to the 'type' parameter, clarifies that limit_price is required for limit orders, and explains portfolio creation with starting_balance_usd. This goes beyond the schema descriptions.
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: 'Place a simulated order against the live Kalshi book.' It explicitly distinguishes from real trading with 'Nothing here reaches Kalshi: no real order is placed and no real money moves.' It also differentiates from sibling paper tools (kalshi_paper_cancel, kalshi_paper_reset) by focusing on placing orders.
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 clearly implies usage for simulated trading without risking real funds, and explicitly references kalshi_paper_reset for portfolio creation. However, it does not explicitly name alternatives (e.g., kalshi_create_order_v2) or provide when-not-to-use guidance, so it falls just short of 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:

[![KalTraderMCP MCP server](https://glama.ai/mcp/servers/SakethSripada/KalTraderMCP/badges/card.svg)](https://glama.ai/mcp/servers/SakethSripada/KalTraderMCP)

Score Badge

Copy to your README.md:

[![KalTraderMCP MCP server](https://glama.ai/mcp/servers/SakethSripada/KalTraderMCP/badges/score.svg)](https://glama.ai/mcp/servers/SakethSripada/KalTraderMCP)

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/SakethSripada/KalTraderMCP'

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