get_claim_evidenceReturns the value, filing source, release identity, methodology version, and current or superseded status for a RentSeek clm_... claim ID. Requires OAuth or X-API-KEY and costs 1 credit. The result is filing evidence, not investment advice.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description adds value by disclosing the credit cost and a disclaimer ('not investment advice'). No contradictions, and the extra context about auth requirements further aids an agent in understanding behavioral constraints beyond safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first clearly states what the tool returns, second adds essential context (auth, cost, disclaimer). No unnecessary words, but could be more structured with bullet points or clearer separation of concerns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists five returned fields but does not specify their format or structure (no output schema). Given the tool's simplicity (one param), this is moderate but not fully complete – an agent might need to infer the response shape. For a tool without output schema, more detail on the output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage; the description compensates minimally by noting that the claim ID is a RentSeek `clm_...` ID, adding format context. However, it does not elaborate on the parameter's purpose or constraints beyond the schema's minLength, leaving significant gap for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns specific fields (value, filing source, etc.) for a RentSeek claim ID, using a specific verb 'Returns'. The resource is well-defined as 'claim evidence' and is distinct from sibling tools like get_company_dossier or list_available_tickers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions required authentication (OAuth or X-API-KEY) and cost (1 credit), which provides context but does not explicitly guide when to use this tool vs alternatives. Implicitly, it is for retrieving claim evidence by ID, but no when-not-to-use or sibling comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct aspect of executive compensation data: claim evidence, full company dossier, compensation rows, ticker listing, and material changes. Descriptions clearly differentiate them, preventing confusion.
All tools follow a consistent verb_noun pattern using snake_case: get_* for retrieval and list_* for enumeration. No mixing of styles or irregular verbs.
Five tools is well-scoped for the domain of accessing executive compensation filing data. Each tool provides essential functionality without unnecessary bloat or gaps.
The tool set covers core operations: retrieving evidence, dossiers, compensation details, available tickers, and material changes. A minor gap is the lack of a direct tool for bulk compensation data across multiple companies, but the set is largely complete.