Nepternship

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

With readOnlyHint/idempotentHint already declaring the safe-read profile, the description adds the non-obvious dual-mode behavior: no arguments returns the overview, while passing an id from a previous result opens that group. It stops short of describing result size, pagination behavior, or what the 'people under each' entries contain.

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?

Front-loaded purpose sentence, then usage triggers, then mechanics, then the sibling handoff — a logical order with no filler. The parenthetical example queries add value but make the middle sentence slightly long.

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?

Covers purpose, triggers, drill-down mechanics and routing, which is most of what a zero-required-param read tool needs, and no output schema exists so return shape needn't be explained. The missing piece is pagination behavior, which matters given a 60-item cap.

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 0%, so the description must carry parameter meaning. It does explain that company_id, role_id and industry_id come from a previous result and open that group, but says nothing about limit and offset (defaults 20/0, max 60), leaving two of five parameters entirely undocumented.

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?

States a specific verb and resource: shows companies, roles and industries where the user can get a warm introduction, with the people under each. It is clearly distinguished from search_members (named company/role lookup) and from the networking-outreach siblings.

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?

Gives explicit triggers with quoted example user intents ('which banks can I get an introduction at', 'what tech companies could I network into'), explains the no-argument overview mode, and names the alternative to use for a named company or role. When-to-use and when-not-to-use are both covered.

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?

Annotations already declare readOnlyHint=false, idempotentHint=true and openWorldHint=true, but the description adds context annotations cannot: the connection happens through an external sign-in page requiring Google/Apple/email plus a verified mobile number for new members, so the agent knows a user-facing handoff is involved. It also states the outcome ('returns the account status'), filling the gap left by the absent output schema.

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?

Three sentences, front-loaded with the action and mechanism, then usage, then the parameter rule and return value. The parenthetical about sign-in providers and mobile number is slightly dense but carries real behavioral information, so little is wasted.

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?

For a one-parameter, open-world, non-destructive mutation with no output schema, the description covers the trigger, the external interaction requirement, the account-creation path via join_code, and the return ('account status'). Remaining gaps are minor, such as what happens if the user abandons the sign-in page or what the status values look like.

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%, so the baseline is 3, but the description earns more by explaining the conditional semantics of join_code: it is only supplied when a new member saved join answers in this conversation, and its presence causes account creation. That is decision-relevant information the schema text does not fully convey.

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?

States a specific verb (connect) and resource (the user's Nepternship account to this assistant) plus the mechanism (Nepternship's sign-in page). It implicitly separates itself from sign_up by reserving this tool for members who want to see introductions or sign in, though it never names sign_up or signup_peek as siblings outright.

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?

Gives explicit triggering conditions for both personas: an existing member asking to sign in or view introductions, and a new member with saved join answers and no pending request. It also names the source of the one argument ('Pass join_code from sign_up'), which routes the agent to the correct preceding tool.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so the safety profile is covered. The description earns credit beyond them by disclosing the exact return payload scope and that a card image is included, which is displayable to the user — useful behavioral context an agent would not otherwise know.

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 core scope (one member's full profile) is front-loaded, followed by the field list and then the usage triggers. Four sentences with little waste, though the field enumeration is slightly dense and could be tightened.

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?

With no output schema, the description carries the burden of describing return contents and does so thoroughly, including the card image side effect. Annotations handle the safety profile. The only remaining gap is the unresolved identity of user_id.

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?

There is one parameter with 0% schema description coverage, so the schema does nothing to explain user_id. The description implies a specific member is being fetched but never states that user_id is the target member's identifier rather than the caller's — a real ambiguity given the sibling get_my_profile. It partially compensates but not fully.

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 opens with a specific verb and resource ('Return one member's full profile') and enumerates exactly what that profile contains (introductions, role/company, their own looking-for, industries, locations, university, connection status). This clearly separates it from list-style siblings like browse_directory or search_members, though it never names those siblings explicitly.

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?

It gives concrete trigger conditions ('when the user wants to know more about a person from a search before asking for an introduction or referral') plus verbatim user phrasings ('who is this', 'what can they help me with'). It lacks explicit when-not guidance or a named alternative (e.g., get_my_profile for the caller's own data).

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is fully covered without prose. The description adds useful disclosure of what is returned (industries, intro requests remaining), but says nothing about the join_code parameter, caching, or when a profile might be absent.

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, front-loaded with the action and its scope, then the field list, then the usage cue. No filler or redundancy; every clause carries 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?

There is no output schema, so the description must describe the return payload, and it does so concretely by listing the profile fields. The one gap is the unexplained join_code, whose conditional role ('when a new member saved their join answers in this conversation' only appears in the schema) is left unaddressed in the description.

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 there is a single optional parameter, so the schema already carries the burden and baseline 3 applies. The description never mentions join_code, which is the genuinely puzzling part of this tool's signature (why a read of my profile takes a sign-up code), so it adds no meaning 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?

States a specific verb+resource ('Return the signed-in user's own Nepternship profile') and enumerates the fields returned, which lets an agent distinguish it from get_member or browse_directory at a glance. The 'own' qualifier is the decisive differentiator from sibling lookups.

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?

Explicitly says when to reach for it: 'Use this when the user asks about their own profile or settings.' That gives clear positive guidance, but there is no exclusion clause pointing to get_member for other people's profiles or to list_matches for matching data, so the boundary is inferred rather than stated.

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

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

With annotations present, the bar is lower, and the description still adds real behavior context: it returns an external nepternship.com URL, and the result differs depending on whether the user already subscribes. It does not explain what happens if join_code is omitted or how the link is generated, but nothing contradicts readOnlyHint=false / openWorldHint=true.

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: the first establishes what is returned and its branching, the second establishes the trigger. Nothing is repeated from the title and no sentence is filler.

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?

No output schema exists, and the description compensates by describing the payload (link, price, trial length) and its two variants. A minor gap remains around the optional join_code and whether the link is single-use or expiring, but an agent has enough to call it 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 coverage is 100% and the single optional join_code is fully documented there, including its origin (sign_up) and when it applies. The description adds no parameter guidance of its own, so the baseline 3 applies.

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?

States a specific verb ('Return') and a precisely scoped resource: the Nepternship Premium checkout link with price and trial length, or the manage-subscription link for existing subscribers. The conditional return branches are spelled out, so an agent can distinguish it from every sibling (sign_up, request_balance, send_intro_request) without opening a schema.

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?

Explicit gating: 'Use this only when the user explicitly asks to upgrade or asks how to get more intro requests after hitting the free limit.' That names both trigger conditions and an implicit exclusion (other mentions of premium should not trigger it). No alternatives need naming because no sibling produces a checkout link.

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?

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds substantive context beyond that: which match categories are included, the special free weekly curated match, and the exact per-item payload (match_id, other member, status, last message, unread count) — particularly valuable because there is no output schema. It does not discuss ordering or whether limit applies per category or overall.

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?

Three sentences, each earning its place: scope first, then retrieval triggers, then return shape. The lead clause front-loads the resource and the example questions are dense retrieval cues rather than filler.

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?

With no output schema, the description correctly compensates by describing the item fields, and it covers the non-obvious free weekly curated match. Remaining gaps are the 'declined' category relative to the default 'all' status and pagination/limit behavior, which an agent would need to reason about for large accounts.

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 only 33%: join_code is documented, while limit and status rely on bare type/default/enum metadata. The enumerated categories loosely map onto the status enum, but the description never mentions the 'declined' value or explains that the default status='all' may surface matches outside the three named categories, and it does not clarify whether limit (default 30, max 100) is a global page size or per-category. Some added meaning, but an important gap remains.

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 names a specific verb (List) and resource (the user's introductions) and immediately enumerates the three scopes covered: accepted matches with an open chat (including the free weekly curated match), inbound requests awaiting the user, and unanswered outbound requests. That scope is clearly distinct from siblings such as read_thread (message-level), search_members/browse_directory (discovery), and respond_to_request (mutation), so an agent can route without opening the schema.

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?

It gives explicit trigger questions ("did anyone reply", "any new introductions", "is anything waiting on me", "who have I connected with"), which is strong positive guidance for a status-listing tool. It stops short of naming alternatives or exclusions — e.g., that reading message bodies requires read_thread and acting on a request requires respond_to_request — so the routing is clear but not fully bounded.

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?

The description adds an important side effect beyond the annotations: reading marks the messages as read for the user. This is consistent with readOnlyHint=false and gives the agent useful behavioral context, though it does not discuss pagination, ordering, or auth prerequisites.

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 three short sentences, front-loaded with the core action and followed by usage and side-effect information. Every sentence adds useful information without repetition.

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?

It covers the core return behavior and the read-marking side effect, which is important for a tool with no output schema. However, it leaves gaps around message ordering, pagination via limit, and the role of join_code, so it is adequate but not fully complete.

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 only 33%, so the description should compensate for undocumented parameters, but it does not explain match_id or limit. It only implies that the thread is tied to a matched member, leaving key parameter semantics to the bare 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 states a specific verb and resource: returning the messages in one introduction's chat. It clearly scopes the operation to one introduction and distinguishes it from sibling actions like send_message or list_matches.

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?

It explicitly says to use this when the user wants to read or catch up on a conversation with a matched member. It gives clear usage context, though it does not name exclusions or sibling alternatives for finding a match or sending replies.

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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds value by enumerating what comes back (quota, referral credits, invite link), which the agent can use to decide whether a call is needed. It does not state auth/prerequisite requirements for the invite link, which is the remaining gap.

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 with no filler: the first front-loads the return payload, the second gives the invocation conditions. Every clause earns its place.

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?

With no output schema, the description carries the burden of describing return values and does so with three concrete items; annotations cover safety. Only the optional join_code pathway for brand-new members is left unexplained, a minor omission for a simple read.

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 join_code is already documented in the schema as originating from sign_up. The description never mentions the parameter or its optional/conditional nature, so it adds no meaning beyond the structured field — baseline 3 applies.

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?

States a specific verb ('Return') and names the exact payload: remaining intro requests, friend-referral credits, and the personal invite link. This clearly separates it from siblings like get_my_profile or get_upgrade_link without needing to open a schema.

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?

Gives two explicit triggers: when the user asks how many requests remain, and after send_intro_request reports the limit. It names the sibling that produces the condition, so the routing decision is unambiguous.

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?

Goes well beyond the annotations by explaining the downstream effect of each branch: accepting opens a chat, declining is private, the requester is never notified, and unanswered requests auto-expire after 30 days. That is exactly the kind of consequence detail destructiveHint=true cannot convey.

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?

Four short sentences, front-loaded with the core action, then consequences, then the confirmation instruction. Every sentence adds information an agent would otherwise have to guess.

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?

For a destructive, idempotent mutation with no output schema, the description covers both branches, the silent/expiry behavior, and the required user confirmation. The only gap is the join_code edge case for new members, which is left entirely to the schema.

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 only 33%, and the description never explains the action enum or match_id directly, though it implies match_id originates from list_matches. join_code carries a schema description, but the description offers no compensating detail for the undocumented parameters.

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?

States a specific verb pair (accept/decline) applied to a specific resource (introduction request), and anchors it to the sibling tool that produces those requests (status pending in list_matches). This clearly separates it from send_intro_request and list_matches.

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?

Gives the triggering condition (a request waiting on the user, pending in list_matches) and an explicit interaction guardrail: 'Confirm with the user before declining.' It doesn't spell out when to prefer accepting vs declining, but the decision is the user's by design.

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?

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered; the description adds genuinely new context about the corpus (Nepternship network, 3,000+ companies with named examples) and the return shape (grouped by company/role/industry, first name + last initial, opportunity_id for send_intro_request). It stops short of pagination or ranking/limit behavior, which would be the remaining useful disclosure.

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?

Front-loaded with the core purpose, then trigger examples, then corpus and return shape, then the sibling fallback -- a sound ordering. It is on the long side and the quoted example phrases border on redundant, but every sentence maps to a decision the agent must make.

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?

With no output schema, the description supplies the return contract (grouped results, name masking, opportunity_id bridging to send_intro_request) plus the corpus scope and the browse_directory fallback. An agent has everything needed to select and call this 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 coverage is 67%, with query and location documented; the description broadens query's meaning by listing team, role and industry as searchable dimensions and implies location narrowing via 'city'. The one gap is limit, which is neither in the schema description nor the prose, but the schema carries the rest adequately.

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?

States a specific verb and resource ('find people who can give a warm introduction or referral') with the axes it searches over (company, team, role, industry, city) and the use cases it serves. It also explicitly distinguishes itself from browse_directory, so an agent can route without opening either schema.

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?

Gives concrete trigger phrasings ('how do I get into Goldman Sachs', 'can anyone refer me at Google') plus the intent classes (networking, coffee chat, finding an analyst/engineer/recruiter). It also names the exclusion condition and the alternative: if the user has no target, use browse_directory.

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?

Annotations declare a non-readonly, non-destructive, open-world, non-idempotent write, and the description goes well beyond that: it discloses the Nepternship account requirement, the fallback next step without an account, the join_code handoff from sign_up, and the failure modes (free limit reached, request already exists). No return format detail, but an output schema is absent and the description covers status reporting adequately.

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?

Purpose and call-to-action are front-loaded, and every sentence carries operational information (trigger, pre-call check, auth requirement, fallbacks). It is a dense run-on block, however, and could be split so the auth and error behavior is scannable rather than buried mid-paragraph.

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?

Covers what an agent needs to invoke this write tool safely: the account prerequisite, the join_code flow, the confirmation step, and the two known rejection reasons. The only material hole is the semantics of the required opportunity_id, which an agent must guess from the sibling tools' 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?

With 50% schema coverage the description must compensate, and it does for join_code (explains it comes from sign_up) and note (optional, 200-char limit, and a reminder to confirm with the user), while existing_member is only indirectly implied. The required opportunity_id — the one mandatory argument — is never explained in either schema or description, leaving the most important parameter undefined.

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?

States a specific verb and resource ('Send a Nepternship member an introduction request') and immediately defines the concept — an intro/referral to a person the member can connect the user to, with a concrete example (analyst at JPMorgan). This clearly separates it from send_message and respond_to_request without requiring schema inspection.

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?

Explicitly names the triggering conditions and the sibling tools whose output feeds it (search_members, browse_directory, get_member), plus the UI path ('taps Request intro on the member card'). It also prescribes a pre-call step: check with the user whether they want to add a note before calling.

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?

Annotations already cover the safety profile (non-read-only, non-idempotent, non-destructive, open-world). The description adds meaningful context beyond that: the user-approval gate before sending, that chat is free post-acceptance, and that limit errors are self-explaining. It doesn't warn about duplicate sends despite idempotentHint=false, which would have been valuable.

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?

Three short sentences, each earning its place: capability, precondition, and cost/error behavior, with the capability front-loaded. No redundancy or filler.

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?

With no output schema and only three simple parameters, the definition covers the essentials: what it does, the approval gate, and how quota errors surface. Minor gaps remain around duplicate-send behavior and the join_code path, but nothing blocks correct 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?

Schema coverage is only 33% (only join_code is documented), so the description must compensate. It partially does: 'accepted match' clarifies match_id's domain and 'the exact text' the user approved clarifies the text parameter's provenance. It adds no format or length guidance and says nothing about join_code, leaving real gaps.

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?

States a specific verb and resource ('Send a message') and scopes it to 'one of the user's active introductions (an accepted match)', which implicitly separates it from send_intro_request and read_thread. It stops short of naming a sibling explicitly, so differentiation is inferential rather than stated.

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?

Gives a clear precondition: 'Use this only after the user has approved the exact text.' That is a real gating rule an agent can act on. It does not, however, contrast against alternatives (e.g., read_thread for reading, send_intro_request for starting a conversation) or state 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.

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

Goes well beyond the annotations: discloses the validation failure mode (vague introduction answer saves nothing and reports what's missing), the two account-state branches (join_code issued with no account; profile created immediately when connected but profiled-less), and explicitly what PII is not collected. This is rich behavioral context for a non-idempotent, open-world write.

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?

Front-loads the core purpose and field inventory, then layers behavior. The long parenthetical enumerations are dense but each clause carries information; the final PII sentence is worth its place, though the description is somewhat long overall.

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?

For a 13-parameter mutation with no output schema, the description covers the trigger, validation failure behavior, account-state branching, and excluded data, which is everything an agent needs to invoke it correctly and interpret results. No output schema is needed since the description explains the result semantics (join_code vs immediate profile).

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 85%, so parameters are largely self-documenting, but the description adds meaning by framing the required pair semantically (looking_for as opportunity type, offering as the introduction target with specificity requirements) and explaining the join-flow semantics of the account linkage. Some schema-only fields (note, held_opportunity_id, linkedin_url) aren't explained further in prose.

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?

States a specific verb+resource ('Save a new member's answers to the Nepternship join questions') and enumerates exactly which answers are stored. It is clearly distinguished from siblings like signup_peek (read preview) and connect_account (auth), since this is the write that persists onboarding answers.

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?

Explicitly says 'Use this once those answers have been collected in conversation,' which gives a clear trigger condition. It doesn't name alternatives (e.g., signup_peek for previewing), so it's not full when/when-not coverage, but the usage moment is unambiguous.

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?

Annotations already cover read-only, idempotent, closed-world and non-destructive, so the bar is lower. The description still adds genuinely useful disclosure: results are illustrative ('example companies', 'sample offerings', 'first names' only), not real member records, which prevents the agent from treating the output as an authoritative match list.

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, front-loaded with the return content before the usage note. Dense but every clause carries information; no filler.

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?

No output schema exists, so the description must describe the return payload, and it does: companies, roles, industries, sample offerings, first names. Combined with annotations and a fully documented 2-param schema, an agent has what it needs to call this 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 coverage is 100% with per-field descriptions, so the schema carries parameter meaning. The description reinforces that 'looking_for' is the prospect's stated answer and that results are surfaced where introductions can be made, but says nothing about how location shapes results — baseline 3 applies.

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?

States a specific verb (return/preview) and a concrete payload: example companies, roles, industries, sample offerings and first names. It is clearly distinguished from search_members or browse_directory by being a preview tied to a prospect's stated intent, though it never names those siblings explicitly.

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?

Gives explicit timing: 'while a new member is joining, right after they say what they are looking for.' That is strong when-to-use context. It stops short of any when-not clause or named alternative, leaving the boundary with directory/search tools to inference.

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