Skip to main content
Glama

noticed

by so.noticed.mcp
OverviewDiscussionsAdmin

get_person

Read-onlyIdempotent

One person's full record: profile (including github_login and github_url when known; team records use githubHandle and githubUrl), current role, and your relationship context (notes, tags, last interaction, added_at = when they entered your network) by default; pass include:'extras' or 'all' for work history, education, and repos. person_id:'me' for yourself. The contact section carries ALL of their emails, phones, and companies (primary first) — a person can have several of each, so read contact.emails rather than the single top-level email when the user asks for their addresses. The relationship section carries your memory of them: summary (cited), strength ({score, category}), mutuals (shared connections), actions (follow-ups — done flags completion), and memories (saved notes). scope:'team' opens the POOLED TEAM record for a person from a team search_people hit — who on the team knows them + their strength, and full-consent teammates' actions/notes/interactions attributed to each member. Relationship types include manual/derived origin, persistent rejections, and relationship_type_evidence with shared company/university, both date ranges, overlap precision, and provenance. Present-tense snapshot — an empty field means not recorded, NOT false.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNo'own' (default) — your own record. 'team' — the pooled TEAM record for a person from a team search_people hit (who knows them + full-consent teammates' notes/actions/interactions).
includeNo'dossier' (default, fast) · 'extras' (work history/education/repos) · 'all'.
team_idNoFor scope:'team' — the organizationId (from account_status.teams). Optional when you're in exactly one team; required otherwise.
person_idYesThe person's id (from search_people), or the literal 'me' for yourself.
compared_toNoOptional second person_id — adds a shared_signals section.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether noticed completed the operation.
dataNoThe operation result when ok is true.
errorNoA human-readable error when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / data / properties / enrichment
      Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "available": {
+      "type": "boolean"
+    },
+    "next_enrichment_at": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "status": {
+      "enum": [
+        "available",
+        "pro_team_required",
+        "not_found",
+        "no_email",
+        "in_progress",
+        "recently_enriched"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "available",
+    "status",
+    "next_enrichment_at"
+  ],
+  "type": "object"
+}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "The operation result when ok is true.",
+      "properties": {
+        "compared_to": {
+          "$ref": "#/properties/data/properties/person"
+        },
+        "contact": {
+          "$ref": "#/properties/data/properties/person"
+        },
+        "person": {
+          "additionalProperties": true,
+          "properties": {},
+          "type": "object"
+        },
+        "relationship": {
+          "$ref": "#/properties/data/properties/person"
+        },
+        "scope": {
+          "enum": [
+            "own",
+            "team",
+            "public"
+          ],
+          "type": "string"
+        },
+        "shared_signals": {
+          "$ref": "#/properties/data/properties/person"
+        },
+        "team": {
+          "$ref": "#/properties/data/properties/person"
+        }
+      },
+      "type": "object"
+    },
+    "error": {
+      "description": "A human-readable error when ok is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether noticed completed the operation.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral context: the 'present-tense snapshot' caveat (empty field means not recorded), the instruction to read contact.emails instead of a top-level email, and the pooled team record semantics. These go beyond the annotations without contradicting them.

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?

The description is long but deliberately structured: main purpose first, then options, then detailed sections. Every sentence carries information that affects tool usage (e.g., contact structure, relationship fields, team scope). It is not tautological; it is a dense but well-organized reference. Slightly verbose, but earned.

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 tool with 5 parameters, an output schema, and complex relationship data, the description covers all usage aspects: default vs. include options, team scope, person_id literal, contact/relationship structure, and the snapshot caveat. Nothing an agent needs to call this correctly is missing.

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 description coverage is 100%, so baseline is 3. The description adds meaning: the 'me' literal, the team_id conditional requirement, and the include values' effects (work history/education/repos). It also clarifies the relationship section's subfields. This enriches the schema, justifying a score above baseline.

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?

The description opens with a precise verb+resource ('One person's full record') and enumerates the exact sections (profile, contact, relationship) and optional include values. It clearly distinguishes this from sibling retrieval tools like search_people and my_profile by the level of detail and the explicit mention of 'from a team search_people hit'.

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?

The description gives strong usage context: when to use 'me', when to use 'team' scope, and the include options. It references search_people as the source of person_id, and explains the team_id requirement. It does not explicitly exclude alternative tools, but the purpose is so distinct that it is implicitly clear.

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

All noticed 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