interactionsInteraction partners for a set of proteins.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max partners per protein (default 10). | |
| species | No | ||
| identifiers | Yes | ||
| network_type | No | functional (default) | physical | |
| required_score | No | 0-1000 confidence score (default 400). |
| Name | Required | Description | Default |
|---|---|---|---|
| count | Yes | Number of items returned. | |
| items | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / examplesAdded value: +[
+ {
+ "identifiers": [
+ "9606.ENSP00000269305"
+ ]
+ },
+ {
+ "identifiers": [
+ "9606.ENSP00000269305",
+ "9606.ENSP00000005339"
+ ],
+ "network_type": "physical",
+ "required_score": 700
+ }
+]Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "count": {
+ "description": "Number of items returned.",
+ "type": "integer"
+ },
+ "items": {
+ "items": {
+ "properties": {
+ "ncbiTaxonId": {
+ "description": "NCBI taxonomy ID",
+ "type": "number"
+ },
+ "preferredName_A": {
+ "description": "Query protein name",
+ "type": "string"
+ },
+ "preferredName_B": {
+ "description": "Partner protein name",
+ "type": "string"
+ },
+ "score": {
+ "description": "Interaction confidence score (0-1000)",
+ "type": "number"
+ },
+ "stringId_A": {
+ "description": "Query protein STRING ID",
+ "type": "string"
+ },
+ "stringId_B": {
+ "description": "Interaction partner STRING ID",
+ "type": "string"
+ }
+ },
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "items",
+ "count"
+ ],
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds no additional context about behavior, such as how network_type or required_score affect results, or any limitations like the number of partners returned. The description is too terse to disclose any behavioral traits beyond the basic purpose.
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 a single, brief sentence with no wasted words, which is concise, but it is under-specified rather than appropriately structured. It lacks any elaboration or hierarchy to help the agent understand the tool's capabilities and limits.
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 tool has moderate complexity with five parameters and an output schema, yet the description provides only a minimal statement of purpose. It does not orient the user on selection criteria, default behavior, or relationships to sibling tools, making it incomplete for effective and safe invocation.
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 schema provides descriptions for limit, network_type, and required_score (60% coverage), but the description itself adds no meaning for parameters like identifiers or species. Examples in the schema illustrate the identifier format, but the description does not clarify parameter usage or constraints 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's core function: returning interaction partners for a set of proteins. It names the resource (protein interactions) and the input (proteins), but lacks an explicit verb and does not differentiate from sibling tools like 'network'. This makes it clear but not fully specific.
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 no guidance on when to use this tool versus alternatives such as 'network', 'enrichment', or 'homology'. There is no mention of scenarios where this tool is preferred or when a sibling tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools have heavily overlapping purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, discover_tools, and suggest_questions all route to the same underlying data catalog. The six polymarket_* tools also blur together (edges, arbitrage, edge_tracker, fill_risk, kalshi_spread), and resolve vs resolve_entity is an outright collision an agent will likely misselect.
There is a solid verb_noun core (list_subscriptions, scan_dependency, validate_claim, suggest_questions, compare_entities) but it is mixed with bare nouns (enrichment, homology, interactions, network) and product-prefixed names (pipeworx_feedback, polymarket_edges, ask_pipeworx). No single consistent pattern holds across the set, though the clusters are internally predictable.
At 36 tools this is well above the 25+ threshold for 'too many,' and the sprawl is not justified by a single coherent domain—prediction markets, bioinformatics, brand visibility, npm scanning, and subscription management are jammed together. The count makes the tool surface hard to navigate even with good descriptions.
Within each major cluster the lifecycle feels covered: memory (remember/recall/forget), subscriptions (subscribe/unsubscribe/list/recent_alerts), STRING-DB (resolve/homology/interactions/network/enrichment), and Polymarket analysis (scan/edge/arb/fill-risk/track) all form reasonably complete workflows. The main gap is that the server attempts so many domains that none is exhaustively deep, but there are no critical dead ends.