TMDB MCP Server

Overview Schema Source Related Servers Discussions Admin

Get person details

get_person

Read-only

Retrieve full details for a person by TMDB ID, including biography, birth/death dates, department, and TMDB/IMDb links. Use it for profile lookups; fetch filmography separately with credits.

Instructions

Get full details for one person by TMDB id: biography, birthday/deathday, department, and links (TMDB + IMDb). Does not include filmography — use get_person_credits for that. Get the id from search_people or a credits list.

Input Schema

Name	Required	Description	Default
`id`	Yes	TMDB numeric id.
`language`	No	Override the response language (ISO-639-1, optionally with a region), e.g. 'ru-RU' or 'en-US'. Localizes titles/overviews/genre names. Defaults to the server's TMDB_LANGUAGE. A well-formed code TMDB has no translation for (e.g. 'xx') is not an error: overviews come back null, movies/shows keep their original-language title, and episodes get a generic 'Episode N' name.

Output Schema

Name	Required	Description	Default
`id`	Yes
`name`	No
`gender`	Yes
`imdb_id`	Yes
`birthday`	Yes
`deathday`	Yes
`homepage`	Yes
`imdb_url`	Yes
`tmdb_url`	Yes
`biography`	Yes
`popularity`	Yes
`profile_url`	Yes
`also_known_as`	Yes
`place_of_birth`	Yes
`known_for_department`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed19 schema fields changedv0.14.0Oct 24, 2026

changedInput schema / properties / language / description

Previous value: -"Override the response language (ISO-639-1, optionally with a region), e.g. 'ru-RU' or 'en-US'. Localizes titles/overviews/genre names. Defaults to the server's TMDB_LANGUAGE."New value: +"Override the response language (ISO-639-1, optionally with a region), e.g. 'ru-RU' or 'en-US'. Localizes titles/overviews/genre names. Defaults to the server's TMDB_LANGUAGE. A well-formed code TMDB has no translation for (e.g. 'xx') is not an error: overviews come back null, movies/shows keep their original-language title, and episodes get a generic 'Episode N' name."

removedOutput schema / properties / biography / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / biography / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / gender / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / gender / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / homepage / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / homepage / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / imdb_id / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / imdb_id / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / imdb_url / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / imdb_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / known_for_department / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / known_for_department / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / place_of_birth / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / place_of_birth / type
```
Added value: +[
+  "string",
+  "null"
+]
```

removedOutput schema / properties / popularity / anyOf

Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / popularity / type
```
Added value: +[
+  "number",
+  "null"
+]
```

removedOutput schema / properties / profile_url / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedOutput schema / properties / profile_url / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed4 schema fields changedv0.10.1Jul 30, 2026

changedOutput schema / properties / birthday / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / birthday / default
```
Added value: +null
```

changedOutput schema / properties / deathday / anyOf

Previous value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / deathday / default
```
Added value: +null
```

Addedv0.8.1Jul 26, 2026
Removedv0.8.0Jul 22, 2026
First observedv0.3.0Jul 9, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds valuable scope disclosure about what the response contains and deliberately omits. It does not mention language/localization behavior or the shape of the returned links, but the output schema and the language parameter description carry those details.

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

Conciseness5/5

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

Three short sentences with zero padding: what it returns first, the exclusion second, how to obtain the id third. Every clause carries information an agent needs to route the call.

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 single-record lookup with an output schema, full parameter documentation, and read-only annotations, the description supplies the remaining unknowns: field coverage, filmography exclusion, and id provenance. Nothing needed to call it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, including a detailed explanation of the language override and TMDB fallback behavior, so the schema does the heavy lifting. The description only echoes 'by TMDB id' and adds no semantics beyond the schema — the expected baseline of 3.

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 and resource ('Get full details for one person by TMDB id') and enumerates the returned fields (biography, birthday/deathday, department, links). It explicitly separates itself from get_person_credits, so the agent can distinguish the two 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.

Usage Guidelines5/5

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

Names the excluded use case and the alternative ('Does not include filmography — use get_person_credits for that'), plus prerequisite routing for the id ('Get the id from search_people or a credits list'). Both the when and the when-not are stated outright.

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