Academic Research Intelligence MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden. It discloses pricing, daily free allowance, the 402 error recovery flow, and the API key bypass. The 'Analyze' verb implies read-only behavior, which is consistent. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short paragraphs with no fluff. The first paragraph states the tool's purpose and output, the second explains payment mechanics. Every sentence adds necessary information, and it is front-loaded with the primary function.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists, the description need not detail return values, but it does list key metrics. However, it lacks guidance on how to properly specify the author (e.g., which of author_id or author_name to use, or what happens if both are provided). This omission reduces 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?

Schema description coverage is 100%, so the baseline is 3. The description adds context for the payment_tx parameter (retry flow) and clarifies that author_id or author_name are used for lookup, but it does not explain which takes precedence or how they interact. Marginal value added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Analyze') and resource ('author's research profile from OpenAlex') and lists specific metrics (h-index, paper count, etc.). This distinguishes it from sibling tools that focus on papers or graphs, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for evaluating academic authors in literature reviews but provides no explicit guidance on when to use this tool versus siblings like paper_detail or citation_graph. It does include detailed instructions for payment handling (free tier, 402 retry), but lacks comparative context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description carries full burden. It explicitly discloses the paid model ($0.01 per query after free 25/day), daily free allowance, error handling (402 with Solana memo), and authentication bypass (Bearer fnet_ key). This is comprehensive behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with two sentences: first defines the tool's function, second explains the paid model and retry behavior. It is front-loaded with purpose. However, the second sentence could be better structured for readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema, the description does not need to explain return values. It covers purpose, usage context, cost, and error handling. It is nearly complete for a tool with 5 parameters and one required field.

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?

Schema description coverage is 100%, and the schema already provides clear descriptions for all 5 parameters. The description does not add significant new semantic meaning beyond what is in the schema, except contextualizing the payment_tx parameter. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('analyze', 'list'), the resource ('citation graph for a paper'), and the specific actions (get citations or references). It distinguishes the tool from siblings like 'paper_detail' and 'similar_papers' by focusing on citation links.

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?

The description implies when to use the tool (for tracing influence and prior work in literature review). It also provides guidance on payment and error handling (402 retry). However, it does not explicitly state when not to use it or compare with alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the return content and that it is 'FREE', but does not disclose whether it is read-only, if authentication is needed, or any rate limits or side effects. For an info tool, basic read-only clarity is expected.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is relatively concise at about four sentences, with the main purpose front-loaded. It could be slightly more structured (e.g., bullet points for the returned items) but is still efficient and readable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has no parameters and the output schema exists (implied by context), the description comprehensively lists what information is returned. It fully explains the tool's output and purpose, making it complete for an info tool.

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 tool has zero parameters, so the baseline is 4. The description adds significant value by detailing exactly what is returned (attestation guidance, MINT endpoint, ten sister servers), which compensates for the lack of parameters and enriches the understanding of the output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves FoundryNet Data Network info and MINT Protocol details, specifying the returned content. It does not explicitly distinguish from sibling tools, but the sibling tools are related to research papers, so it is likely distinct. Still, a brief differentiation would improve clarity.

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?

The description implies usage when needing information about the MINT protocol or FoundryNet, but it does not provide explicit guidance on when to use this tool vs alternatives, nor does it mention when not to use it. The word 'FREE' hints at no cost but is not a usage guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It notes that TLDR is included 'when available,' hinting at data completeness variability. However, it does not mention rate limits, authentication, error handling (e.g., ambiguous input with multiple identifiers), or whether it returns exactly one result. The schema allows all three parameters to be null, but description implies exactly one should be provided, creating ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, with the first sentence listing all returned fields and sources, and the second sentence providing usage instructions. Every word is functional; there is no fluff. It is appropriately sized for a retrieval tool with a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that an output schema exists (context signal: Has output schema: true), the description does not need to detail return values. It covers the key input identifier types, sources, and output fields (abstract, authors, etc.). It lacks error handling and specifics on multiple identifiers but is sufficient for a simple retrieval tool. The 'FREE' note adds value.

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?

Schema description coverage is 100% (each parameter has a description), so the baseline is 3. The overall description adds limited extra meaning: it lists the three allowed input types and says to provide one, but the schema already explains each parameter. The mention 'FREE' is extra but not about parameters. The description does not significantly improve understanding beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get the full record'), specifies the resource ('academic paper'), and lists sources (OpenAlex, arXiv, PubMed) and returned fields (abstract, authors, venue, year, citation/reference counts, PDF link, TLDR). It distinguishes from sibling tools like search_papers (which returns lists) and similar_papers (which finds related papers) by focusing on retrieving a complete record for a known paper.

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?

The description explicitly instructs the user to 'Provide a paper_id, a DOI, or a title,' indicating both the required input and the three acceptable identifier types. While it does not explicitly state when to use this tool over siblings, the purpose implies it is for known papers needing full details, and siblings are for searching or finding related papers. The mention 'FREE' adds a contextual note.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description covers search scope, filtering, return fields, sorting by citations, and importantly the payment mechanism (402 handling, free allowance, key bypass). It could mention pagination or rate limits but is generally transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with purpose and filters, then payment details. It is somewhat long but each sentence adds value. Structure is logical, though could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given an output schema exists (context signal true), the description adequately covers return values and payment handling. It misses mentioning default limit or handling of empty results, but overall it is complete enough for a search tool.

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?

Schema description coverage is high (80%), so baseline 3. The description adds context for payment parameters and agent_id but does not significantly enhance meaning for other parameters beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it searches academic papers across multiple sources (OpenAlex, arXiv, PubMed) for literature reviews, lists filters, and return fields. This differentiates it from siblings like paper_detail or similar_papers.

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?

The description specifies the tool is for literature reviews with relevant filters. It also explains payment handling and free allowance. However, it does not explicitly state when not to use or compare to alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It explains the payment model (daily free allowance, $0.02 per query, 402 handling), the underlying technology (fastembed, pgvector), and the use of an authorization key. It does not detail error behaviors or rate limits beyond the daily cap, but overall is transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: one clear purpose sentence, then key details in a bullet-like paragraph. Every sentence adds value, and payment instructions are necessary for proper usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (payment system, multiple inputs) and the presence of an output schema, the description covers essential behavioral and usage aspects. It lacks information about error handling or data sources, but overall is sufficient for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds little beyond the schema: it clarifies mutual exclusivity of query and paper_id and repeats terse parameter descriptions. No additional formatting or constraints are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Find related academic papers by semantic similarity' and positions it as 'the related work finder for a literature review'. It distinguishes from sibling tools by specifying semantic similarity based on a query or paper_id, which is different from keyword search (search_papers) or citation links (citation_graph).

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?

The description provides clear usage context ('literature review') and two input modes (query or paper_id). It includes detailed payment instructions for premium usage. However, it does not explicitly exclude use cases where other tools might be better (e.g., when citation data is needed).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description bears full responsibility. It details the payment model ($0.01 per query after 25/day free), HTTP 402 handling, the re-call procedure with payment_tx, and an auth bypass using a Bearer token. This covers key behavioral traits beyond the tool's core function, though it does not mention side effects or rate limits beyond free allowance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise: two short paragraphs. The first immediately states the purpose, the second covers essential payment/auth details. Every sentence adds value, and there is no redundant or extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 5 parameters, a payment model, multiple data sources, and an output schema (which covers return values), the description is largely complete. It explains the payment flow, auth bypass, and metric options. However, it omits details like daily allowance reset time or rate limits, which would fully round out the context.

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?

Schema coverage is 100% and every parameter has a schema description. The tool description does not add any parameter-specific details beyond what is already in the input schema (e.g., days default, metric options). It only repeats the 'field' filtering in prose. Hence, it provides no extra semantic value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool finds trending research across three named sources (OpenAlex, arXiv, PubMed) using citations or volume metrics, optionally scoped by field. It also clarifies its use case: 'For tracking emerging scientific literature.' This clearly distinguishes it from sibling tools like search_papers (general search) or paper_detail (single paper info).

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?

The description implies the tool is suitable for tracking emerging literature and trending topics, but does not explicitly contrast with alternatives or state when not to use it. There is no mention of prerequisites or comparison to sibling tools, leaving the agent to infer usage from context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.