Skip to main content
Glama
Sign In

Nepternship

by io.github.robertisaak
OverviewDiscussionsAdmin

Save your join answers

sign_up

Save a new member's answers to the Nepternship join questions: what they are looking for (up to 3 industries, a preferred location and a sentence about the opportunity), whether their university career center referred them, their name, university and graduation year, and who they can introduce other members to (a specific person, their role, company and location). Use this once those answers have been collected in conversation. If the answer about who they can introduce is too vague, nothing is saved and the result says what is missing. Without a connected account it returns a join_code that creates the account when the user connects; with a connected account that has no profile yet, it creates the profile right away. No email address, phone number or password is collected here: the user adds those on Nepternship's own sign-in page when connecting.

Input Schema

NameRequiredDescriptionDefault
cityNoPreferred location, e.g. 'Boston, MA' or 'New York'
noteNoThe note for that held request, if they gave one
offeringYesWho they can introduce other members to, in their words, at least 10 characters: a specific person, their role and company, and a location if applicable
full_nameNo
industriesNoUp to 3 of: Academia, Arts, Business, Engineering, Entertainment, Fashion, Government, Healthcare, Law, Tech
universityNoUniversity as they say it, e.g. 'NYU'
looking_forYesThe type of opportunity they are looking for, in their words, at least 10 characters
linkedin_urlNoTheir LinkedIn profile link, if they share one: name, university and graduation year are copied from it
referral_codeNoFriend's referral code, if they have one
graduation_yearNo
offering_industryNoIndustry of the person they can introduce (one of the ten)
held_opportunity_idNoThe opportunity_id of the member they asked for an introduction before joining, if any
career_center_referralNoWhether their university career center referred them

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / held_opportunity_id / description
      Previous value: -"The opportunity_id of the member they asked for an intro before joining, if any"New value: +"The opportunity_id of the member they asked for an introduction before joining, if any"
    • addedInput schema / properties / linkedin_url
      Added value: +{
+  "description": "Their LinkedIn profile link, if they share one: name, university and graduation year are copied from it",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "full_name",
-  "university",
-  "looking_for",
-  "offering"
-]New value: +[
+  "looking_for",
+  "offering"
+]
  2. Changed3 schema fields changed
    • changedInput schema / properties / held_opportunity_id / description
      Previous value: -"The opportunity_id of the member they asked for an introduction before joining, if any"New value: +"The opportunity_id of the member they asked for an intro before joining, if any"
    • removedInput schema / properties / linkedin_url
      Removed value: -{
-  "description": "Their LinkedIn profile link, if they share one: name, university and graduation year are copied from it",
-  "type": "string"
-}
    • changedInput schema / required
      Previous value: -[
-  "looking_for",
-  "offering"
-]New value: +[
+  "full_name",
+  "university",
+  "looking_for",
+  "offering"
+]
  3. Changed2 schema fields changed
    • addedInput schema / properties / linkedin_url
      Added value: +{
+  "description": "Their LinkedIn profile link, if they share one: name, university and graduation year are copied from it",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "full_name",
-  "university",
-  "looking_for",
-  "offering"
-]New value: +[
+  "looking_for",
+  "offering"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / held_opportunity_id / description
      Previous value: -"The opportunity_id of the member they asked for an intro before joining, if any"New value: +"The opportunity_id of the member they asked for an introduction before joining, if any"
  5. Changed7 schema fields changed
    • changedInput schema / properties / career_center_referral / description
      Previous value: -"'Were you referred by your university career center?'"New value: +"Whether their university career center referred them"
    • removedInput schema / properties / email
      Removed value: -{
-  "description": "you@university.edu",
-  "type": "string"
-}
    • changedInput schema / properties / held_opportunity_id / description
      Previous value: -"The opportunity_id of the member they tried to request an intro from before signing up, if any (from the needs_account answer)"New value: +"The opportunity_id of the member they asked for an intro before joining, if any"
    • changedInput schema / properties / looking_for / description
      Previous value: -"'Expand on the type of opportunity you are looking for' in their words, at least 10 characters"New value: +"The type of opportunity they are looking for, in their words, at least 10 characters"
    • addedInput schema / properties / note
      Added value: +{
+  "description": "The note for that held request, if they gave one",
+  "maxLength": 200,
+  "type": "string"
+}
    • changedInput schema / properties / offering / description
      Previous value: -"'Who can you introduce other students to?' in their words, at least 10 characters: a specific person, their role and company, and a location if applicable"New value: +"Who they can introduce other members to, in their words, at least 10 characters: a specific person, their role and company, and a location if applicable"
    • changedInput schema / required
      Previous value: -[
-  "email",
-  "full_name",
-  "university",
-  "looking_for",
-  "offering"
-]New value: +[
+  "full_name",
+  "university",
+  "looking_for",
+  "offering"
+]
  6. First observed

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

All Nepternship toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources